Notifications
Clear all
Topic starter
02/09/2026 3:57 pm
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.
NHIMG editorial — based on content published by Highflame: MCP 2.0 makes MCP fully stateless and pushes more control into per-request metadata and headers
By the numbers:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
- 53% of MCP servers expose credentials through hard-coded values in configuration files.
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: What breaks when gateways trust MCP headers without validating the body?
A: Header-only enforcement creates a desynchronisation risk.
Q: When does requestState become a security risk in MCP deployments?
A: requestState becomes risky when it can influence authorization, resource access, or business logic without integrity protection.
Practitioner guidance
- Validate every request independently Require version, client capabilities, and tool context to be checked on each call before any routing or authorization decision.
- Treat requestState as protected state Bind server-authored requestState to the authenticated principal, add a short TTL, and verify integrity before accepting it in later calls.
- Move policy to the gateway layer Use Mcp-Method and Mcp-Name for per-tool rate limiting, audit, and authorization so the JSON body is not the only place policy can be enforced.
What's in the full article
Highflame's full analysis covers the operational detail this post intentionally leaves for the source:
- Header-by-header examples showing how MCP-Protocol-Version, Mcp-Method, and Mcp-Name are mirrored and validated in practice.
- The migration checklist for dual-era clients and servers that need to support both legacy session semantics and the new stateless model.
- Detailed guidance on requestState handling, including integrity protection and replay bounds for multi-turn workflows.
- The protocol-specific handling of subscriptions, caching hints, and long-running task patterns that were only summarised here.
👉 Read Highflame's analysis of MCP 2.0 stateless requests and header routing →
MCP stateless sessions and header routing: what changes for IAM teams?
Explore further
02/09/2026 3:58 pm
Stateless transport does not remove identity governance, it exposes it. MCP 2.0 makes every request declare its own identity context, but that is not the same as proving authority. The governance problem shifts from session stewardship to request stewardship, which is a stricter and more visible burden for IAM and NHI teams. Practitioners should read this as a demand for per-request policy enforcement, not as a simplification of trust.
A few things that frame the scale:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to the State of MCP Server Security 2025.
- 53% of MCP servers expose credentials through hard-coded values in configuration files.
A question worth separating out:
Q: What should teams do when MCP workflows still need continuity across calls?
A: They should move continuity into ordinary application state and make it explicit, such as a queryId or job identifier stored server-side. That keeps lifecycle, logging, and policy visibility intact. Transport state is no longer the right place to hide workflow context in a stateless MCP model.
👉 Read our full editorial: MCP 2.0 makes agent traffic stateless, but not automatically safer
