Stateless MCP: What the 2026-07-28 Specification Changes for Security and Identity

The 2026-07-28 MCP specification is the largest change to the protocol since it shipped. MCP was designed as a stateful, bidirectional connection: a client and server performed an initialize/initialized handshake, agreed protocol version and capabilities once, and thereafter shared a session identified by the Mcp-Session-Id header. The new revision removes all of that. MCP becomes request/response and stateless, every call carries its own context, and sticky sessions are gone.

Most of the commentary has framed this as an infrastructure story - and operationally it is a good one. But the security consequences are more interesting than the deployment ones, and they cut both ways: some real vulnerability classes close, and one new failure mode opens that is easy to build straight into a first implementation. This guide covers what changed, what it means for authorization, identity and audit, and what to check.

What actually changed

The practical upshot for operators is that any server instance can serve any request behind a plain round-robin load balancer. No session affinity, no sticky routing, no draining connections on deploy. For anyone who has run MCP at scale behind a proxy, that alone justifies the revision.

What gets safer

Three genuine improvements, and they are not marginal.

1. Session hijacking stops being a category. No session identifier means no long-lived bearer of authority to steal, replay or fixate. A leaked Mcp-Session-Id used to be a durable capability; now there is nothing equivalent to leak.
2. Header/body disagreement is now an error. Servers must reject requests whose Mcp-Method and Mcp-Name headers do not match the body. That closes a smuggling class where a gateway routes or authorizes on one value while the server acts on another - the same desync that produces request-smuggling bugs in HTTP proxies.
3. Policy enforcement gets cheaper and more reliable. Because method and tool name are in headers, a gateway can make an allow/deny decision without parsing a JSON body. Less parsing means fewer parser-differential bugs between your gateway and your server, and it makes per-tool rate limiting and authorization practical at the edge - relevant if you run an AI gateway or proxy.

What gets riskier

Authorization has to be re-decided on every request, and identity is now something the client asserts. Those two facts together are where implementations will go wrong.

Under the old model it was tempting - and workable - to authorize at handshake and treat the session as trusted thereafter. That shortcut is now impossible, which is an improvement. But the replacement has a trap: client identity and capabilities arrive in _meta on each request, and _meta is transport-level metadata supplied by the caller. It is a *claim*. If a server reads the client identity out of _meta and uses it for authorization decisions or writes it into an audit log without binding it to the authenticated principal - the OAuth token, mTLS certificate, or whatever actually establishes who is calling - then it has built self-reported identity into its security decisions. An attacker with any valid credential can then present themselves as a different client.

This matters especially for audit. An agent-layer audit trail is only worth what its identity field is worth, and *the caller told us who it was* is worth very little under scrutiny. If you are relying on that record for ISO 42001 or NIST AI RMF evidence, the identity in each entry needs to derive from authentication, with the _meta claim recorded separately as what the client asserted. The distinction is small in code and large in an audit. Our OAuth for MCP servers guide covers establishing the authenticated principal, and AI gateway OAuth passthrough covers what happens to it in transit.

The second new surface is MRTR. Multi Round-Trip Requests restore interactivity to a stateless protocol: a server can return resultType: "input_required" along with the things it needs answered, and the client retries the original call with the answers attached in inputResponses. This is a sensible design. It also formalises a channel in which a server asks a client for input, and the text of that request reaches the model. Treat input_required prompts as untrusted content, exactly as you would a tool result - this is the delivery path that MCP tool poisoning and indirect prompt injection already exploit, and DuneSlide showed a zero-click RCE arriving via an MCP response. A server that can prompt for input can ask for a credential and have the request look like protocol.

Migration checklist

• Confirm which spec revision each of your MCP servers and clients implements. Mixed fleets are the normal state during a transition, and the two models have different security assumptions - do not reason about them as one system.
• Audit every place your servers read client identity or capabilities from _meta. Bind identity to the authenticated principal for any authorization decision, and record the _meta claim as an assertion rather than a fact.
• Remove any authorization shortcut that assumed a session. If a decision was made once per connection, it now needs making per request.
• Move gateway routing, metering and allow/deny to Mcp-Method and Mcp-Name headers, and verify your gateway and server agree on the values - the spec requires servers to reject mismatches, so a disagreement should now fail loudly rather than diverge quietly.
• Treat MRTR input_required prompts as untrusted input in the model's context. Never wire an automatic responder that can supply credentials or approve actions without a policy check.
• Re-check rate limits and quotas. Stateless means retries and MRTR round trips multiply request counts, so limits tuned per-session will behave differently per-request.
• Re-examine your audit schema so each entry carries the authenticated principal, the asserted client identity, the method and the tool name - which the headers now make straightforward to capture.
• Reconcile the servers your fleet actually talks to against a reviewed set, per building an MCP server registry. A protocol change is a good moment to discover which servers exist.

Where Anomity fits

A protocol revision does not change the underlying governance problem: an MCP server is a program launched with a user's permissions, and most organisations cannot enumerate the ones running on their endpoints. MCP servers are one of the eight AI artifact types Anomity inventories per endpoint - alongside AI agents, extensions, plugins, skills, secrets, hooks and CLIs - which is what makes "which servers do we talk to, and which revision do they speak" an answerable question rather than a survey.

The stateless model also makes the enforcement point cleaner. Because every request is self-describing, the tool call is the natural unit of decision - which is where Anomity already operates. Where an agent exposes a hook, such as the PreToolUse event in Claude Code, each call is evaluated against policy and returns allow, deny, or log before it runs, and decisions land in a queryable 90-day audit trail with the method and tool name that the new headers make explicit. That is runtime governance reading the same fields your gateway now routes on. Anomity collects metadata only, with on-endpoint secret redaction, is SOC 2 Type II, and complements EDR, DLP, network and GRC tooling.

You can't govern what you can't see.The Anomity principle

The 2026-07-28 revision is a good change badly served by being described as an infrastructure upgrade. Dropping sessions removes a hijacking class and makes edge policy enforcement genuinely practical. But it relocates identity into per-request metadata that the caller supplies, and adds a sanctioned channel for servers to prompt clients - so the work is to bind identity to authentication and treat MRTR prompts as untrusted. Get those two right and the new model is stricter than the old one. Get the first wrong and your audit trail records whatever the caller claimed. For the full trust model see the MCP Server Security guide, for identity foundations AI identity security explained and non-human identity governance, and for lifecycle placement ADLC. To see which MCP servers your fleet actually runs, request early access.