MCP 2026-07-28 shifts gateway governance toward stateless control

At a glance

What this is: This is TrueFoundry's analysis of the MCP 2026-07-28 final specification, which moves the protocol to stateless routing, formalises Apps and Tasks as extensions, and tightens authorization toward OAuth/OIDC practice.

Why it matters: It matters because gateway teams now have to govern explicit handles, task lifecycles, and app-initiated tool calls as first-class identity and access surfaces, not as implicit protocol state.

Context

MCP gateway governance changed because the protocol itself changed shape: what used to be session-bound and transport-stateful is now routed through headers, explicit handles, and extension-specific lifecycles. For identity and access teams, that means the control plane has to follow the protocol boundary instead of assuming the protocol will preserve state for them.

The biggest governance question is no longer whether an MCP server can keep a session alive. It is whether the gateway can still enforce authorization, traceability, and revocation when state is carried as explicit handles, tasks can outlive their start context, and Apps can initiate tool calls through the ordinary tools/call path.

Key questions

Q: What breaks when MCP state is moved into explicit handles?

A: When state becomes an explicit handle, the hidden trust embedded in transport sessions disappears and governance has to move to the object that names the state. Teams must decide whether possession of the handle is enough to act, whether it can be replayed, and how it is redacted in transcripts and logs.

Q: Why do long-running MCP Tasks create revocation risk?

A: Because a task can continue after the authorization that started it has changed or expired. If the task is not bound to the principal and current authorization context, the system can keep executing under stale authority, which is exactly the gap the final specification leaves to implementers.

Q: How should security teams govern MCP tool access in enterprise environments?

A: Security teams should bind MCP tool access to enterprise identities, entitlements, and lifecycle state before a request reaches production tools. A gateway can enforce policy at the edge, but governance only exists when the identity system knows who is calling, what they are allowed to do, and whether approval or offboarding has already occurred.

Q: What is the difference between a protocol handle and a session token in MCP?

A: A session token usually proves an ongoing transport relationship, while an MCP handle names application state that can be passed as an argument through the model context. That makes handles more visible and more operationally useful, but also more sensitive if possession alone grants access.

Technical breakdown

Stateless MCP routing and explicit handles

The final specification removes protocol sessions and the initialization handshake, then routes requests by headers such as Mcp-Method and Mcp-Name. That pushes continuity out of the transport layer and into explicit handles like basket_id or ticket_id that tools return and later consume as ordinary arguments. In security terms, the handle is no longer just data. It becomes an application-level reference to live server-side state, which may be visible in transcripts, logs, and downstream tool calls. That makes handle design, redaction, and authorisation decisions part of the gateway's trust boundary rather than a convenience feature.

Practical implication: Treat explicit handles as security-sensitive artefacts and authorise every reuse against the current principal.

Tasks as a poll-based lifecycle with revocation gaps

Tasks move into a formal extension with a redesigned poll-based lifecycle: tasks/get, tasks/update, and cooperative tasks/cancel. That matters because long-running work can now continue after the original authorization context has aged, changed, or been revoked. The protocol standardises lifecycle mechanics but leaves per-task identity, mid-task revocation, and budget attribution to the implementer. In practice, that means the task itself becomes the unit of governance, and the gateway must be able to associate task activity with the principal and authorization state that created it.

Practical implication: Bind each task to its issuing principal and propagate revocation into running work.

MCP Apps and tool-call governance at the gateway

MCP Apps place server-rendered UI inside trusted client chrome, but app-initiated tool calls still traverse the ordinary tools/call path. That design is important because it separates untrusted UI from governed execution without separating the actual action path from policy and audit. The host must sandbox the UI, while the gateway continues to govern the tool call itself as a normal MCP request. The result is a split trust model: the app surface is a user-experience risk, but the tool invocation remains an identity and authorization event that should be inspected, logged, and enforced like any other call.

Practical implication: Apply the same policy, logging, and approval rules to app-initiated tool calls as to direct tool requests.

Threat narrative

Attacker objective: The objective is to turn protocol-visible state, task continuity, or app-initiated calls into durable tool access that outlives the intended authorization window.

1. Entry occurs when an attacker or abusive workflow obtains visibility into explicit handles, task identifiers, or app-driven tool invocation paths exposed in the MCP control surface.
2. Escalation follows when a handle is reused beyond the authority that minted it, or when a task keeps executing after the original authorization context is no longer current.
3. Impact lands when the gateway lacks task-level revocation and handle-level authorization checks, allowing stale or replayed state to drive unintended tool execution.

