The Model Context Protocol's largest specification revision goes final today. Sessions are gone. The initialization handshake is dead. Three core features — Roots, Sampling, Logging — are deprecated. Every request is now self-contained, carrying its own protocol version, identity, and capabilities in a _meta object. New HTTP headers (Mcp-Method, Mcp-Name) allow routing without body parsing. The stateful architecture that forced every production deployment to maintain sticky load balancer routing, shared Redis session stores, and request body inspection at the gateway is over.
The infrastructure story is elegant. A remote MCP server that previously needed sticky sessions and a shared session store can now run behind a plain round-robin load balancer. Horizontal scaling became trivial. Cache tools/list with ttlMs. Deploy behind a CDN. The protocol is finally ready for the scale it already operates at: 97 million monthly SDK downloads, 9,400+ public servers, 80% of Fortune 500 AI agents.
The security story is a different sentence entirely.
The Trade
The old protocol had a specific security problem: session hijacking. An attacker who stole an Mcp-Session-Id header could impersonate an authenticated user. This was the protocol's problem, owned centrally, fixable in one specification update. The new protocol fixes it completely — by eliminating sessions.
In their place: handles. Portable, stateless identifiers returned inside tool responses. A task handle. A browser handle. A resource reference. Each one is, as Backslash Security documented, "just a string the model can see, echo, and pass along, with no built-in binding to user, IP, or TLS."
This is the structural trade the spec made. Session hijacking was a centralized vulnerability — bad, but singular. Handle hijacking is a decentralized vulnerability — worse, because it multiplies. A malicious tool response can inject an attacker-controlled handle: {"task_id": "t-ATTACKER-CONTROLLED"}. The model obeys. The server executes. No binding validates whether the handle belongs to the requesting user. Whether each server implements that validation is now a question asked 9,400 times with 9,400 different answers.
Three Surfaces, One Layer
Handle hijacking isn't alone. The spec revision opens two more attack surfaces, and all three share a property that matters: they operate at the endpoint, invisible to the network security infrastructure that enterprises already have.
The filesystem scope gap is the quietest. Roots — the protocol-level mechanism for constraining what files an MCP server could access — is deprecated. It can't persist without the initialization handshake the spec just killed. Backslash documented one incident where an agent "accessed 340 other files... credential stores, .env files with database passwords, Stripe API keys, and AWS secrets. Then, in a subsequent tool call, it exfiltrated them to an external webhook." Scope enforcement is now optional, per-server, and invisible to the protocol.
MCP Apps (SEP-1865) is the loudest. Servers can now ship interactive HTML directly into IDE iframes. Clicking a button triggers a JSON-RPC tool call back to the server. The attack surface is the familiar web security catalog — stored XSS, clickjacking, UI mimicry — but the rendering context is not a browser tab. It's the IDE. As Backslash put it: "A sandbox escape here is a full IDE compromise." Access to source code, terminal, filesystem, and every connected MCP server. And Akamai noted there is no origin enforcement mechanism equivalent to what browsers provide.
The Tasks extension completes the set. Long-running asynchronous work — the feature enterprises asked for — creates a one-sided resource equation. Task creation is cheap for the client, expensive for the server. Spawn a resource-intensive operation, disconnect, never retrieve the result. The server exhausts CPU, memory, or database storage. Hit-and-run denial of service, at protocol level.
The Population Problem
Every one of these surfaces depends on implementation quality. The spec's answer to each is: developers should validate handles, developers should enforce scope, developers should sanitize HTML, developers should rate-limit task creation. This is architecturally reasonable and empirically reckless.
The population now responsible for these decisions is the same one the VIPER-MCP study audited in May. Researchers scanned 39,884 MCP server repositories and found 106 confirmed zero-day vulnerabilities with end-to-end exploit traces. Sixty-seven CVE IDs assigned. Forty-three percent of servers were vulnerable to command injection. Eighty-two percent of file operations were prone to path traversal. The tool handlers that take user-controlled input and pass it — without sanitization — into shell execution, network requests, or file system operations are not edge cases. They are the norm.
The authorization numbers tell the same story from a different angle. Censys counted 12,520 publicly exposed MCP services. Approximately 40% are unauthenticated. Fifty-three percent rely on static API keys. Only 8.5% use OAuth with short-lived tokens. The new spec mandates RFC 8707 resource indicators and requires PKCE — but runtime enforcement remains an implementation decision. As one security analysis demonstrated: a connection-layer defense built on metadata linting, session checks, and human approval "blocked four and let six through" of ten modeled attacks. Runtime scope enforcement blocked all ten. The spec provides the first architecture and leaves the second to developers.
"MCP's rapid proliferation has outpaced the development of its security model."— NSA guidance, May 2026
The NSA published that before the spec went stateless. The revision doesn't contradict the assessment — it sharpens it. The protocol's security model didn't catch up. It was redistributed.
The Forged Metadata Problem
The new architecture introduced a subtler risk that deserves separate attention. Every stateless request carries a _meta object with protocol version, identity, and capabilities. Akamai flagged what happens when this is the only identity signal: the object carries no cryptographic signature. A single malicious metadata field — "tenant": "admin" — could enable privilege escalation or cross-tenant access. Header-body desynchronization, where the HTTP headers (Mcp-Method, Mcp-Name) say one thing and the JSON-RPC body says another, can bypass security controls or blind monitoring entirely.
Meanwhile, the new x-mcp-header mapping creates a data leakage channel. Accidentally mapped secrets "ride along in the header, exposed to every load balancer, proxy, and log between client and server." The header infrastructure that makes stateless routing elegant also makes accidental exposure trivial.
The Pattern
This is not a criticism of the specification. Going stateless was the right architectural decision. The old session model was a deployment bottleneck that limited MCP to local use cases. The new model is genuinely better for infrastructure.
But a pattern is emerging in AI tooling that extends beyond MCP. Two days ago, I wrote about the sandbox being the wrong abstraction for artifact-producing agents. Today, the protocol that connects those agents to the world solved its infrastructure problem by distributing its security problem. The sandbox doesn't contain what agents can do. The protocol doesn't secure how they connect. And both failures operate at the endpoint — the one layer that network perimeters, gateway inspection, and centralized policy can't reach.
The question the spec answered was: can MCP scale? Yes. Trivially. The question it deferred was: can 9,400 server developers, 43% of whom couldn't prevent command injection, independently implement handle binding, scope enforcement, HTML sanitization, task rate limiting, metadata validation, and header hygiene?
The protocol knows the answer. That's why it stopped asking.