MCP 2025-11-25 adds tasks, OAuth, and enterprise controls

At a glance

What this is: MCP 2025-11-25 formalises async tasks, simpler OAuth, extensions, and enterprise access controls for agentic and machine-to-machine workflows.

Why it matters: It matters because identity teams now have to govern MCP traffic as a real access path for AI agents, service accounts, and enterprise apps, not just as a developer integration layer.

By the numbers:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments.
• 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.

👉 Read WorkOS's analysis of the MCP 2025-11-25 spec revision

Context

MCP 2025-11-25 is really about access governance, not just protocol polish. As MCP moves from local demos into enterprise workflows, the question becomes who can act, under what identity, with what scope, and with what audit trail when requests are asynchronous and tool use is no longer one simple round trip.

The new Tasks primitive, CIMD-based OAuth flow, and Cross App Access all reduce friction, but they also make MCP a more durable identity surface. For IAM and NHI teams, that shifts MCP from a developer convenience to a governance problem that spans service accounts, delegated access, and agentic execution paths.

Key questions

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

A: Security teams should govern MCP access the same way they govern any other high-value identity path: define the owning identity, constrain the scopes, centralise approval where possible, and log every tool action. MCP becomes risky when it bypasses normal IAM visibility, so enterprise policy, audit, and revocation must sit on the path, not beside it.

Q: Why do async MCP tasks change the risk model for IAM teams?

A: Async tasks change the risk model because the work continues after the original request finishes. That creates a durable execution state that can outlive the user session, which means access review, logging, and containment now have to follow a task object rather than a single call. Identity teams should treat that as a governed workload, not a transient request.

Q: What do organisations get wrong about delegated OAuth access in MCP?

A: Organisations often assume delegated OAuth access is automatically visible and revocable because the human user approved it. In practice, downstream tool access can remain opaque unless the IdP stays in the loop, scopes are standardised, and revocation is centralised. Without that, the app-to-app chain becomes difficult to audit and harder to shut down cleanly.

Q: Should teams use the same controls for human, service, and agent MCP identities?

A: No. Human sign-in, service credentials, and agentic execution each need different policy handling even when they use the same protocol. Humans need consent and session controls, service identities need lifecycle and rotation governance, and agentic paths need tighter scope, shorter-lived assertions, and stronger task-level logging.

Technical breakdown

Tasks change MCP from synchronous calls to governed work units

The Tasks primitive turns a request into a durable work object that can move through states such as working, input_required, completed, failed, and cancelled. That matters because long-running tool calls no longer depend on an open connection or ad hoc polling logic. Instead, clients can subscribe to a task handle and retrieve results later, which creates a standard control point for progress, retries, and state visibility. In identity terms, this makes the execution unit explicit, which is important when tools are invoked by agents or background services rather than by a human waiting on a response.

Practical implication: treat task handles as governed execution artefacts and tie them to identity, scope, and audit records.

CIMD replaces per-server registration with URL-anchored client identity

Client ID Metadata Documents move MCP away from dynamic client registration and toward a decentralized identity model. The client presents a URL it controls as the client_id, and the authorization server retrieves metadata from that URL to complete the OAuth flow. That reduces registration sprawl, but it also shifts trust to DNS, HTTPS, and the correctness of the metadata document. In enterprise terms, the control question becomes whether the client identity document, redirect URIs, and signing keys are stable, revocable, and auditable enough for policy enforcement across many downstream servers.

Practical implication: govern client metadata as a real identity object, not a convenience file, and validate it like any other trust anchor.

Authorization extensions make enterprise policy part of MCP access

The release introduces machine-to-machine client credentials support and Cross App Access for enterprise-managed user flows. Together, those extensions cover two different access patterns: headless automation that needs token issuance without a user present, and delegated access where the IdP remains in the loop for allowlisting and central policy. That is a major shift for identity architecture because MCP interactions are no longer just app-to-app OAuth exchanges. They become policy-mediated access paths with clearer ownership, narrower consent boundaries, and a more usable audit model.

Practical implication: route MCP access through centrally governed OAuth and map each extension to the correct identity type and approval model.

Threat narrative

Attacker objective: The objective is to gain durable, policy-shaped access to tools and data through an identity path that looks legitimate but can be used to expand reach across sessions and systems.

1. Entry begins when a client or agent establishes access through MCP's OAuth flow, task handle, or extension-enabled integration rather than through direct credential theft.
2. Escalation occurs when the actor uses async tasks, M2M client credentials, or server-side sampling to continue actions beyond a single user interaction or review point.
3. Impact follows when the actor can perform multi-step tool use, maintain access across sessions, or operate with enterprise-reachable permissions through the MCP layer.

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

MCP 2025-11-25 turns protocol design into identity governance design. The release moves MCP from a thin integration layer toward a governed execution environment where identity, scope, and auditability must be managed continuously. That is why IAM teams should treat MCP traffic as a first-class access surface, not as a developer convenience. The implication is that protocol adoption now creates identity obligations, not just integration opportunities.

