← Blog

stdio vs SSE MCP Transport Security

15 Research Lab
mcp-safetydefensetools

MCP supports two transport mechanisms: stdio and SSE (Server-Sent Events over HTTP). They serve different deployment patterns and have fundamentally different security characteristics.

stdio Transport

The MCP server runs as a child process of the client. Communication happens through the process's standard input and standard output streams.

Security properties:

  • No network exposure. The server is not reachable from the network.
  • Process-level isolation provided by the operating system.
  • The client controls the server's lifecycle (spawn, kill).
  • No authentication protocol needed because the client spawned the process.

Limitations:

  • Single-client only. Each client spawns its own server process.
  • Cannot share a server across multiple agents or users.
  • The server runs with the same privileges as the client process.
  • No built-in encryption (not needed since communication stays in-process).

When to use stdio: Local development, single-user tools, CLI applications, any situation where the agent and tools run on the same machine under the same user.

SSE Transport

The MCP server runs as an HTTP service. The client connects to it over the network using Server-Sent Events for the streaming channel and HTTP POST for tool calls.

Security properties:

  • Network-accessible. Must be protected with authentication and TLS.
  • Supports multi-client and multi-user deployments.
  • Can be deployed behind load balancers, gateways, and firewalls.
  • Scales independently of the client.

Required security controls:

  • TLS encryption for all connections. No exceptions.
  • Authentication on every request. Bearer tokens or OAuth 2.0.
  • CORS headers restricted to expected origins.
  • Rate limiting per authenticated identity.
  • Network segmentation to limit server exposure.

Limitations:

  • MCP itself does not define an authentication standard. Implementers must add it.
  • SSE connections are long-lived, requiring careful timeout and cleanup handling.
  • Connection management adds operational complexity.

When to use SSE: Multi-user production deployments, shared tool servers, cloud-hosted tools, any situation where the agent and tools run on different machines.

Security Comparison

| Property | stdio | SSE | |----------|-------|-----| | Network exposure | None | Full (must be secured) | | Authentication | OS process isolation | Must be implemented | | Encryption | Not needed | TLS required | | Multi-user support | No | Yes | | Scalability | Single process | Horizontally scalable | | Attack surface | Local privilege escalation | Network attacks, auth bypass, injection |

The Deployment Gap

The security gap is not in the transports themselves but in the transition from development to production. Teams build with stdio locally (no auth needed), then deploy with SSE in production without adding the authentication and encryption that SSE requires.

Every SSE deployment checklist should verify: TLS enabled, authentication enforced, CORS configured, rate limits set, audit logging active, gateway in place. Missing any one of these creates an exploitable gap.