MCP 2026-07-28 rewrites AI agent authentication and sessions

At a glance

What this is: WorkOS explains that the MCP 2026-07-28 release candidate replaces session-based protocol assumptions with stateless requests and stricter OAuth-aligned authorization.

Why it matters: That matters because AI agent and MCP governance now depends on per-request identity, scoped tokens, and clearer extension boundaries, which affects both NHI and autonomous access controls.

By the numbers:

• The final specification ships on July 28, 2026.
• 8707) are required in token requests., quired in token requests.

👉 Read WorkOS's analysis of the MCP 2026-07-28 authentication changes

Context

MCP 2026-07-28 is a protocol governance change, not a cosmetic update. The release candidate removes session state from the protocol layer, hardens authorization, and changes how clients, servers, and gateways establish identity for AI agent interactions.

For identity teams, the practical question is how much of today's MCP security model still assumes sticky sessions, implicit trust, or token replay tolerance. When the protocol changes those assumptions, the impact lands in NHI governance, agentic AI access control, and the operational design of enterprise authorization flows.

Key questions

Q: How should security teams migrate MCP servers away from session-based trust?

A: Security teams should replace protocol sessions with explicit application handles, request-scoped authorization, and server-side validation that does not depend on sticky routing. The goal is to make every call independently authenticable and auditable. If a server still needs continuity, that state should live in a controlled handle, not in hidden protocol memory.

Q: Why do Resource Indicators matter for MCP authorization?

A: Resource Indicators matter because they bind a token request to a specific MCP server, which reduces confused-deputy risk and token replay across different resources. In multi-server environments, that binding is what keeps delegation boundaries clear. Without it, one server can accidentally or maliciously receive a token intended for another.

Q: What breaks when MCP clients and servers still assume sticky sessions?

A: Sticky-session assumptions break routing, scaling, and identity validation when the protocol no longer maintains connection-bound state. Implementers may also miss hidden dependencies that only appear under load-balanced or multi-instance deployment. The result is inconsistent authorization behaviour and a false sense of control continuity.

Q: Who is accountable when an MCP extension changes approval or audit behaviour?

A: Accountability stays with the team operating the server, the client, and the authorization layer, because negotiated extensions still become part of the control environment. The extension model does not remove governance responsibility. If an extension alters consent, logging, or task flow, it must be treated as a security-relevant change.

Technical breakdown

Stateless MCP protocol and explicit state handles

The release candidate removes protocol-level sessions and the initialize handshake, which means MCP no longer uses a shared session context to bind requests to a server instance. Instead, protocol metadata travels in request headers and the server can expose capability discovery on demand. When an application still needs continuity, it must mint explicit handles such as a basket_id or browser_id and pass them as normal tool arguments. That changes the architecture from implicit protocol memory to explicit application state, which is easier to route and audit but also easier to expose if handle design is weak.

Practical implication: inventory every dependency on Mcp-Session-Id and replace hidden session state with explicit, reviewable handles.

OAuth 2.1 alignment, protected resource metadata, and issuer binding

The spec moves MCP toward a real enterprise authorization model by treating servers as OAuth 2.1 resource servers, requiring Protected Resource Metadata, and formalizing Resource Indicators. That combination reduces token confusion because the client must specify the intended server and the authorization server identity must be validated. Issuer binding matters because MCP clients often talk to many servers, and mix-up attacks appear when tokens, issuers, and resource boundaries are not pinned together. The result is a tighter trust chain, but also a stricter implementation burden for clients and servers.

Practical implication: update token issuance, issuer validation, and resource scoping together rather than treating them as separate integration tasks.

Extensions, MCP Apps, and the new task lifecycle

The new extensions framework separates core protocol behavior from optional capabilities such as MCP Apps and Tasks. That separation matters because security-relevant functionality like interactive UIs, approval paths, and long-running work now has a formal negotiation model instead of being improvised by each implementer. Tasks moved out of the core spec because the old lifecycle could not be scoped safely without sessions, so task creation, update, and cancellation now operate through an extension-defined flow. This is a cleaner boundary, but only if implementers treat extension negotiation as an access-control decision, not just a feature flag.

Practical implication: treat extension support, especially task and UI capabilities, as part of authorization design and audit it explicitly.

Threat narrative

Attacker objective: The attacker wants to redirect authorization, reuse tokens across boundaries, or exploit weak MCP trust assumptions to gain broader agent access than intended.

1. entry: A client or server enters the new MCP model with legacy assumptions about session-bound trust, sticky routing, or token scope that no longer hold once the protocol becomes stateless.
2. escalation: If issuer verification, Resource Indicators, or explicit resource metadata are missing, tokens can be confused, replayed, or applied to the wrong MCP server boundary.
3. impact: Tool access, approval flows, and long-running tasks can be misrouted or over-authorized, creating exposure across agent interactions and downstream systems.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

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 is now an identity governance control, not just an architecture preference. MCP's removal of protocol sessions shifts trust from connection state to per-request identity, which makes authorization decisions more explicit and more inspectable. That helps governance, but it also means any implementation still depending on hidden session continuity is now carrying technical debt in the identity layer. Practitioners should treat protocol statelessness as a control boundary that must be validated, not assumed.

