Stateless MCP changes the security model for AI agent tooling

At a glance

What this is: This analysis of MCP 2026-07-28 says stateless transport, header-based routing, cacheable capability listings, and tighter authorization shift trust enforcement points across AI agent tooling.

Why it matters: IAM, NHI, and agentic AI teams need to reassess where policy lives when capability discovery, approvals, and routing no longer depend on a persistent session.

Context

MCP is a protocol for connecting AI agents and tools, and the 2026-07-28 revision changes where state, routing, and authorization are enforced. That matters because the security model now depends less on a held-open session and more on request-scoped controls, explicit handles, and validation at the edge.

For identity governance, the practical question is no longer whether the transport is stateful enough to preserve context. The question is whether request metadata, capability listings, and delegated approvals can be trusted when they are decoupled from a persistent session and may be cached, mirrored, or replayed in new ways.

Key questions

Q: What breaks when MCP moves from a stateful session to stateless requests?

A: The old assumption that trust can be carried by a long-lived session breaks first. Security teams now need to validate each request independently, because protocol version, client identity, and capability context arrive as data rather than as durable connection state. That changes how authorization evidence is established and audited.

Q: Why do stateless MCP approvals create new authorization risk?

A: Because approval artifacts such as requestState now travel through the client and return as request data. If those artifacts are not bound to the originating principal, the original request, and an expiry, they can be replayed or repurposed outside the intended decision context. The risk is policy drift, not just transport loss.

Q: What signs show that MCP capability caching is becoming a governance problem?

A: The warning signs are stale tool inventories, unexpected tool selection by the model, and authorization outcomes that no longer match the server's current catalogue. When cached discovery survives schema or policy changes, the client may act on obsolete capability data. That is a governance failure, not a performance optimisation.

Q: How should security teams implement MCP tool approvals in gateway-controlled environments?

A: Start by treating approvals as a gateway enforcement function, not a protocol feature. Hold the call at the boundary, return explicit pending metadata to the client, and require the caller to branch safely when approval is outstanding. Then scope the decision to a resolved requester identity, a specific server, and a specific tool, so the grant cannot drift across actors or sessions.

Technical breakdown

Stateless MCP removes the session as a trust container

The 2026-07-28 specification removes the initialize handshake and session header, so a request no longer inherits trust from a sticky transport path. Instead, each call carries its own protocol version, client identity, and capabilities, while tools can mint explicit handles that must be passed back in later requests. That architecture improves deployment flexibility, but it also moves security decisions into the request content and the surrounding control plane. Any system that still assumes a session boundary is now enforcing policy in the wrong place.

Practical implication: Treat request metadata and explicit handles as the new control surface, not the transport connection.

Header-based routing creates a new validation boundary

MCP now exposes method, tool name, and selected parameters in HTTP headers so gateways can route and authorize before parsing the JSON-RPC body. That is useful for edge enforcement, but it creates a new integrity requirement: the header view and body view must match, and downgrade paths must be rejected. The specification also allows parameter mirroring into headers, which makes schema-defined metadata policy-relevant. If the implementation does not verify alignment, an attacker can exploit inconsistent interpretation between intermediary and backend.

Practical implication: Enforce header-body consistency checks and reject requests whose declared version does not support the required validation.

Cacheable capability listings increase stale metadata risk

Capability listings are now cacheable, which reduces round trips and token usage, but also extends the lifespan of whatever tool inventory the client or intermediary has stored. Because tool definitions influence model choice, stale or poisoned listings can shape downstream tool selection long after the server changed its catalogue. The same logic applies to long-running tasks and requestState returned during interactive approvals: if that material is not bound, expired, and verified, the client becomes part of the trust problem rather than a neutral transport.

Practical implication: Set tight cache lifetimes and bind approval state to the originating principal and request.

Threat narrative

Attacker objective: The attacker wants to induce the server or gateway to make the wrong authorization or routing decision, then use that mismatch to run an unintended tool action.

1. Entry occurs when a client or intermediary accepts a valid-looking MCP request whose headers, body, or cached capability listing do not match the server's actual policy state.
2. Escalation follows when the implementation trusts mirrored header values, stale discovery metadata, or unbound requestState to drive authorization or routing decisions.
3. Impact appears as misrouted tool calls, duplicated side effects after retries, or unauthorized tool use that bypasses the intended backend checks.

Breaches seen in the wild

