MCP’s Stateless Rewrite Makes Agent Traffic Easier to Govern—but Not Safe by Default

2026-08-02 Security by al-ice.ai Editorial

The Model Context Protocol has shipped the stable version of its largest architectural revision since launch. The final 2026-07-28 specification removes MCP’s initialization handshake and protocol-level session identifier, makes each request self-describing, and puts the called method and tool name into standard HTTP headers. It also tightens several OAuth and OpenID Connect behaviors intended to stop authorization-server confusion and accidental credential reuse.

We covered the release candidate’s new attack surfaces and the shift of state-security decisions to implementers in June. The final release now makes that design operational, adds a concrete migration target, and exposes controls that deserve separate attention: issuer-bound credentials, gateway-visible tool identity, explicit cache scope, and request-bound multi-round-trip approval.

These changes give defenders better enforcement points and fewer hidden transport dependencies. They do not make an MCP deployment stateless in the security sense, authenticate requests automatically, or solve prompt injection. The final specification and matching Tier 1 SDK support were published July 28; the project’s GitHub release records stable tag commit 5f5440bb26a62e2cf3440b92da5a667efa03b267. This is a breaking protocol revision, not a transparent security patch for older clients and servers.

Sessions disappear from the protocol, not from the threat model

Earlier Streamable HTTP deployments began with initialize/initialized and carried an Mcp-Session-Id on later requests. Under 2026-07-28, that exchange and header are retired. Every request carries its protocol version and client capabilities in _meta; clients should also identify themselves on each request. Servers must implement server/discover for capability and version discovery, although clients do not have to call it before another operation.

The operational benefit is real. Any request can reach any compatible server instance behind an ordinary round-robin load balancer. Operators no longer need sticky routing or a shared transport-session store merely to preserve MCP protocol state.

Application state remains. The specification tells servers that need continuity to mint explicit handles—such as a browser, basket, job, or workspace identifier—and return them as tool results for the model to pass into later calls. That makes state visible and auditable, but it also turns the handle into a first-class authorization object. A bearer-like handle that is guessable, logged, exposed to an untrusted tool result, or accepted across users can become an insecure direct-object-reference path.

Defenders should therefore bind every handle to the authenticated principal, tenant, tool, and permitted operation; give it a short lifetime; prevent use after revocation; and avoid placing secrets inside a model-visible identifier. Stateless transport removes implicit affinity. It does not remove the need for server-side ownership checks.

Tool identity moves into headers where gateways can act on it

Streamable HTTP POST requests must now include Mcp-Method and Mcp-Name. A request calling a search tool, for example, exposes tools/call and search before a gateway parses the JSON-RPC body. The specification requires servers to reject a request when those headers disagree with the body.

This is the release’s most useful defensive engineering change. Gateways can build tool-aware allowlists, rate limits, telemetry, and step-up controls using ordinary HTTP infrastructure. A production policy can distinguish tools/list from tools/call, meter a costly query tool, deny an administrative tool at the edge, or route high-risk calls through additional inspection.

Headers are routing and policy inputs, not trustworthy claims by themselves. The server still has to compare them with the body and enforce authorization on the resolved operation. Intermediaries must preserve the headers without allowing an external client to smuggle duplicates or bypass normalization. Logs should record the authenticated subject, resource server, protocol version, method, tool name, outcome, and a trace identifier—while excluding tokens and sensitive arguments.

The OAuth changes close specific mix-up and credential-binding gaps

The authorization revision addresses a deployment pattern in which one MCP client connects to many resource and authorization servers. Authorization servers should return the iss parameter defined by RFC 9207, and clients must validate it when present before redeeming an authorization code. The maintainers describe this as a low-cost defense against authorization-server mix-up. The requirement is deliberately narrower than a guarantee: this release does not yet require clients to reject every response that omits iss, although the release-candidate guidance says a future version is expected to do so.

Persisted client credentials must also be keyed by the issuer that created them and must not be reused with another authorization server. This matters when a resource migrates, discovery changes, or a malicious endpoint tries to redirect registration and token traffic. The client should re-register rather than carrying credentials across issuer boundaries.