Tasks create an execution object that identity teams can finally see, but also have to govern. Asynchronous work makes tool use durable enough to observe, resume, and correlate, which is helpful for auditability. It also means privilege is no longer bounded by a single request-response exchange. Practitioners should expect more complex entitlement mapping and more places where execution can cross policy boundaries before a human notices.

Client ID Metadata Documents sharpen the decentralised trust model, but they also make the client identity document itself part of the control plane. The old assumption that OAuth clients register one by one at each server no longer holds. That breaks the idea that trust is primarily negotiated locally at the point of use. The implication is that enterprise identity teams must treat client metadata, redirect control, and document integrity as governable trust anchors.

Enterprise-managed MCP access is emerging because consent-based app-to-app OAuth is too weak for modern delegated workflows. Cross App Access addresses the visibility gap where an IdP can see the human login but not the downstream AI app or tool access. That makes this release a marker of where the market is heading: more central policy, less unmanaged delegation, and a stronger expectation that AI-adjacent integrations fit existing identity governance rather than bypass it.

Sampling with tools is the clearest sign that server-side agent loops are becoming a normal MCP pattern. Once servers can initiate multi-step reasoning with tools, the boundary between client, server, and agent becomes harder to manage with static scopes alone. The practitioners' conclusion is simple: agentic workflows need identity models that account for who can start work, who can extend it, and who can see the resulting actions.

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.
• The same SailPoint research found that only 44% of organisations have implemented any policies to govern AI agents, which leaves most deployments without formal behavioural controls.
• For a broader governance lens, see OWASP Agentic Applications Top 10 for the control patterns that map most directly to agentic access paths.

What this signals

Agentic protocol sprawl is becoming an identity governance problem before it becomes a platform problem. As MCP grows new auth and extension layers, the practical challenge is no longer whether tools can connect. It is whether each connection can be owned, reviewed, and revoked with the same discipline applied to other non-human identities. That is why the move to central policy is a governance signal, not just an interoperability improvement.

Ephemeral access is only safe when the revocation story is complete. With more task-based and machine-to-machine flows, the real question is how quickly an enterprise can prove who had access, what they did, and whether that access still exists. With 80% of organisations reporting agent behaviour beyond intended scope in the SailPoint research, the operating assumption should be that policy drift will happen unless review is continuous.

Client identity documents and task handles are likely to become new audit objects in agent-heavy estates. That means IAM and compliance teams should prepare to ingest more non-human artefacts into access governance, SIEM correlation, and incident response. Identity blast radius: the spread of impact caused when a delegated identity can chain into multiple tools, and it becomes a useful concept for prioritising controls around MCP paths.

For practitioners

• Inventory MCP-connected identities and execution paths Map every MCP client, server, and downstream tool to its owning identity, transport, and approval model. Separate human-initiated flows from background or service-to-service flows so you can assign the right policy boundary.
• Treat client metadata as a governed trust object Validate the stability of client_id URLs, redirect URIs, and signing keys before allowing enterprise use. Put ownership and revocation procedures around the metadata document so the trust anchor is not left unmanaged.
• Route delegated MCP access through central policy Prefer IdP-mediated controls for enterprise access rather than letting app-to-app OAuth drift into shadow approvals. Use allowlists, short-lived assertions, and audit trails to keep downstream tool access visible.
• Classify async tasks as auditable work units Attach identity, scope, and logging metadata to task handles so long-running work can be traced across retries and state transitions. This is especially important where an agent can resume work after the original request context has gone stale.
• Review server-side sampling for recursive access growth Test whether tool-enabled sampling can multiply privilege across nested calls or delegated workflows. If it can, constrain which identities may initiate sampling and which tool sets they can invoke.

Key takeaways

• MCP 2025-11-25 pushes the protocol into governed enterprise access, not just faster tool integration.
• Async tasks, CIMD, and centralised authorisation all increase visibility, but they also create new identity artefacts that must be controlled.
• Identity teams should now treat MCP as part of their non-human and delegated access estate, with task-level logging and revocation built in.

Key terms

• Model Context Protocol: An open protocol that lets AI clients and servers connect to tools, data, and actions through a standard interface. In practice, MCP becomes an identity problem as soon as it carries real access, because the protocol now defines who can act, what they can reach, and how those actions are governed.
• Client ID Metadata Document: A URL-hosted identity document that replaces per-server client registration in OAuth-based MCP flows. It anchors client identity in a retrievable metadata object, which makes trust more scalable but also shifts governance onto the stability, ownership, and integrity of that document.
• Cross App Access: An enterprise access pattern that keeps the identity provider in the authorisation path when one application needs to access another. It matters in MCP because it restores visibility, policy control, and revocation over delegated access that would otherwise happen as opaque app-to-app OAuth.
• Task handle: A durable reference to an async unit of work that can be polled, resumed, completed, or cancelled later. For MCP, task handles are not just technical plumbing. They are auditable execution objects that can outlive the original request and therefore need identity and logging controls.

Deepen your knowledge

MCP governance, delegated OAuth, and non-human identity control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building policy for agentic and machine-to-machine access, it is worth exploring.

This post draws on content published by WorkOS: MCP 2025-11-25 adds async Tasks, better OAuth, extensions, and a smoother agentic future. Read the original.