• Secrets in VS Code extensions 2025: Wiz found 550+ secrets in VS Code extensions, including publishing tokens able to push malicious updates to about 150,000 installs.
• 12,000 secrets in LLM training data: Truffle Security found 11,908 live API keys and passwords hard-coded in web pages captured by Common Crawl, a dataset used to train LLMs.

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 MCP is a control-plane shift, not just a transport change: the protocol now assumes trust can be reconstructed from request metadata, explicit handles, and edge enforcement rather than from a persistent session. That is a meaningful governance change because the security boundary moves closer to the gateway and farther from the connection lifecycle. Practitioners should treat this as a redesign of where authorization evidence lives.

Cacheable capability listings create identity blast radius through stale discovery: when tool inventories are cached, the model may continue to reason over a capability set that no longer reflects server reality. That creates a governance problem for NHI and agentic tooling because authorization decisions are now influenced by metadata that can outlive the server state it describes. The implication is a shorter trust horizon for discovery material.

Header-visible routing makes validation a first-class security requirement: once method, tool name, and selected parameters are mirrored into headers, the integrity of those values becomes part of the security model. The classic assumption that policy lives only in backend code no longer holds. Practitioners need to recognize that a gateway can only enforce policy safely if it can prove the request representation is consistent.

Explicit approval handles replace hidden session state, but they do not remove trust debt: requestState and similar artifacts now travel through the client and back into the server as data. That means expiry, binding, and provenance become governance controls, not implementation details. The practical conclusion is that request-scoped trust must be measured and governed like any other credential-bearing artefact.

Protocol hardening does not fix weak backend exposure: the article makes clear that MCP still exposes APIs, databases, and filesystems through a new interface rather than hardening the underlying system itself. That means teams should not confuse protocol revision with application security. The field should read this as an interface rework, not a substitute for hardening the workloads behind it.

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

Capability listings are becoming identity-bearing data: when tool inventories are cacheable, they stop being passive metadata and start influencing model behaviour over time. Teams should assume that discovery material now has a governance lifetime and deserves explicit expiry, invalidation, and owner review.

The broader signal is that agent tooling is moving toward edge-enforced authorization and request-scoped trust. That aligns with how NHI programmes already think about short-lived access, but it also exposes a gap: discovery, approval, and routing now need the same lifecycle discipline as credentials.

MCP hardening is also a reminder that protocol revision does not equal workload hardening. If the underlying API, database, or filesystem remains exposed through the new interface, the control point has shifted but the risk has not disappeared.

For practitioners

• Harden header-body consistency checks Reject any request where MCP-Protocol-Version, Mcp-Method, or Mcp-Name disagree with the body or declared capability path. Make downgrade paths explicit denial cases, not fallback behavior.
• Treat requestState as attacker-controlled input Bind input_required state to the originating principal, the original request, and a short expiry before the value can influence authorization or tool execution.
• Shorten cache lifetimes for capability listings Limit ttlMs aggressively for tools and resources catalogs, then invalidate cached discovery when tool schemas, descriptions, or authorization boundaries change.
• Test retry paths for duplicate side effects Reissue interrupted MCP operations in a controlled lab to see whether idempotency is enforced by the tool or merely assumed by the client.
• Map every exposed tool to an authorization owner Assign a named control owner for each tool, resource, and prompt surface so header-visible routing does not become an orphaned policy decision.

Key takeaways

• MCP 2026-07-28 changes where trust is enforced, not just how requests are transported.
• Cached discovery, header-based routing, and request-scoped approvals create new failure modes if validation is weak.
• Practitioners should govern MCP metadata, approval artifacts, and backend ownership as a single security surface.

Key terms

• Stateless MCP: Stateless MCP is a way of using the Model Context Protocol without relying on stored session state between requests. In practice, each interaction carries the needed context, credentials, and tool references explicitly, so the server does not preserve conversational memory. This reduces persistence risk, but shifts responsibility to the caller for continuity and authorization.
• 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.
• Capability Listing: A capability listing is the server's advertised set of tools, prompts, and resources that an MCP client can discover and use. In a cacheable model, it becomes governance-relevant metadata because stale or poisoned listings can shape model behaviour long after the server changes.
• Header-Body Validation: Header-body validation is the control that checks whether values exposed in HTTP headers match the JSON-RPC body and declared protocol state. In MCP, it is a core integrity check because routing and authorization may happen before the backend parses the payload.

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 programme, it is worth exploring.