Dynamic Client Registration remains available for compatibility but is now formally deprecated in favor of Client ID Metadata Documents. While DCR remains, clients declare an appropriate OpenID Connect application_type, preventing desktop and CLI applications from being treated as web clients whose loopback redirect URIs are rejected. The revision also clarifies refresh-token requests, discovery suffixes, and how scopes accumulate during step-up authorization.

None of this authorizes a tool call on its own. OAuth establishes and constrains a client’s access to the MCP resource server; the MCP server must still map that identity to tenant, tool, argument, and downstream-data permissions. Token passthrough to another service remains a dangerous design because it blurs audiences and converts the MCP server into a confused-deputy boundary.

Cache scope becomes a confidentiality control

Results from tool, prompt, resource, and template listing operations—and from resources/read—now include ttlMs and a cacheScope value of public or private. Deterministic tool ordering and explicit freshness can reduce repeated catalog fetches and stabilize upstream prompt caches.

The security consequence is easy to miss. A wrongly labeled response can move a tenant-specific tool catalog or resource through a shared intermediary. “Public” must mean the result is safe to reuse across authenticated users, not merely that the endpoint was reachable. Cache keys should vary on every identity and policy attribute that can alter the result, and sensitive deployments should default to private scope until cross-user equivalence is demonstrated.

Cache invalidation also becomes part of revocation. Removing a user’s access or disabling a tool must prevent stale private results from continuing to advertise or expose data. A cached list is not authorization to execute what it names; every call and read still needs a fresh server-side decision.

Multi-round-trip approval improves traceability, not judgment

The specification replaces server-initiated sampling, elicitation, and roots requests with Multi Round-Trip Requests. A server processing a call can return resultType: "input_required" and identify the information or confirmation it needs. The client retries the original operation with inputResponses. Server-initiated requests are restricted to the processing of an active client request, linking a prompt to something the user or agent started.

This makes approval flows easier to correlate and removes the need for a permanently open bidirectional stream. It does not ensure that the person understands the side effect. Clients should display the resolved action, destination, identity, affected records, cost, persistence, and exact scope change—not an agent-authored summary. The retry must be bound to the original subject and operation, protected against replay, and invalidated when material inputs change.

Roots, Sampling, and Logging are deprecated under a new lifecycle policy, as is the legacy HTTP+SSE transport. They continue to work for at least the 12-month deprecation window, so mixed estates will remain common. Inventory and telemetry need to preserve protocol version; otherwise defenders cannot tell whether the session, routing, authorization, and observability assumptions of a request belong to the old or new design.

What MCP operators should change now

Inventory protocol versions before upgrading SDKs. Record every host, client, server, proxy, and gateway that speaks MCP. Test the breaking removal of initialization, session IDs, SSE resumability, and older task behavior before rollout.
Make gateway policy tool-aware. Validate a single canonical Mcp-Method and Mcp-Name, reject header/body disagreement, and authorize the resolved tool at both gateway and server.
Treat explicit handles as capabilities. Bind them to identity and tenant, enforce object ownership on every use, expire and rotate them, and keep their contents opaque and non-secret.
Pin OAuth state to issuer and resource. Validate iss when supplied, key registrations and credentials by issuer, re-register after issuer migration, enforce token audience, and never pass an inbound token blindly to a downstream API.
Default caches to private. Prove that a result is invariant across users before declaring it public. Include authorization context in cache keys and connect access revocation to invalidation.
Harden multi-round-trip consent. Bind replies to the original request and principal, expire request state, prevent replay, and show semantic consequences rather than raw tool arguments.
Preserve protocol-aware observability. Trace subject, issuer, resource, version, method, tool, decision, downstream target, and result without recording credentials or sensitive prompt data.
Keep prompt-injection controls outside the protocol. The revision changes transport and authorization mechanics. It does not make model-generated tool choices trustworthy; least privilege, argument validation, egress control, and independent confirmation remain mandatory.

MCP 2026-07-28 is a meaningful security improvement because it makes important facts explicit: which operation is being called, which protocol version governs it, which authorization server issued credentials, how cached data may be shared, and what additional input a server requires. Explicit facts are enforceable facts. But the protocol deliberately stops short of defining an organization’s authorization policy or deciding whether an agent’s requested action is safe. The new baseline is easier to govern—not safe by default.

Sources: