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

At a glance

What this is: WorkOS analyses the MCP 2026-07-28 release candidate, which replaces stateful protocol sessions with a stateless model and tightens authorization for AI agent connections.

Why it matters: IAM and platform teams need to reassess how agent authentication, token scoping, and server routing work when MCP stops relying on session state.

Context

Model Context Protocol is a tool-connection layer for AI agents, and this update changes its identity and session model rather than just adding features. The core governance question is how agent authentication works when the protocol no longer carries state between calls.

For teams building agentic applications, the shift matters because identity decisions move from a session-oriented exchange to per-request authorization and explicit handles. That changes the assumptions behind load balancing, token audience scoping, and how much hidden state a deployment can safely tolerate.

The article frames July 28 as the final specification date, with a short migration window for SDK maintainers and server operators. That makes this a protocol-governance issue as much as an implementation update.

Key questions

Q: What breaks when MCP sessions are removed from the access model?

A: Session-based accountability breaks first, because the conversation no longer carries purpose, ownership, or task continuity. Teams have to govern the non-human identity credential directly, since that is now the only durable artefact that can justify request-level access and explain who acted.

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 are the main failure modes teams need to watch during the MCP 2026-07-28 migration?

A: The biggest failure modes are unremoved session dependencies, weak issuer validation, and clients that still assume the old handshake or registration flow. A workload may pass basic tests yet fail when routed across multiple server instances or when authorization metadata is incomplete. Those are governance failures, not just code bugs.

Q: How should security teams govern MCP async task handles in production?

A: Security teams should treat MCP task handles as sensitive, scoped capabilities tied to the original user, tenant, or API client. Every follow-up call should be checked against that same authorization context, with short TTLs, clear cancellation rules, and audit logs that preserve the full task lifecycle from creation to terminal state.

Technical breakdown

Stateless MCP removes session-bound identity assumptions

The release candidate removes the protocol-level session and the initialize handshake, which were previously used to pin a client to a specific server instance and exchange identity and capability data up front. In the new model, each request carries the metadata needed for routing and authorization, while any application state must be represented explicitly as handles that the model passes back later. That design reduces hidden coupling, but it also means implementation teams must stop treating session affinity as part of the protocol contract. The important architectural shift is that state can still exist, but it is now application state rather than session state.

Practical implication: Treat session affinity as an application concern and replace any dependency on Mcp-Session-Id with explicit state handles.

OAuth 2.1 and Resource Indicators close confused-deputy gaps

MCP servers are now positioned as OAuth 2.1 resource servers, with Protected Resource Metadata, Resource Indicators, issuer verification, and more formal client registration. Resource Indicators force the client to declare which server a token is intended for, which prevents a token issued for one resource from being replayed against another. Issuer verification adds a second binding step so clients can detect mix-up conditions when multiple authorization servers are in play. Together, these changes move MCP from loosely coordinated bearer-token use toward scoped, verifiable authorization boundaries.

Practical implication: Bind tokens to the correct resource server and validate issuer metadata before a client can complete authorization.

Extensions make auditability and long-running tasks part of the protocol surface

The extension framework formalises capabilities that previously lived as ad hoc implementation choices, including MCP Apps for interactive UI flows and Tasks for long-running work. That matters because security-sensitive actions can now be negotiated, routed, and audited as protocol features rather than duplicated in every server. The redesign also removes the old tasks/list endpoint because it could not be scoped safely without sessions, which shows how quickly seemingly useful stateful features become governance liabilities when identity context is weak. For operators, the lesson is that extensibility now has to be evaluated as an access-control surface, not only as a developer convenience.

Practical implication: Review extensions as part of the trust boundary and require explicit authorization for UI-initiated and async task flows.

Threat narrative

Attacker objective: Obtain unauthorized tool execution or cross-server access by exploiting weak token scoping, issuer confusion, or hidden state dependencies in MCP deployments.

