July 2026 MCP changes shift identity control to the auth layer

At a glance

What this is: The July 2026 MCP revision removes session-based transport state and formalises authorization behaviour, pushing more identity control into the auth layer.

Why it matters: IAM, NHI, and agentic AI teams need to rethink how MCP clients, servers, and enterprise IdPs share trust, because protocol changes now alter where identity decisions live.

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.

👉 Read Descope's analysis of the July 2026 MCP spec revision

Context

Model Context Protocol is becoming an identity boundary, not just a transport mechanism. The July 2026 revision removes session-centric assumptions and formalises authorization patterns that were previously left to implementers, which changes how teams should think about MCP governance, client trust, and delegated access.

For identity developers, the key issue is not whether MCP can move data between tools, but where the protocol expects trust to be established, retained, and revoked. That matters for NHI governance, enterprise-managed authorization, and the way AI clients inherit or request access on behalf of users.

This is a typical maturation pattern for emerging identity-adjacent protocols. Once deployments move from pilots to enterprise use, the hidden assumptions around state, consent, and client identity become governance problems rather than engineering conveniences.

Key questions

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: Why do stateless protocols still create identity risk for MCP deployments?

A: Because stateless transport removes connection memory, not trust requirements. Teams still need to bind every request, callback, and server-side handle to a verified identity, or they end up replacing session problems with state confusion and authorization drift.

Q: What breaks when MCP client identity is treated as a registration detail?

A: Trust becomes fragile when client identity is only a registration artefact. Domain-controlled client IDs, issuer validation, and metadata documents all require explicit governance, or migrated clients, stale credentials, and ambiguous ownership can create access paths that no one can revoke cleanly.

Q: Who should be accountable for MCP governance failures?

A: Accountability should sit across platform engineering, security, and the product owners of the workflows using MCP, because each owns a different part of the control plane. Security defines the policy, platform engineering enforces the server boundary, and the workflow owner approves the business purpose. If any one of those is missing, governance fragments quickly.

Technical breakdown

Stateless transport and the end of session identifiers

The revision replaces session-based transport with stateless HTTP, which removes reliance on Mcp-Session-Id and long-lived connection state. That does not remove identity risk. Instead, it shifts the security boundary from transport session management to request-level authorization and server-side state binding. Where a session ID previously served as a visible coordination token, the new model pushes implementers to treat any server-generated handle as an internal lookup key, not a credential. This is a narrower attack surface operationally, but a stricter trust model cryptographically.

Practical implication: stop treating transport state as identity and bind every server-side handle to a verified user identity.

MRTR, elicitation, and callback integrity

Multi Round-Trip Requests remove protocol-supplied correlation fields and replace them with requestState plus retry semantics. That sounds like an API detail, but it has direct identity consequences because the server can no longer rely on a built-in elicitation identifier to anchor OAuth state or callback continuity. Any design that uses requestState must preserve integrity across retries and instance changes, because the state now behaves like a portable trust container. The main failure mode is no longer session hijacking alone, but callback confusion and state tampering across distributed MCP infrastructure.

Practical implication: treat requestState as integrity-protected security data and never encode authorization logic directly into it.

Enterprise-Managed Authorization shifts consent to the enterprise IdP

EMA formalises a pattern where the enterprise identity provider becomes the policy decision point for MCP access, while the MCP server still issues scoped tokens. That matters because it replaces per-user, per-server consent sprawl with centrally managed trust relationships and admin-controlled policy. The protocol itself does not become more permissive; instead, the governance model becomes more legible. For identity teams, EMA is a sign that MCP is converging on enterprise authorization patterns already familiar from federated access and cross-app trust governance.

Practical implication: map MCP access decisions to enterprise IdP policy and avoid unmanaged consent at the client-server edge.

NHI Mgmt Group analysis

Statelessness does not weaken identity risk, it relocates it. The July 2026 MCP revision removes session state from transport, but the underlying governance burden remains. State handles, callback correlation, and authorization continuity still need trust binding, only now that binding sits in application logic rather than in the protocol surface. Practitioners should recognise that the control problem has moved, not disappeared.

Enterprise-managed authorization is the right response to consent sprawl, but it also exposes governance maturity gaps. When hundreds of users connect many MCP clients to many servers, delegated approval cannot scale as an end-user event. Centralising policy in the enterprise IdP aligns MCP with existing identity governance, but only if client registration, scope assignment, and revocation are already disciplined. The practical conclusion is that authorization governance must become a first-class deployment requirement.

