MCP Server Security: What's in Place Today, and What Isn't

Evaluate the complete data path

An MCP server can expose source code, documentation, and internal runbooks to AI clients. Evaluating its security requires more than checking whether the endpoint supports authentication. Review the complete path:

1. What leaves your environment?
2. What is stored, and for how long?
3. Which requests require authentication?
4. What happens when a source or account is deleted?
5. Which controls are incomplete?

This article applies those questions to MCP Studio as it exists today.

Indexing and model processing

For indexed sources, MCP Studio crawls content, splits it into passages, and sends those passages to OpenAI's API to create embeddings. The embeddings support semantic search. MCP Studio does not train a model.

According to OpenAI's data controls documentation, API data is not used to train OpenAI models. OpenAI may retain abuse monitoring logs for up to 30 days. If your data policy prohibits that retention window, do not index the affected content in MCP Studio.

This is separate from the policy of the AI client that calls your server. Cursor documents its controls in Privacy Mode. GitHub documents Copilot model hosting and plan differences in its model hosting documentation. You need to evaluate both the MCP service and the client because retrieved passages pass through both systems.

Stored content and telemetry

Indexed source content remains in Postgres on Neon while the source is connected. The database is encrypted at rest and connections use SSL.

MCP Studio also records request telemetry. A request record can include the query text and up to 480 characters of a returned passage. Retention depends on the data type and analytics tier:

Data	Retention
Query text and returned passages, free tier	Removed at 90 days
Query text and returned passages, paid analytics	Removed at 395 days
Request records, including timing, tool name, and success	Deleted at 395 days
Cached search results	5 minutes

On the free tier, text is scrubbed at 90 days while noncontent fields remain until day 395. This preserves aggregate usage charts without retaining the query or excerpt for the full period. A nightly job applies these policies.

Public and private server access

Servers are public by default. Anyone with a public server URL can call it.

A private server requires an access token. Each token is scoped to one server, begins with mcps_live_, and is shown once at creation. MCP Studio stores a SHA-256 hash rather than the plaintext token. Tokens can be revoked individually.

Authorization runs before the JSON-RPC method is processed. An unauthenticated caller cannot run initialize, list tools, or call a tool. Both the standard POST transport and both legs of the SSE transport apply the same check. Requests for a server owned by another account return "not found" rather than disclosing its existence.

Adding a private GitHub repository forces the server to private visibility. Repository visibility is resolved on the server with GitHub data, not accepted from the browser. If visibility cannot be verified, the repository is treated as private. The server cannot return to public visibility until the private source is disconnected.

The private MCP servers guide covers token creation and client configuration.

GitHub OAuth access

GitHub sign in requests read:user user:email for identity. The broader repo scope is requested only when a signed in user adds a private repository.

The repo scope is broader than MCP Studio needs. It can provide read and write access across repositories the token can reach, although MCP Studio only reads repository content. A GitHub App with selected repository access and read only permissions would provide tighter scope, but that migration is not complete.

GitHub OAuth tokens stored by MCP Studio do not currently have application level encryption. Database encryption at rest and SSL protect the storage and transport layers, but there is no separate encryption key protecting that column. This is a material limitation for private repository use.

Automatic account linking based only on matching email addresses is disabled. A second provider can still be linked while the user is already authenticated.

URL fetch controls

Websites and other user supplied URLs create a server side request forgery risk. MCP Studio resolves the destination hostname and rejects private, loopback, link local, and other internal addresses. It checks every resolved address and validates each redirect destination.

Redirects are followed manually. Authorization and Cookie headers are removed when a redirect crosses origins. This prevents credentials intended for one host from being forwarded to another host.

These controls reduce SSRF exposure, but they do not replace source level access controls. Only connect content that the resulting server is permitted to retrieve and return.

Source and account deletion

Disconnecting a source deletes:

• Indexed pages and embeddings
• Crawl records and pending indexing jobs
• Cached search results
• Stored request excerpts attributed to that source

Cache entries and telemetry excerpts require explicit cleanup because database cascades alone do not remove them. The purge runs before the source row is deleted. If cleanup fails, the source remains visible instead of reporting a successful disconnection while content survives.

Request records not containing source text remain subject to the retention schedule above. Reconnecting the source starts a new index and does not restore deleted history.

Requesting account deletion immediately marks the user's MCP servers as deleted, so their endpoints stop answering. Billing subscriptions are cancelled, and final account deletion is scheduled 24 hours later. The deletion job refuses to remove the user record while a live subscription remains, which prevents an active charge from losing its customer reference.

Controls currently implemented

MCP Studio currently has:

• Per server, revocable access tokens stored as hashes
• Authorization before handshake, discovery, and tool calls
• Server side private repository detection
• Explicit cleanup for indexed content, caches, and excerpts
• Defined telemetry retention
• Encryption in transit and at rest
• SSRF checks across DNS results and redirects
• Audit records for authentication, server lifecycle, credentials, and denied access
• Immediate endpoint shutdown when account deletion is requested

Material limitations

GitHub tokens lack application level encryption. A database compromise could expose usable OAuth tokens.

GitHub's repo scope is too broad. It is not limited to selected repositories or read only operations.

Audit logs are not tamper evident. They have no retention limit or automated alerting. A denied access spike does not page an operator, and the application can modify the same log it writes.

Sessions cannot be revoked centrally. Authentication uses signed session tokens rather than server stored sessions. Signing out clears the current device, but a copied token remains valid until expiration.

Rate limiting is IP based. Distributed callers can evade meaningful restriction by using multiple addresses.

No independent security assessment has been completed. MCP Studio has no third party penetration test, SOC 2 audit, or ISO 27001 certification.

Compliance documentation is incomplete. Data deletion exists, but processing agreements, a record of processing activities, and a documented data access request process are not complete.

There are no published completion dates for these items.

Decide against your requirements

Use a public server only for content intended for public retrieval. Use a private server and scoped access tokens for private content. Do not connect sensitive repositories if your requirements include application level OAuth token encryption, selected repository permissions, centrally revocable sessions, independent certification, or completed compliance documentation. MCP Studio does not meet those requirements today.

Before indexing private content, review the private server setup and source behavior. If the current controls fit your policy, you can create a server.