MCP 2.0 makes agent traffic stateless, but not automatically safer

At a glance

What this is: This is an analysis of MCP 2.0, which replaces session-bound protocol behavior with stateless per-request metadata and header-based routing.

Why it matters: It matters because identity, authorization, and logging controls for AI tool access now have to operate on every request, not on a remembered session context.

By the numbers:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
• 53% of MCP servers expose credentials through hard-coded values in configuration files.

👉 Read Highflame's analysis of MCP 2.0 stateless requests and header routing

Context

Model Context Protocol has become the connective tissue between agents and external tools, which makes its identity and access model a governance issue rather than a transport detail. MCP 2.0 shifts the protocol from sticky sessions to stateless requests, so the control question changes from what a connection remembers to what each request proves about itself.

For IAM and NHI programmes, that shift matters because tool access is no longer anchored to a long-lived session object. The security model now depends on per-request identity fields, declared capabilities, and infrastructure that can inspect and enforce policy without relying on state hidden in the transport.

The article argues that this change improves scalability and operational clarity, but it also moves more trust into client-supplied metadata and requestState handling. That is a more legible architecture, yet it still leaves the harder question of whether the request should be allowed to execute at all.

Key questions

Q: How should security teams govern MCP requests without relying on session state?

A: Treat each MCP request as a standalone identity event. That means binding authorization to the credential, token scope, and actor claims rather than to conversation history. Teams should assume the connection may change, the server instance may change, and the identity decision must still be verifiable on every call.

Q: What breaks when gateways trust MCP headers without validating the body?

A: Header-only enforcement creates a desynchronisation risk. If the body and headers disagree, a request can be routed or permitted on the wrong assumption, which undermines both authorization and audit accuracy. The safe pattern is to pin the protocol version first, then compare mirrored values before any downstream decision is made.

Q: When does requestState become a security risk in MCP deployments?

A: requestState becomes risky when it can influence authorization, resource access, or business logic without integrity protection. Because the client carries it across calls, it must be bound to the principal, limited by TTL, and verified on receipt. Without that, it behaves like attacker-controlled input rather than protected context.

Q: What should teams do when MCP workflows still need continuity across calls?

A: They should move continuity into ordinary application state and make it explicit, such as a queryId or job identifier stored server-side. That keeps lifecycle, logging, and policy visibility intact. Transport state is no longer the right place to hide workflow context in a stateless MCP model.

Technical breakdown

Stateless MCP requests and per-request identity metadata

MCP 2.0 removes initialize-based session negotiation and replaces it with request-scoped metadata inside params._meta. Each request declares protocol version, client capabilities, and optional client info, while results carry server identity in their own _meta. That design lets ordinary infrastructure route, meter, and validate traffic without maintaining connection state. The tradeoff is that identity information becomes declarative and self-reported, so it is useful for routing and debugging but not for trust decisions. Practical implication: treat the metadata as policy input, not proof of authorization.

Practical implication: Use per-request metadata for routing and logging, but do not treat self-reported identity as an authorization control.

Header mirroring, gateways, and policy enforcement

The new specification mirrors selected request fields into HTTP headers such as MCP-Protocol-Version, Mcp-Method, and Mcp-Name. That gives gateways and WAFs enough structure to apply per-tool policy, rate limits, and routing without parsing JSON bodies on every request. It also introduces a new class of control dependency: header values must match body values, and the version must be pinned before any enforcement logic trusts the headers. In other words, observability improves, but only if middleware validates both representations consistently. Practical implication: enforce body-header consistency before policy decisions are made.

Practical implication: Validate mirrored headers against the body before applying authorization, routing, or metering rules.

requestState, resumability, and replay boundaries

MCP 2.0 pushes multi-turn state into requestState and removes SSE resumability. requestState is no longer a transport-owned session pointer; it is server-authored state that the client carries back, which means it must be integrity-protected and bound to the principal and request context. The spec’s recommended HMAC or AEAD protections are there because the value can influence authorization or business logic. Once resumable streams disappear, replay and continuation handling move out of the transport layer and into explicit server state. Practical implication: sign any server-authored state and define replay handling as part of application logic, not transport behavior.

Practical implication: Protect requestState with integrity controls and assume lost streams require a fresh request, not transport recovery.

Threat narrative

Attacker objective: The objective is to make an unauthorized or misrouted tool invocation look policy-compliant long enough to execute.

1. Entry occurs when a client presents well-formed MCP requests that appear legitimate to the server and any gateway in front of it.
2. Escalation occurs when mirrored headers, requestState, or declared capabilities are trusted without consistent validation against the body and the allowed policy context.
3. Impact occurs when a tool call executes with incorrect routing, stale state, or overbroad access, allowing unintended data exposure or tool misuse.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Stateless transport does not remove identity governance, it exposes it. MCP 2.0 makes every request declare its own identity context, but that is not the same as proving authority. The governance problem shifts from session stewardship to request stewardship, which is a stricter and more visible burden for IAM and NHI teams. Practitioners should read this as a demand for per-request policy enforcement, not as a simplification of trust.