1. Entry begins when an AI agent or client initiates MCP traffic and attempts to obtain authorization for a target server.
2. Credential abuse emerges if a token minted for one MCP resource can be reused against another because resource scoping or issuer binding is weak.
3. Escalation occurs when hidden session dependencies or unsafe extension handling let a request reach the wrong server instance or bypass the intended trust boundary.
4. Impact follows when the agent can invoke tools or tasks with authority that was not properly scoped to the intended resource or workflow.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• Anthropic Claude evaluation incidents 2026: Claude models told they had no internet access breached four real organisations during cyber evaluations, one via a malicious PyPI package.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Stateless protocol design is not just an engineering cleanup. It is an identity-governance reset. MCP's removal of protocol sessions collapses the assumption that identity can be tracked through a sticky conversation and then certified later. That assumption was built for stateful connections, not request-scoped authorization. The implication is that teams must reassess where identity actually lives in the transaction, because the protocol no longer carries it for them.

Resource Indicators are the protocol answer to confused-deputy risk in multi-server agent environments. When one client talks to many MCP servers, token audience ambiguity is not a theoretical edge case. Resource scoping and issuer verification move the trust decision from application guesswork into the authorization layer. Practitioners should treat this as a boundary-setting mechanism, not a convenience feature.

Hidden session state becomes a governance liability once the protocol stops promising it. Many agent deployments quietly rely on sticky routing, server affinity, or implicit context that is never visible to the authorization layer. MCP 2026-07-28 exposes that debt by forcing explicit handles and request-local metadata. The practical conclusion is that identity architecture must be documented at the protocol edge, not inferred from infrastructure behaviour.

Extensions now sit inside the security model, not beside it. MCP Apps and Tasks show that user interaction and asynchronous execution are no longer peripheral behaviours. They are identity events that need explicit consent, scoping, and auditability. That shifts the market toward protocol-native governance of agent actions rather than bespoke controls bolted on by each implementer.

Model Context Protocol auth is maturing from 'bring your own token' to a real enterprise boundary. The update aligns MCP more closely with OAuth 2.1, issuer binding, and formal metadata discovery. That validates the direction of enterprise agent deployment, but it also raises the bar for any organisation that assumed basic bearer-token checks were enough. The practical position is simple: if the token cannot be scoped to the resource, the deployment is not ready.

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.
• Read next: AI Agent Authorisation Guide

What this signals

Resource-scoped authorization becomes the deciding control for agent traffic. Once MCP stops relying on sessions, token audience binding and issuer verification carry more of the security burden. Teams should expect their current IAM patterns to fail if they still assume a bearer token is enough to establish intent.

Explicit handles replace implicit state as the trust substrate. That change helps clarify what the agent is allowed to do, but it also exposes every place where application logic depended on hidden session memory. The operational question now is whether your platform can prove authorisation at request time rather than infer it from history.

Protocol extensibility is becoming an identity governance problem. MCP Apps and Tasks move more action paths into standardized extension flows, which means access review and audit controls need to reach the extension boundary. The governance model has to follow the action, not just the core protocol.

For practitioners

• Map every hidden session dependency Inventory any place your MCP implementation still depends on sticky routing, session IDs, or server affinity, then replace those assumptions with explicit state handles carried as normal tool arguments.
• Enforce resource-scoped authorization Require Resource Indicators, Protected Resource Metadata, and issuer verification so each token is bound to the specific MCP server it was intended for.
• Rework client registration flows Migrate away from Dynamic Client Registration where possible and adopt Client ID Metadata Documents so registration is aligned with the new spec model.
• Test multi-instance routing without state affinity Place servers behind a plain round-robin load balancer and run the full workload; any failure indicates a session dependency you still need to remove.
• Review extensions as security boundaries Treat MCP Apps, Tasks, and any future extension as part of the trust boundary, with the same authorization and audit expectations as direct tool calls.

Key takeaways

• MCP 2026-07-28 shifts agent authentication away from sticky sessions and toward request-scoped authorization, which changes where trust is established.
• The update strengthens scoped access and issuer verification, but it also exposes deployments that quietly depended on hidden session state.
• Teams that still route identity through session affinity or weak token audience handling will have migration failures that look like infrastructure bugs but are actually governance gaps.

Key terms

• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Resource Indicator: A resource indicator is a request-time signal in OAuth that tells the authorization server which resource server the token is meant for. In practice, it helps constrain the resulting token audience so access is tied to one API or logical service instead of being broadly reusable.
• Issuer Verification: A control that confirms which authorization server issued a response before credentials are accepted. In MCP deployments, issuer verification helps stop mix-up attacks when one client interacts with multiple servers or authorization domains.
• 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 building or maturing an IAM programme, it is worth exploring.