Breaches seen in the wild

• LiteLLM MCP auth bypass 2026: An exploited LiteLLM MCP auth bypass and default sk-1234 master keys let attackers steal AI gateway master and provider API keys.
• Moltbook AI agent keys breach: Moltbook breach exposed 1.5M AI agent keys.

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

Statelessness moves the trust boundary upward, not away. The protocol no longer carries session state for the gateway to inherit, so continuity now depends on explicit handles, header-based routing, and application-level logic. That means the gateway becomes the enforcement point where state visibility, authorisation, and traceability must be reconstructed. Practitioners should read this as a migration from hidden protocol state to governed identity artefacts.

Handle governance is the new control problem. The article's handle model is effectively capability-like: a basket_id or ticket_id names live server-side state and can travel through transcripts and tool calls. The assumption that protocol state stays invisible has broken. NHI governance now has to ask who can mint, reuse, replay, redact, and revoke those handles, because possession may be enough to reach state.

Tasks expose the temporal-validity gap in identity controls. Access review logic assumes a privilege persists long enough to be reviewed, but poll-based work can outlive the authorisation that started it. The issue is not just long-running execution, it is that governance is now lagging a lifecycle that can change faster than periodic review cycles. That makes task-scoped identity and revocation the relevant programme design question.

MCP Apps create an identity event at the UI boundary and another at the tool boundary. Server-rendered UI increases user-targeted abuse risk, but the app's tool calls still flow through the governed request path. That separation is useful only if teams stop treating the interface as the control plane. Practitioners should align trust decisions to the tool invocation itself, not the visual container around it.

Gateway-centric governance is becoming the practical default for AI tool ecosystems. As protocols standardise on explicit handles, extension lifecycles, and hardened client authentication, the estate needs one place to inventory versions, enforce policy, and observe task and app behaviour. This shifts MCP from a transport question to an identity governance question, which is where NHI teams already know how to operate.

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.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
• Read next: MCP Security Guide

What this signals

Handle governance is now part of identity governance. Once a protocol turns state into explicit handles, teams have to classify those handles the way they classify credentials and tokens: who can mint them, where they appear, whether they can be replayed, and when they should be invalidated. That is a governance problem, not a transport tweak.

Task lifecycles will outpace periodic review if they are left to the application tier alone. The more work is expressed as poll-based tasks, the more important task-level identity, revocation, and attribution become in the gateway and control plane. Mature programmes will move those controls earlier in the request path instead of trying to recover them after the fact.

For practitioners

• Inventory explicit handles as governed artefacts Track every handle type returned by tools, classify whether possession alone can recover or mutate state, and define redaction and retention rules for transcripts and logs.
• Bind task execution to the issuing principal Store the principal, authorization context, and budget owner with each task so revocation and audit can follow the work rather than the session.
• Treat app-initiated tool calls as normal governed requests Apply the same authorisation, consent, and audit policy to tool calls triggered from MCP Apps as to direct calls from the host.
• Update migration inventories for the new spec shape Record protocol version, client identity, and extension usage so you can distinguish legacy experimental Tasks implementations from the final poll-based lifecycle.

Key takeaways

• MCP's final 2026-07-28 specification shifts control from transport state to explicit handles, extension lifecycles, and gateway-enforced policy.
• That shift creates new identity surfaces around handle reuse, task persistence, and app-initiated tool calls, all of which need explicit governance.
• Teams that inventory protocol versions, bind tasks to principals, and govern handles at issuance will be better placed to manage the revision safely.

Key terms

• Explicit Handle: A state reference, such as a basket_id or browser_id, that an application creates and passes between calls instead of relying on hidden protocol session memory. It makes continuity visible and auditable, but it must be governed like a scoped credential surrogate.
• Task-scoped identity: Task-scoped identity is an identity created for a specific job, workflow, or action, and it exists only for that limited purpose. It binds permissions, context, and duration to one task, reducing exposure if the identity is misused. In practice, it supports least privilege, auditability, and controlled automation.
• App-Initiated Tool Call: A tool invocation started by an MCP App rather than a direct user request. The call still traverses the normal governed execution path, so security teams should treat it as a standard authorisation and audit event even when the user interface is rendered inside trusted client chrome.
• Gateway Governance Gap: The mismatch between request-level enforcement and actual identity governance. A gateway can inspect traffic and block calls, but it cannot by itself determine standing privilege, lifecycle status, or whether the caller is entitled across the broader enterprise environment.

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.