Stateless MCP changes the security model for AI agent tooling

At a glance

What this is: Equixly’s analysis says the 2026-07-28 MCP specification makes the protocol stateless while moving routing, approvals, and authorization checks into new request and header controls.

Why it matters: This matters because IAM, PAM, and NHI teams must now govern tool access, request integrity, and capability exposure at the protocol edge instead of relying on session state.

👉 Read Equixly’s analysis of the 2026-07-28 stateless MCP specification

Context

Model Context Protocol security changes because the protocol decides where trust lives, how tool access is declared, and what a gateway can validate before an action is executed. The 2026-07-28 revision removes session state from the transport and shifts more responsibility into headers, request payloads, and capability discovery, which makes MCP identity and access control a protocol design issue rather than just an application concern.

For IAM and NHI programmes, the important question is no longer only whether an MCP server is reachable, but whether the server, client, and intermediary all agree on identity, capability scope, and request integrity. That is why this update belongs in the same governance conversation as workload identity, secrets handling, and privileged tool access.

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: Why do header-based routing controls create new MCP security risks?

A: They create a second representation of the same action, which can drift from the body if validation is weak. That matters because gateways may approve a request based on one set of values while the server executes another. The safest model is fail closed on any mismatch and test downgrade paths as rigorously as the normal path.

Q: What breaks when MCP capability listings are cached for too long?

A: Stale tool catalogs can keep exposing capabilities that should no longer be available, and the model may still act on them because the cached description influences tool selection. Long cache TTLs also make poisoned metadata harder to spot. Teams should monitor catalog freshness, not just server uptime, and treat capability listings as governed access data.

Q: Who is accountable when an MCP tool call is authorised through a gateway and fails downstream?

A: Accountability is shared across the gateway, the MCP server, and the system behind the tool. The gateway must validate the request it sees, the server must not accept mismatched headers or stale state, and the downstream system must enforce its own access boundaries. Policy delegation does not remove responsibility for the final action.

Technical breakdown

Why stateless MCP changes request trust

The 2026-07-28 specification removes the initialize handshake and session affinity, so each request stands on its own with protocol version, client capabilities, and identity context carried in the request. That makes MCP easier to scale, but it also means state can no longer hide inside a transport-level session. Any capability reference that survives across calls now depends on explicit handles, request binding, and expiry discipline. In security terms, the trust boundary moved from a persistent connection to each individual request.

Practical implication: validate request binding, expiry, and identity context on every call instead of assuming a stable session.

How header-based tool routing changes the attack surface

MCP now places routing and method information into headers such as MCP-Protocol-Version, Mcp-Method, and Mcp-Name, allowing gateways to authorize and meter traffic without parsing JSON-RPC bodies. That improves edge enforcement, but it also creates a header-body consistency problem. If implementations fail to compare the two, a gateway may approve one thing while the server executes another. The same issue applies to Mcp-Param-* headers, where tool arguments can be mirrored into policy-visible metadata and must be validated as trusted input.

Practical implication: test header-body mismatch handling and reject any path where the gateway and server disagree.

Why cacheable capability listings need governance

The new cacheable listings for tools, prompts, and resources reduce round trips, but they also make stale metadata a security concern. A tool catalog is not just documentation. It influences what the model decides to call and how it formats arguments, so a poisoned or overly broad cached listing can persist until TTL expiry across multiple clients. Deterministic ordering helps consistency, but it also makes catalog drift easier to miss if teams do not monitor what the server is advertising over time.

Practical implication: review cache TTLs and compare cached capability lists against live server output on a fixed schedule.

NHI Mgmt Group analysis

Stateless transport does not remove identity risk, it relocates it. MCP 2026-07-28 shifts trust away from persistent sessions and into per-request controls, which makes request integrity, issuer binding, and tool-scoped authorization the real governance layer. That is a better deployment model for scaling, but it also removes the comforting fiction that session state can serve as an access-control boundary. Practitioners should treat every MCP request as an independently governed identity event.

