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.
Editorial analysis by NHI Mgmt Group, based on content published by Equixly: “Stateless MCP: What the 2026-07-28 specification changes for security”.
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.
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.
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.
Practitioner guidance
- 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.
- 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.
Bottom line: MCP 2026-07-28 changes where trust is enforced, not just how requests are transported.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
18/08/2026 3:03 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Stateless MCP changes the security model for AI agent tooling