Transport security for MCP servers

The MCP specification defines two transport mechanisms:

• stdio transport— the host application spawns the MCP server as a child process. Messages are exchanged over the process's standard input and standard output streams as newline-delimited JSON-RPC. This transport is inherently local: the server runs on the same machine as the host.
• HTTP with Server-Sent Events (HTTP/SSE) transport — the host application connects to a remote MCP server over HTTP. Tool invocations are sent as HTTP POST requests. Server responses are returned as Server-Sent Events on a persistent HTTP connection. This transport enables remote and multi-tenant MCP servers.

The security requirements for each transport differ significantly because the threat model for a local process is fundamentally different from the threat model for a network service. A review that applies network security requirements to a stdio transport misses the relevant risks; a review that applies local process security thinking to an HTTP/SSE transport misses equally important ones.

The stdio transport runs entirely on the host machine. The MCP server is a process spawned by the host application, and the communication channel — standard I/O streams — is managed by the operating system. There is no network socket, no TLS configuration, and no certificate to validate.

The security questions for stdio transport are different: they are questions about process isolation, local file permissions, and the trust assumptions that come with running on the same machine as the host.

Process isolation

Can the MCP server subprocess be accessed or interfered with by other processes on the host? In a well-configured system, the child process inherits only the file descriptors the host explicitly passes — it is not directly addressable by other processes. In practice, poorly configured environments may allow other processes to send signals to the subprocess, attach a debugger, or read from the process's memory.

Review question: is the MCP server subprocess run with the minimum OS privileges required for its function? Does it run as the same user as the host application, or under a dedicated, lower-privileged account? In containerised environments, is the subprocess contained within the same container as the host, or isolated in its own container with a restricted communication channel?

Local file permissions

stdio MCP servers frequently need access to the local filesystem — to read configuration, access data files, or execute tools that interact with local resources. The file permissions granted to the server process define the scope of what a compromised or manipulated server can access.

Review question: does the MCP server process have access to more of the filesystem than its stated tools require? Are sensitive files (credentials, configuration, other applications' data directories) accessible to the server process?

HTTP/SSE transport exposes an MCP server over the network. The server listens on an HTTP endpoint; the host connects to it and maintains a persistent session. This transport is used for remote MCP servers, multi-tenant MCP services, and internal MCP servers deployed separately from the host application.

The network exposure introduces the standard set of network-layer security concerns: whether the channel is encrypted, whether the server's identity is verified, and whether the client's identity is verified.

Unlike REST APIs, the HTTP/SSE transport for MCP involves a long-lived connection (the SSE stream) alongside discrete HTTP requests (tool invocations). Security controls need to cover both the discrete requests and the persistent stream. Session management and connection state are relevant concerns that a point-in-time request-level review may miss.

TLS is the primary transport-level control for HTTP/SSE MCP deployments. It provides message confidentiality (messages cannot be read in transit), message integrity (messages cannot be modified in transit), and server identity verification (the server's certificate proves its identity to the connecting client).

The MCP specification does not mandate TLS. In assessed systems, HTTP/SSE MCP servers are frequently deployed without TLS in internal network environments, on the assumption that the internal network is trusted. This assumption is increasingly untenable — internal networks are not perimeter-protected environments, and a compromised internal host or a misconfigured network path can expose plaintext MCP traffic.

TLS for an HTTP/SSE MCP deployment requires:

• A valid certificate issued by a trusted certificate authority (CA) — either a public CA or the organisation's internal CA, depending on the deployment context.
• Certificate validation enabled in the MCP client — validation must not be disabled for development convenience and left disabled in production.
• TLS 1.2 minimum, TLS 1.3 preferred. Older protocol versions should be explicitly disabled in the server configuration.
• Certificate rotation before expiry, with an automated or alerted process.

In assessed systems, disabled TLS certificate validation is one of the most common transport control gaps. It is introduced during development — to avoid certificate management overhead in a test environment — and never re-enabled before deployment. A client with disabled certificate validation cannot verify server identity and is vulnerable to a server impersonation attack even when the connection appears to be over HTTPS.

Standard TLS verifies the server's identity to the client. Mutual TLS (mTLS) additionally verifies the client's identity to the server: both parties present certificates, and both parties validate the other's certificate.

For most MCP deployments, standard TLS combined with application-layer authentication (an API key or session token in the request headers) is sufficient. Mutual TLS is appropriate for deployments where:

• The MCP server is exposed to the internet and the cost of a compromised API key is high.
• The MCP server has access to highly sensitive data or capabilities, and the client identity must be cryptographically verified rather than token-verified.
• Regulatory or policy requirements mandate certificate-level authentication for the specific type of data the MCP server handles.

mTLS adds operational overhead: both sides require certificate infrastructure, certificate rotation must be coordinated, and client certificate provisioning must be managed. For internal MCP servers in most enterprise deployments, standard TLS with API-key authentication meets the security requirement without the added operational burden.

The following review questions should be addressed for each MCP transport type in scope:

For stdio transport

• What OS user account runs the MCP server subprocess?
• Does the subprocess account have least-privilege file system access?
• Can the subprocess be accessed by processes other than the intended host?
• In containerised deployments, how is the subprocess isolated?
• Does the subprocess have access to credential files, SSH keys, or cloud configuration?

For HTTP/SSE transport

• Is TLS enforced for all connections to this endpoint?
• Is certificate validation enabled and verified not to be bypassed?
• Is the certificate issued by a trusted CA and within its validity period?
• What protocol versions and cipher suites are accepted?
• Is there application-layer authentication (API key, session token) in addition to TLS?
• Is mutual TLS required? If so, how are client certificates provisioned and rotated?
• Is the endpoint accessible from the internet? If so, is the exposure intentional and justified?

A security review of the MCP transport layer should produce the following evidence:

• TLS configuration excerpt— the server's TLS configuration showing the protocol versions, cipher suites, and certificate reference.
• Certificate validation test result — confirmation that the MCP client rejects connections with invalid, self-signed (if not trusted), or expired certificates.
• Process permissions record (for stdio) — the user account and file system permissions of the MCP server subprocess.
• Network exposure confirmation — documentation of whether the MCP endpoint is accessible from the internet, from internal networks, or only from specific hosts.
• Authentication enforcement test — confirmation that unauthenticated requests are rejected.

For the full MCP security review, see An MCP server security review checklist.