Header visibility is a governance gain only if validation is strict. Moving routing into headers gives gateways a chance to enforce policy earlier in the path, but it also creates a second representation of the same action. The security value comes from consistency checks, not from the presence of headers themselves. If the body can disagree with the header, policy becomes advisory instead of authoritative, and that is a control failure rather than a protocol feature.

Cacheable capability listings create capability drift risk. The specification makes tool discovery cheaper, but also longer lived, which means the model may keep acting on stale or overbroad metadata longer than teams expect. Capability listing cache drift: once a tool catalog is cached, the security issue is no longer only what the server exposed, but how long that exposure remains actionable in downstream clients. Practitioners need to govern catalog freshness as part of access governance, not only as performance tuning.

The protocol revision validates the need for testing at the interface boundary, not just behind it. Equixly’s point is structurally correct: MCP does not harden the functionality it exposes, so the rebuilt interface and the underlying API surface must both be exercised adversarially. For identity teams, that means protocol changes should trigger a review of authorization boundaries, request mutation paths, and tool invocation controls together. The field is moving toward edge-enforced policy, but edge policy is only as good as the identity assumptions behind it.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• For the adjacent control problem, see OWASP Agentic Applications Top 10 for the agentic threat model that now intersects with MCP governance.

What this signals

Capability listing cache drift: as MCP catalogs become cacheable, teams need a governance model that treats tool metadata as access-bearing data, not documentation. If the cached listing outlives the permission change, the model can continue to reason from obsolete authority. That is a policy freshness problem as much as a protocol problem.

With 80% of organisations reporting AI agents acting beyond intended scope in our research on agentic attack surfaces, the broader lesson is that autonomous tool access is already escaping traditional review cycles. For MCP, that means lifecycle controls, authorization binding, and edge validation must be designed together rather than layered on later.

Practitioners should also align MCP testing with edge enforcement guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls and the agentic threat patterns documented in OWASP Agentic AI Top 10. The practical goal is to stop treating protocol modernization as a transport-only project.

For practitioners

• Validate per-request identity binding Require every MCP request to carry verifiable client identity, issuer context, and expiry, and reject any request that depends on hidden session state.
• Test header and body consistency Build test cases for MCP-Protocol-Version, Mcp-Method, Mcp-Name, and Mcp-Param-* mismatches, then confirm the server and gateway fail closed.
• Treat cached tool catalogs as access data Track TTLs, cacheScope, and catalog drift so a stale tool listing cannot keep authorising a capability after the server side has changed.
• Review requestState handling as attacker-controlled input Bind requestState to the originating principal and request, encrypt or sign it where possible, and set a short expiry before it can affect authorization decisions.

Key takeaways

• MCP 2026-07-28 moves security responsibility from persistent sessions to per-request governance, which raises the importance of identity binding and request integrity.
• Header-based routing and cacheable tool catalogs create new validation and freshness risks that can turn protocol convenience into policy drift.
• Teams testing MCP should evaluate gateway consistency, catalog TTLs, and authorization binding together because the protocol change expands the places where access can fail.

Key terms

• 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.
• 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 cache: A capability listing cache stores tool, prompt, and resource metadata so clients do not need to refetch it on every interaction. In MCP, that cache becomes a security concern because stale descriptions can keep shaping tool selection long after the server’s authority has changed.
• Header-body mismatch: Header-body mismatch occurs when the metadata carried in an HTTP header disagrees with the action encoded in the request body. In MCP, that mismatch can undermine gateway policy unless implementations compare both representations and reject any inconsistency.

What's in the full article

Equixly's full blog covers the operational detail this post intentionally leaves for the source:

• A step-by-step explanation of how the stateless MCP request flow changes client, gateway, and server responsibilities.
• The exact header fields and validation edge cases that security testers should probe in MCP implementations.
• The protocol-level implications of cacheScope, ttlMs, and requestState for real deployments.
• Equixly's testing perspective on exposed functionality beneath MCP, including how adversarial chaining reaches the underlying system.

👉 Equixly’s full post covers the routing, authorization, and testing details behind the new MCP security model.

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.