Notifications
Clear all
Topic starter
18/08/2026 2:10 pm
TL;DR: Stateless transport, header-based routing, cacheable capability listings, and stricter authorization all shift where trust and policy enforcement happen, according to Equixly. The real security change is that MCP now exposes more control points, but also more places for validation failures, stale metadata, and request tampering to create abuse paths.
NHIMG editorial — based on content published by Equixly: Stateless MCP: What the 2026-07-28 specification changes for security
Questions worth separating out
Q: How should security teams govern MCP requests without relying on session state?
A: Treat each MCP request as a standalone identity event.
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.
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.
Practitioner guidance
- 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.
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.
👉 Read Equixly’s analysis of the 2026-07-28 stateless MCP specification →
Stateless MCP 2026-07-28: are your controls keeping up?
Explore further
18/08/2026 3:03 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Stateless MCP changes the security model for AI agent tooling