Client identity is becoming a domain-control problem, not a registration convenience. The move from dynamic client registration to client ID metadata documents makes domain ownership part of trust evaluation. That creates a clearer enterprise model, but it also forces teams to decide which domains are authorised to represent software clients. Identity architects should treat that as a trust framework decision, not a protocol housekeeping change.

MCP is converging on a broader pattern: identity decisions belong outside the tool session. The protocol is steadily separating transport mechanics from trust control, which is the right direction for agentic and NHI-heavy environments. That also means policy, revocation, and issuer validation have to be managed at the identity layer, not inferred from runtime connection state. Teams that keep treating protocol changes as engineering-only issues will miss the governance shift.

Named concept: protocol-layer trust relocation. This revision shows how identity responsibility moves when transport becomes stateless and authorization becomes more explicit. The consequence is that teams must reassess where trust is anchored, because protocol convenience no longer doubles as a security control. Practitioners should expect more of these shifts as agent-facing protocols mature.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), 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, according to the same report.
• That governance gap is why practitioners should also review Ultimate Guide to NHIs for lifecycle and revocation patterns that map cleanly to protocol-level trust changes.

What this signals

Protocol-layer trust relocation: As MCP sheds session state, identity teams will need to move their controls upstream into registration, issuer policy, and callback governance. The operational win is simpler transport, but the programme risk is that hidden identity assumptions become harder to see until they fail.

With 92% of organisations agreeing that governing AI agents is critical but only 44% having implemented policies, the same gap will likely appear in MCP rollouts if teams treat protocol changes as developer work rather than identity governance. The question is not whether MCP can scale, but whether the surrounding IAM model can govern it.

Teams should expect more convergence between agent access governance and enterprise application policy. That makes standards such as the OWASP Top 10 for Agentic Applications 2026 and NIST AI Risk Management Framework useful reference points when mapping future controls.

For practitioners

• Inventory every MCP state dependency Identify any code that still treats session identifiers, elicitation identifiers, or requestState as security primitives. Replace those assumptions with verified user identity and server-side lookup keys.
• Rework authorization around enterprise policy Route MCP access through the enterprise IdP where possible, and define scope grants, approval paths, and revocation rules centrally instead of per client-server pair.
• Audit client registration trust rules If you use client ID metadata documents, define which domains can assert client identity and how changes to domain control affect trust. Treat domain ownership changes as access lifecycle events.
• Validate retry and callback integrity Protect callback state with integrity checks, store it separately from requestState, and verify that multi-instance retries cannot rewrite the terms of an in-flight authorization.
• Review deprecated MCP dependencies now Check for use of long-lived streams, DCR-based onboarding, and any code path that depends on removed handshake behaviour before the next protocol migration cycle.

Key takeaways

• The July 2026 MCP revision shifts identity responsibility away from transport state and into explicit authorization governance.
• Enterprise-managed authorization is the clearest signal that MCP is moving from developer convenience to governed enterprise access.
• Teams that do not rework client identity, callback integrity, and revocation boundaries will carry hidden trust debt into production.

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.
• Enterprise-Managed Authorization: Enterprise-managed authorization is a policy model in which the identity provider decides what an agent may do and encodes that decision into the token or access flow. It helps organisations keep control logic centralized instead of spreading entitlement decisions across many servers.
• Client ID Metadata Document: A trust model where the client_id resolves to a metadata document hosted by the client itself. The authorization server fetches that document to validate identity, which replaces open registration with a verifiable assertion and materially reduces impersonation and SSRF exposure.
• RequestState: Opaque state carried across a multi-round-trip authorization flow so a client can resume a partially completed request. It is not a credential, but it can become a security object if teams encode trust decisions into it instead of treating it as integrity-protected lookup data.

What's in the full article

Descope's full article covers the operational detail this post intentionally leaves for the source:

• A line-by-line changelog of the July 2026 MCP revision and which changes are breaking versus additive.
• Implementation guidance for authorization server behaviour, including issuer validation, client registration, and scope step-up.
• The full explanation of Enterprise-Managed Authorization and how Descope positions it inside its Agentic Identity Hub.
• Developer-oriented detail on requestState, elicitation, and the migration away from long-lived transport assumptions.

👉 The full Descope post covers authorization SEP details, EMA flow, and migration checkpoints for identity developers.

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