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

At a glance

What this is: This is an independent analysis of the MCP 2026-07-28 revision and its key finding: governance moves from protocol state to explicit handles, task lifecycles, and gateway policy.

Why it matters: It matters because IAM, PAM, and NHI teams now need to govern MCP traffic as an identity-bearing control surface, not just as transport between models and tools.

By the numbers:

• While 71% of IT teams have been advised on AI agent data access, only 47% of compliance teams, 39% of legal teams, and 34% of executives have the same visibility.

👉 Read TruFoundry's analysis of the MCP 2026-07-28 specification changes

Context

The Model Context Protocol has moved from a stateful, session-oriented design to a stateless one, which changes where control lives. In practice, that means enterprises must stop treating session continuity as the security boundary and start treating explicit handles, headers, and gateway policy as governed identity artefacts.

For MCP governance, the central issue is not just transport revision but the relocation of trust. Apps, Tasks, and authorization now sit closer to ordinary OAuth and OIDC patterns, which makes the gateway the practical enforcement point for NHI, agentic AI, and tool access decisions.

The article also revisits a broader enterprise question: when a protocol formalises extensions and deprecates older behaviours, what needs to be inventoried, re-authorised, and retired before production drift becomes policy debt? That starting position is typical for organisations adopting MCP at scale.

Key questions

Q: How should security teams govern explicit handles in stateless MCP workflows?

A: Security teams should treat explicit handles as capability-bearing artefacts, not as harmless reference strings. Each use should be authorized against the current principal, with secrets excluded from the value itself. The best control point is the gateway, where handle issuance, replay detection, and transcript redaction can be tied to policy and audit.

Q: Why do AI coding tools increase governance risk for IAM and NHI teams?

A: AI coding tools increase governance risk because they obscure who created the logic, which identities executed it, and whether the resulting automation has the right access scope. That creates blind spots in auditability, approval authority, and secret handling. IAM and NHI teams need controls that can prove both the actor and the action.

Q: What do organisations get wrong about MCP Apps and trusted client chrome?

A: They often confuse a trusted interface with trusted content. MCP Apps can render inside a sanctioned host while still serving untrusted UI that triggers ordinary tool calls. That means the UI layer and the tool-authorization layer must be controlled separately, with explicit consent and sandbox boundaries.

Q: How should teams retire deprecated MCP features without creating migration surprises?

A: Teams should build a live inventory of callers, feature dependencies, and protocol versions before setting retirement dates. Deprecation policy only works when it is tied to actual usage. Without that visibility, removal windows become incident windows, especially for legacy transports and experimental APIs.

Technical breakdown

Stateless MCP routing and explicit handles

The final MCP revision removes protocol sessions and the initialization handshake, then routes requests by MCP method and name headers. That makes state an application concern instead of a transport concern. When a tool needs continuity, the server can mint a handle such as a basket_id or ticket_id and pass it back as an ordinary argument. The handle is visible to the model and can survive across tool calls, which makes it easier to reason about but also easier to misuse if it carries too much authority or reveals server-side state.

Practical implication: treat handles as governed identity artefacts, not harmless labels, and validate each use against the current principal.

Tasks as durable work with revocation gaps

Tasks have moved into a formal extension with a poll-based lifecycle: tasks/get, tasks/update, and cooperative tasks/cancel. That design is useful for long-running workflows because it decouples work progress from a single request thread, but it also creates a temporal-validity problem. The authorization that starts a task may not be the authorization that should finish it, and the protocol itself does not guarantee that the original grant remains valid when the work completes. This is an application-level governance problem, not a protocol feature.

Practical implication: bind every task to a principal, track the authorization context, and enforce revocation and budget attribution at the application layer.

MCP Apps, trusted chrome, and app-initiated tool calls

MCP Apps are server-rendered interfaces that run inside trusted host chrome, but the rendered content is still untrusted. The host and app communicate over a JSON-RPC style channel, and app-initiated tool calls travel through the normal tools/call path. That is the important security split: UI traffic stays within the client sandbox, while tool invocation reaches the governed layer that already needs consent, policy, and audit. The risk is not only malicious code, but user confusion through a trusted interface that appears native.

Practical implication: separate UI sandbox controls from tool-call governance, and do not assume trusted chrome implies trusted content.

Threat narrative

Attacker objective: The objective is to turn an apparently ordinary MCP interaction into durable access or unauthorised tool execution by exploiting stale governance around handles and tasks.

1. Entry occurs through a trusted MCP App interface or an exposed task workflow that carries an accepted handle into the session context.
2. Escalation happens when the handle or task outlives the original authorization context and is reused through ordinary tool calls or poll-based task progression.
3. Impact follows when the gateway or downstream service accepts the carried identity artefact without rechecking principal, scope, and revocation state.

Breaches seen in the wild

• Coupang Signing Key Breach — Unrevoked signing key credentials expose 33.7 million records after employee offboarding failure at Coupang.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Stateless protocol design does not remove the governance problem, it relocates it. The final MCP revision makes the gateway, headers, and application-layer handles the real control plane. That is a better fit for enterprise enforcement, but only if teams stop assuming the protocol itself carries stateful security guarantees. The practitioner conclusion is that state visibility has become the new governance boundary.

