TL;DR: The 2026-07-28 MCP revision removes session state, adds per-request metadata and headers, and makes tool traffic readable by gateways and load balancers, according to Highflame. It shifts replay and integrity risks into requestState and other client-supplied fields, making the protocol easier to scale but leaving governance dependent on whether identity, capability, and authorization are enforced at the right layer.
At a glance
What this is: This is an analysis of MCP 2.0’s stateless request model and the security trade-offs created by pushing identity, capability, and routing signals into per-request headers and metadata.
Why it matters: It matters because IAM, PAM, and NHI teams now have more inspectable request paths, but also a larger burden to validate client-declared state and enforce authorisation at the right layer.
Context
Model Context Protocol has become a common integration layer for agents and tools, but its original stateful design carried over from local stdio into remote deployments, creating sticky-session and replay burdens that do not fit ordinary web infrastructure. In identity terms, the question is not whether the transport is cleaner, but whether request-level metadata is sufficient to govern who or what is allowed to act.
The revised specification makes MCP fully stateless by moving protocol version, client identity, and declared capabilities into each request. That changes the governance problem for NHI and agentic AI programmes: routing becomes easier to inspect, while trust moves from connection state to per-request validation and integrity controls.
Key questions
Q: What breaks when MCP servers rely on session-bound state or the initialize handshake?
A: Older draft patterns fail when a request lands on a different instance or when client capabilities change between calls. Session IDs can hide state dependencies, and one-time handshake logic can miss per-request context. The result is brittle routing, inconsistent authorization decisions, and migration problems that only appear under load, retries, or partial outages.
Q: Why do stateless MCP headers not solve authorisation on their own?
A: Because headers make the request easier to inspect, not inherently trustworthy. Mcp-Method and Mcp-Name can help route and meter traffic, but they do not prove that the caller is entitled to run the tool. Authorisation still needs an independent decision based on identity, capability, and policy context.
Q: How do teams know whether MCP policy is being enforced at the right layer?
A: A good indicator is whether policy still works when the body changes but the header stays the same, and whether version pinning blocks downgrade or desynchronisation attempts. If enforcement depends only on mirrored headers without validating the declared protocol version, the control is too weak to trust.
Q: What should security teams do when a tool call depends on requestState?
A: Treat requestState like a sensitive bearer artefact and verify it before any business logic runs. It should be bound to the authenticated principal, a short TTL, and the originating request so a client cannot replay it across users or extend its usefulness beyond the intended exchange.
Technical breakdown
How stateless MCP changes transport and routing
MCP 2.0 removes the need to preserve session context across requests. Each call carries version, client metadata, and declared capabilities in params._meta, while HTTP headers mirror method and tool information for intermediaries. That lets load balancers, gateways, and policy engines act on visible request attributes instead of parsing the full JSON body. The protocol also drops server-initiated JSON-RPC requests, SSE session IDs, and resumability, which simplifies the wire but shifts any stateful behaviour into explicit tool arguments or separate protocol extensions.
Practical implication: enforce policy on the request fields MCP now exposes, and treat any remaining state as application-owned rather than transport-owned.
Why requestState is the new control point
The spec moves multi-turn coordination into requestState, which the server mints, the client returns, and the server must verify. That makes it closer to a signed client-held token than a connection pointer. Because the server does not control the client’s copy, the payload must be integrity-protected and bound to the authenticated principal, a short TTL, and a request identifier to reduce replay and cross-user reuse. This is the protocol’s main trust boundary, because anything that depends on requestState is now exposed to client-side handling and intermediary inspection.
Practical implication: treat requestState as attacker-influenced input and verify integrity, principal binding, and expiry before any access decision.
Why headers help infrastructure but do not authorise tool use
MCP now lets infrastructure see Mcp-Method, Mcp-Name, and selected parameter values before the body is parsed, which improves routing, metering, and logging. That is useful, but the spec is explicit that clientInfo and serverInfo are self-reported and not security signals. The header/body mirroring also creates a new desynchronisation risk if gateways trust headers without checking the declared protocol version. In other words, observability improved, but authorisation still needs a separate decision layer that evaluates identity, capability, and context.
Practical implication: use headers for policy enforcement only after version pinning and body validation, never as proof of identity or entitlement.
Breaches seen in the wild
- Nx s1ngularity attack 2025: Attackers stole Nx's npm token via a GitHub Actions flaw and shipped malware that stole 2,349 secrets and abused developers' AI CLIs.
- Sentry MCP Agentjacking 2026: Researchers showed a fake Sentry error, posted with a public DSN, could make AI coding agents run attacker code with developers' credentials.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Stateless transport does not remove identity trust, it relocates it. MCP 2.0 makes the wire easier to inspect, but it does not answer the governance question of whether a client should be allowed to invoke a tool in the first place. The field now has clearer request metadata, yet the security decision still belongs above the transport, where identity and authorisation are evaluated together. Practitioners should stop equating protocol statelessness with control completeness.
requestState creates a client-held trust boundary, not a server-held one. The server writes the state, but the client returns it, which means replay resistance and integrity are now part of the identity problem. This is the sort of pattern that NHI governance often underestimates because it looks like transport housekeeping. The practical conclusion is that any server-owned context that crosses a client boundary must be treated as a credential-like artefact.
Self-reported identity fields are operationally useful and security-wise weak. clientInfo and serverInfo help logging and troubleshooting, but the protocol does not verify them and explicitly says not to make security decisions from them. That is a useful reminder for gateway design: observability data and trust data are different classes of signal. Teams that blur them will end up with policy that is easy to bypass and hard to audit.
MCP 2.0 sharpens the case for request-layer governance, not transport-layer optimism. The most valuable shift is that tool intent is now legible to infrastructure, which means per-tool policy, metering, and audit are more practical than before. But the protocol still cannot determine whether an agent, user, or workload should run the action. Practitioners need to treat the spec as an enabler for governance, not as governance itself.
From our research library:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- Read next: MCP Security Guide
What this signals
Ephemeral request governance: MCP 2.0 moves the control problem from connection state to per-request state, which makes lifecycle governance more visible but also more urgent. Once the client, gateway, and server all see the same request metadata, teams can enforce per-tool policy earlier in the path instead of relying on hidden transport assumptions.
The remaining risk is not transport state, but trust in client-supplied context. Any programme that handles non-human identities through MCP should review where it still assumes a stable session, because that assumption is exactly what the revision removes.
For practitioners
- Validate per-request identity metadata Require protocolVersion, clientCapabilities, and server-returned identity fields to be present and consistent on every modern request before any policy decision is made.
- Protect requestState as a sensitive token Bind requestState to the authenticated principal, a short TTL, and the originating request digest, then reject any value that fails integrity checks or appears cross-user.
- Enforce tool policy at the gateway layer Use Mcp-Method and Mcp-Name for routing, rate limits, and audit, but only after pinning the protocol version and validating mirrored headers against the body.
- Separate observability data from trust decisions Treat clientInfo and serverInfo as display and logging fields only, and keep them out of authorisation logic, capability decisions, and risk scoring.
Key takeaways
- MCP 2.0 makes agent-tool traffic easier to route and audit, but the security decision still depends on validating request-scoped identity and capability data.
- The protocol shifts state handling into client-returned fields such as requestState, which increases the importance of integrity protection and replay controls.
- For IAM and NHI teams, the key question is no longer whether MCP can be stateless, but whether authorisation is enforced where the request is actually evaluated.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article centers on per-request identity metadata and the limits of self-reported trust. |
| NHI-07 — Long-Lived Secrets | RequestState and other retained request context behave like sensitive bearer artefacts across turns. | |
| NHI-05 — Overprivileged NHI | Tool routing and capability declarations expose the risk of broader access than a client actually needs. | |
| Recommendation — Validate MCP identity fields independently and do not treat self-declared client metadata as proof of authentication. Shorten the lifetime of request-held state and bind it to the authenticated principal before reuse. Map each MCP tool to least-privilege access and remove capabilities the client did not explicitly declare. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article discusses agent traffic where identity and privilege decisions must be enforced per request. |
| Recommendation — Apply request-level privilege checks before tool execution and reject any call whose declared capability exceeds policy. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The protocol now relies on per-request credentials and state handling that must be governed as authenticators. |
| Recommendation — Manage request-bearing credentials and state with expiry, binding, and revocation controls under IA-5. | ||
Key terms
- 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.
- Stateless protocol: A stateless protocol does not depend on a persistent session to understand or authorise a request. In MCP 2026-07-28, that means each call carries the context needed for routing and validation, which improves scale but makes request binding and integrity checks essential.
- Client-declared capability: A capability that the client says it supports or requires, and the server uses to decide whether a request can proceed. In MCP, these declarations are useful for negotiation but are not proof of trust, so they must be validated and never used as a substitute for authorisation.
- Header-body desynchronisation: A condition where the values mirrored into HTTP headers do not match the JSON body that carries the actual request. In MCP, this creates a policy gap if gateways trust headers without checking the body and the declared protocol version, allowing downgrade or tampering issues.
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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on September 2, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org