Resource Indicators and issuer binding close a confused-deputy gap that many agent stacks quietly inherit. MCP clients often talk to multiple servers, which is exactly where token audience confusion and issuer ambiguity become dangerous. The spec now forces a tighter relationship between the token, the intended resource, and the issuing authorization server. That is a governance improvement for NHI and agentic access, because it makes delegation boundaries legible instead of implicit.

Explicit handles replace session memory, which changes how least privilege is expressed for agents. In a sessionless protocol, privilege is no longer anchored to a long-lived conversation context. Instead, each stateful action must be reattached to a handle the model can carry forward. That reduces invisible privilege persistence, but it also means handle design becomes part of access governance. Practitioners should treat every handle as a scoped credential surrogate and review where it can be reused, shared, or replayed.

Extensions are becoming the control plane for MCP governance, which will separate mature deployments from improvised ones. MCP Apps and Tasks are no longer informal add-ons. They are negotiated capabilities that can carry audit, consent, and lifecycle behavior in a standardised way. That matters because the protocol is moving toward a future where governance lives in extensions rather than bespoke server code. Teams that cannot govern extensions will struggle to govern the protocol itself.

Stateless identity is pushing agent governance toward per-request enforcement and away from trust-by-session. The underlying assumption that a session can safely accumulate trust over time is weakening. For identity programmes, that means access policy, audit, and consent all need to operate at the request boundary, not the connection boundary. The practical conclusion is that agent access review must focus on each callable surface, not on a remembered session identity.

From our research:

• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate, according to AI Agents: The New Attack Surface report.
• Only 44% have implemented any policies to govern AI agents, even though 92% agree governing them is critical to enterprise security.
• That gap is widening fast, so teams should review OWASP Agentic AI Top 10 alongside the protocol changes described here.

What this signals

Stateless MCP will expose weak identity design faster than it exposes weak code. Teams that relied on session continuity to hide authorization inconsistency will now see those gaps surface at the request boundary. The immediate programme signal is to re-baseline agent access reviews, token audience validation, and server-side logging against per-call enforcement rather than connection state.

AI agent governance is shifting from conversation management to capability governance. Once sessions disappear, the durable security question becomes which tool, which resource, and which extension a request can touch. That is a different control problem from conversational oversight, and it aligns more closely with OWASP Agentic AI Top 10 and the trust boundaries described in the NIST AI Risk Management Framework.

Identity teams should expect more protocol changes to land as governance changes, not just implementation changes. MCP is showing where agentic infrastructure is heading: explicit resource scoping, negotiated capability boundaries, and tighter audit paths. Programmes that cannot absorb those shifts will end up with fragmented controls across IAM, PAM, and platform engineering.

For practitioners

• Audit session dependencies now Map every place your MCP servers still rely on Mcp-Session-Id, sticky routing, or shared session storage, then replace them with explicit handles and request-scoped identity checks.
• Harden token audience and issuer checks Require Resource Indicators, validate issuer binding on every authorization response, and re-register clients when a resource migrates between authorization servers.
• Rework extension governance Treat MCP Apps and Tasks as negotiated capabilities that require approval, logging, and lifecycle review before they are enabled in production.
• Test multi-instance behaviour before cutover Run production-like tests behind a round-robin load balancer and confirm that requests succeed without hidden session state or implicit server affinity.

Key takeaways

• MCP 2026-07-28 turns protocol sessions into explicit request-scoped identity, which changes how AI agent access must be governed.
• Resource Indicators, issuer verification, and OAuth 2.1 alignment materially reduce token confusion, but only if clients and servers implement them together.
• Teams should treat extension negotiation, task lifecycle, and explicit handles as governance surfaces, not optional engineering details.

Key terms

• Model Context Protocol: An open protocol that connects AI agents to tools and data sources through standardised request and response flows. In security terms, it defines where identity, authorization, and consent boundaries sit between the agent, the server, and the tools it can call.
• Resource Indicator: A token-request signal that specifies which protected resource an authorization grant is intended for. It prevents a token minted for one MCP server from being replayed against another, which makes delegation boundaries explicit instead of assumed.
• Issuer Binding: The requirement to verify which authorization server issued an authorization response and to bind credentials to that issuer. For MCP, it reduces mix-up attacks and keeps client trust aligned with the correct authorization authority.
• 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.

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 responsible for identity security strategy or programme maturity, it is worth exploring.

This post draws on content published by WorkOS: The biggest MCP spec update ships July 28 and what it changes for AI agent authentication. Read the original.