Handle governance is now a named identity problem, not a transport detail. A basket_id or ticket_id that can recover or mutate server-side state behaves like a capability artifact. That means possession, replay, and transcript exposure matter as much as authentication. The implication is that handle issuance, scope, and revocation need explicit policy, not informal logging.

Tasks expose temporal-validity debt in MCP estates. The protocol now expects long-running work to continue after the original request thread has ended, which means access review logic built for short-lived calls is incomplete. This is exactly the kind of lifecycle gap that OWASP-NHI guidance is meant to surface, and the practical conclusion is that task completion must be governed as a distinct identity event.

MCP Apps create a trusted-interface problem at the gateway boundary. The interface looks native to the user, but the rendered content remains untrusted and can drive ordinary tool calls through governed paths. That makes phishing through legitimate UI a governance concern rather than a classic malware problem. The practitioner conclusion is that consent, sandboxing, and tool approval must be separated cleanly.

Formal deprecation clocks are a governance improvement only if inventories are real. A dated removal window helps teams plan, but it also creates false comfort when estates do not know which clients still rely on legacy features. The named concept here is protocol deprecation debt: the gap between a formal removal schedule and the actual time enterprises need to retire dependent integrations. The practitioner conclusion is that removal dates must be tied to live dependency data, not assumed compliance.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, 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.
• OWASP Agentic AI Top 10 is the next step for teams mapping these control gaps to concrete agent risks.

What this signals

Handle governance will become a routine gateway requirement as MCP estates mature. Once state moves into explicit handles, the practical question is no longer whether the protocol is stateful, but whether the gateway can trace who minted, reused, or revoked each handle. That is a natural fit for policy linked to the NIST Cybersecurity Framework 2.0 and to gateway logging already expected in enterprise MCP deployments.

The named concept to watch is protocol deprecation debt: the gap between a formal removal schedule and the actual dependency graph inside the enterprise. Teams that do not inventory MCP callers by version and feature use will discover that deprecation dates are not a migration plan. This is where current-state visibility matters more than future compliance statements.

For autonomous and NHI programmes alike, the migration quarter is a control design moment. Apps, Tasks, and auth hardening all move enforcement closer to the gateway, which means teams should align governance with NIST Cybersecurity Framework 2.0 and, where agentic behaviour is present, with OWASP Top 10 for Agentic Applications 2026.

For practitioners

• Inventory MCP clients by protocol version and feature use Capture client identity, protocol version, and active feature flags at the gateway so teams can see which consumers still depend on legacy sessions, experimental Tasks, or deprecated transports.
• Treat handles as security-sensitive capability artefacts Authorize each handle use against the current principal, avoid embedding secrets in handle values, and log or redact handle strings according to policy.
• Bind every task to a principal and authorization context Persist the creator identity, task budget, and revocation state for each long-running workflow so tasks/get and cooperative tasks/cancel do not become blind continuation paths.
• Separate UI sandbox policy from tool-call policy Apply different controls to host-side ui/* traffic and to app-initiated tools/call requests, because trusted chrome does not make rendered content trustworthy.
• Tie deprecation work to live dependency evidence Map Roots, Sampling, Logging, DCR, and HTTP+SSE usage to actual callers before the removal window closes, then schedule migration by dependency criticality rather than by announcement date.

Key takeaways

• MCP 2026-07-28 shifts the control problem from session state to explicit handles, task lifecycles, and gateway policy.
• The governance risk is not just protocol change, but identity artefacts that can outlive the authority that created them.
• Teams should inventory live dependencies now, or deprecation clocks will turn into production incidents later.

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 Lifecycle: Task lifecycle is the sequence of create, poll, update, complete, and cancel events for long-running work. In MCP, the lifecycle shifts governance away from a single request and into continuing identity, authorization, and revocation checks across the lifetime of the task.
• Protocol Deprecation Debt: Protocol deprecation debt is the gap between a formal feature removal schedule and the real dependency footprint inside an enterprise. It appears when teams know a behaviour is going away but have not mapped which clients, servers, or workflows still rely on it.
• Trusted-Interface Problem: The trusted-interface problem occurs when untrusted content is rendered inside an interface users already trust. In MCP Apps, that means the chrome may be sanctioned while the content still drives tool actions, so UI trust cannot be assumed to equal action trust.

What's in the full article

TruFoundry's full analysis covers the operational detail this post intentionally leaves for the source:

• Spec-by-spec migration implications for teams still running against the 2025-11-25 experimental Tasks API
• Gateway implementation detail for protocol version inventory, caller tracing, and deprecation tracking
• Deeper examples of how MCP Apps forward tool calls while keeping ui/* traffic host-side
• The full breakdown of which spec deltas change host, client, and gateway responsibilities in production

👉 The full TruFoundry article covers protocol deltas, gateway implications, and migration priorities in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.