Separate MCP transport security boundaries

Protocol roles

The MCP host manages users, permissions, model context, and client instances. An MCP client maintains one connection to an MCP server. The server publishes tools, resources, and prompts. The 2026-07-28 protocol revision supports standard transports including stdio and Streamable HTTP.

With stdio, the client launches or connects to a local server process and exchanges protocol messages through standard input and output. The trust boundary is local process execution: executable path, package source, working directory, environment, inherited file descriptors, credentials, user account, and operating-system permissions.

With Streamable HTTP, client and server communicate across HTTP. HTTPS service identity, network route, HTTP origin checks, protected-resource metadata, OAuth, token audience, and server authorization apply. Do not copy the remote OAuth model onto stdio and assume it protects local process execution.

Message flow

For stdio, the host selects a reviewed executable and immutable version, starts it under a restricted operating-system identity, passes a minimal environment, and exchanges one JSON-RPC message per line or according to the current transport rules. The server must keep logs and diagnostics off the protocol output channel. The host validates capabilities and applies local permission before exposing tools to the model.

For Streamable HTTP, the client connects to an authenticated server endpoint. Under the 2026-07-28 revision, requests carry Mcp-Method and Mcp-Name headers that must agree with the message. The server validates the Origin header where required to defend local deployments against DNS rebinding. Remote authorization follows the MCP OAuth resource model. The server validates the access token for itself before it handles the operation.

The 2026-07-28 core is stateless at the protocol layer. Application state must be explicit and authorized. Do not rely on a hidden transport session as the only binding between users and tasks.

Validation and failure cases

For stdio, verify the executable and package source, use an explicit absolute path, restrict configuration writes, remove unneeded environment variables, isolate filesystem and network, avoid inherited bearer credentials, and terminate child processes. Test a replaced binary, malicious current directory, environment secret, protocol data on stderr or logs on stdout, path injection, and child process that survives host exit.

For Streamable HTTP, validate TLS name, exact server and resource identity, Origin policy, protocol version, content type, method and name headers, message size, issuer, token audience, time, and current permission. Test DNS rebinding to localhost, hostile browser origin, wrong token audience, header-body mismatch, redirect to another host, deprecated transport fallback, and request replay.

Never accept an HTTP URL because the same server also supports stdio. Never launch a local executable because its remote server name is trusted.

Design tradeoffs and residual risk

Stdio avoids a listening network service and grants the local server the host process's reachable resources. Streamable HTTP supports remote services and centralized gateways and adds network, OAuth, metadata, and web-origin threats. Containerizing a local server narrows host access and still requires image provenance, volume, socket, and network controls.

Header-based routing improves gateway visibility. It does not authorize a tool by itself. A local server can be malicious despite a correct protocol. A remote server can be authenticated and still return poisoned tool metadata or results.

Pomerium boundary

Pomerium can protect remote MCP HTTP routes and manage documented authorization and upstream OAuth behavior. It does not mediate a local stdio process unless that process separately calls a protected route. The agent host owns local executable trust, operating-system isolation, environment, files, and process lifecycle.

Exercise

Deploy the same simple MCP server once through stdio and once through Streamable HTTP. Draw the different identities, credential paths, executable or network trust, policy points, and logs.

Run the stdio and HTTP negative tests. Confirm that a control from one transport does not create a false claim in the other. Record the exact MCP revision and reject unplanned fallback.

Evaluation checklist

• Is the deployment pinned to MCP revision 2026-07-28 or an explicitly supported revision?
• Are stdio executable and operating-system controls separate from remote OAuth controls?
• Do Streamable HTTP requests validate origin, resource, audience, protocol headers, and route?
• Are local environment, files, credentials, child processes, and network restricted?
• Can transport fallback or confusion never weaken the selected boundary?