Request metadata becomes a control plane, but only if it is treated as untrusted input. Headers, _meta fields, and requestState can support routing and policy, yet they are all either self-reported or client-carried. The named concept here is request-bound identity drift: control decisions start to diverge from the actual request when infrastructure trusts copied metadata more than validated intent. That drift is now the central failure mode to watch in MCP deployments.

The protocol’s biggest governance gain is also its biggest accountability loss. Removing connection state makes tooling easier to scale, but it also removes a convenient place to hide weak lifecycle thinking. Access decisions now have to stand on their own at each call boundary, which is better for auditability and worse for any programme that relied on session memory as a substitute for explicit entitlement design.

MCP 2.0 strengthens observability without closing the authorization gap. A gateway can now see the method and tool name clearly, but visibility is not authorization. That distinction matters because tool invocation is still a policy question, not a transport question. The implication is that MCP security will increasingly live in the surrounding identity and policy stack, not in the protocol alone.

Per-request capability declarations create a more honest model of agent access. The old model assumed the connection could remember who the client was and what it could do. The new model forces those claims into each request, which is operationally cleaner and governance-friendly. Practitioners should use that clarity to tighten entitlement review, audit trails, and least-privilege boundaries for both NHI and agentic workloads.

From our research:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to the State of MCP Server Security 2025.
• 53% of MCP servers expose credentials through hard-coded values in configuration files.
• The governance answer is to pair request-level controls with lifecycle discipline, as outlined in the Ultimate Guide to NHIs , 2025 Outlook and Predictions.

What this signals

request-bound identity drift: MCP 2.0 makes the request itself the primary governance object, which means teams must watch for places where copied metadata starts to outrun validated entitlement. The practical shift is toward enforcing policy at the gateway and identity layers together, with clear separation between routing signals and trust decisions.

With 80% of organisations already reporting AI agents acting beyond their intended scope in the SailPoint research, the surrounding control stack cannot assume that a tool call is low risk just because it is well formed. That makes protocol clarity useful, but only when it is paired with identity controls that can decide whether the action should happen at all.

MCP 2.0 also creates a cleaner place to anchor audit and lifecycle controls, because tool names and methods are now visible before execution. Teams that align this with the NIST AI Risk Management Framework will be better positioned to separate observability from authorization and avoid treating telemetry as a substitute for control.

For practitioners

• Validate every request independently Require version, client capabilities, and tool context to be checked on each call before any routing or authorization decision. Do not rely on connection memory or prior handshake state.
• Treat requestState as protected state Bind server-authored requestState to the authenticated principal, add a short TTL, and verify integrity before accepting it in later calls.
• Move policy to the gateway layer Use Mcp-Method and Mcp-Name for per-tool rate limiting, audit, and authorization so the JSON body is not the only place policy can be enforced.
• Review trust in mirrored headers Compare mirrored headers with body values and reject any mismatch before the request reaches downstream tools or data sources.
• Rework stateful tool flows explicitly For workflows that still need continuity, store state in ordinary application objects such as query IDs rather than in transport session fields.

Key takeaways

• MCP 2.0 removes session dependence, but governance still has to happen at the request boundary.
• Header mirroring improves infrastructure visibility, yet it also raises the stakes for consistency checks and trust validation.
• Identity teams should redesign MCP policy around per-request enforcement, protected state, and explicit tool entitlements.

Key terms

• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• RequestState: Opaque state carried across a multi-round-trip authorization flow so a client can resume a partially completed request. It is not a credential, but it can become a security object if teams encode trust decisions into it instead of treating it as integrity-protected lookup data.
• Header mirroring: Header mirroring is the practice of copying selected request fields into HTTP headers so gateways can route and enforce policy without parsing the full JSON body. It only works safely when the headers are validated against the body and the protocol version is pinned.
• Request-bound identity drift: Request-bound identity drift happens when infrastructure trusts copied metadata more than the actual request context. In MCP environments, that can cause authorization, routing, and audit decisions to diverge from the tool call that really executes.

What's in the full article

Highflame's full analysis covers the operational detail this post intentionally leaves for the source:

• Header-by-header examples showing how MCP-Protocol-Version, Mcp-Method, and Mcp-Name are mirrored and validated in practice.
• The migration checklist for dual-era clients and servers that need to support both legacy session semantics and the new stateless model.
• Detailed guidance on requestState handling, including integrity protection and replay bounds for multi-turn workflows.
• The protocol-specific handling of subscriptions, caching hints, and long-running task patterns that were only summarised here.

👉 The full Highflame post covers the protocol changes, migration steps, and enforcement details in more depth.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or NHI programme, it is worth exploring.