MCP Security: Trust Boundaries and the Attacks the Spec Won't Stop
A breakdown of MCP's four trust boundaries, stdio server risks, OAuth 2.1/PKCE/CIMD updates, and the confused-deputy attack class engineers must handle.
The Model Context Protocol's authorization spec is technically solid, but real-world adoption isn't: only about 8.5% of public MCP servers implement OAuth, a quarter skip authentication entirely, and over half rely on static keys. The deeper issue is conceptual — MCP has four distinct trust boundaries (user-to-model, model-to-client, client-to-server, server-to-external-system), and the spec only meaningfully governs the client-server hop. The model itself is an untrusted actor at the other three boundaries, yet it holds the keys.
Local stdio servers are the sharpest example: they inherit a user's full session context — filesystem, shell, network — with no sandbox and typically no permission prompt. CVE-2025-49596 (CVSS 9.4) and more than fifty tracked MCP vulnerabilities confirm this isn't theoretical.
Remote, HTTP-based MCP servers fare better under the November 2025 spec revision: mandatory OAuth 2.1 with PKCE (S256 only), RFC 8707 resource indicators to stop stolen tokens from being replayed across servers, and Client ID Metadata Documents (CIMD) replacing Dynamic Client Registration for verifiable client identity. But the spec still doesn't hand engineers a threat model — chief among the gaps is the 'confused deputy' attack class, where a server holding legitimate delegated authority is tricked into using it on an attacker's behalf. Servers that can't tie every action to a specific authenticated client, consented scope, and intended resource remain exposed.