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

At a glance

What this is: This is WorkOS's analysis of the MCP 2025-11-25 spec update, which formalises async Tasks, newer OAuth patterns, extensions, and enterprise access controls for agent-facing tool ecosystems.

Why it matters: It matters because identity, consent, and delegation patterns for MCP are moving from one-off integrations toward governable NHI and agent access models that IAM teams will need to standardise.

Context

Model Context Protocol is moving from a developer convenience layer into a governed integration substrate, and that changes the identity problem. Once MCP sessions carry long-running work, delegated OAuth, and server-initiated tool use, the question is no longer whether agents can connect, but which identities can act, for how long, and under what policy.

The central governance gap is that early MCP deployments treated client, server, and user consent as a loose implementation choice. This release tightens that model by standardising async execution, client identity metadata, enterprise-managed access, and machine-to-machine auth, which makes the protocol much more relevant to NHI governance and agentic control design.

For IAM and security teams, the important shift is not feature count but control surface. MCP now has enough structure to expose lifecycle, authorisation, and audit decisions that were previously hidden inside custom integrations.

Key questions

Q: What breaks when MCP access is still handled through ad hoc app-to-app consent?

A: The main failure is governance visibility. Administrators can see that a user approved an integration, but they often cannot see which downstream non-human actions are now possible, what scopes were granted, or how to revoke the path centrally. That creates shadow delegation, weak accountability, and difficult offboarding for AI apps and other machine actors.

Q: When should organisations prioritise OAuth over simpler authentication for MCP?

A: Organisations should prioritise OAuth when an MCP server can touch user-specific data, production systems, or privileged actions. OAuth is more operationally complex, but it gives the team consent, revocation, and scope controls that simple authentication methods usually lack. That matters as soon as the server becomes part of the enterprise identity boundary.

Q: How do security teams tell whether MCP client metadata is still trustworthy?

A: Look for stable ownership, controlled hosting, accurate redirect URIs, current signing keys, and consistent fetch behaviour from the authorisation server. If the metadata location changes often, keys drift, or the document cannot be tied to a clear owner, the trust model is already weakened and authorisation decisions become fragile.

Q: What is the difference between CIMD and Dynamic Client Registration?

A: CIMD makes the client publish a metadata document at a stable HTTPS URL and lets servers fetch it, while Dynamic Client Registration writes client state into the server. CIMD is better suited to open, high-scale MCP ecosystems, but DCR still fits tightly governed environments that need a local registration record.

Technical breakdown

Tasks turn long-running MCP work into stateful execution

The Tasks primitive gives MCP a native async pattern. Instead of forcing a tool call to block until completion, a server can return a task handle and move the work through states such as working, input_required, completed, failed, and cancelled. That matters because it separates request initiation from result retrieval, which is the right model for expensive jobs, human-in-the-loop checkpoints, and agent plans that need to continue across multiple steps. In identity terms, the task becomes the unit of control, not the raw session. That makes status, resumption, and cancellation visible enough for governance, but it also widens the surface for policy decisions around who can resume, observe, or delegate the task.

Practical implication: Treat task handles as governed objects and define who can create, resume, and cancel them.

CIMD changes OAuth from per-server registration to metadata-based trust

Client ID Metadata Documents replace repeated client registration with a stable metadata URL that identifies the MCP client during OAuth. The authorization server fetches that document and uses it to validate the client’s app identity, redirect URIs, and keys. That removes a lot of registration sprawl, but it also shifts trust from a local portal workflow to DNS, HTTPS, and metadata integrity. For NHI governance, this is a meaningful change because client identity now has a published lifecycle and a stable reference point. It also means that metadata drift, stale redirect configuration, or compromised hosting can now become authorisation failures rather than simple admin mistakes.

Practical implication: Govern client metadata as an identity artefact and monitor it for drift, tampering, and stale keys.

Enterprise-managed access makes MCP policy visible to the IdP

Cross App Access inserts the corporate identity provider into the flow so that downstream access to MCP servers is no longer hidden inside app-to-app OAuth consent. That is important because direct authorisation between an AI app and a downstream service leaves administrators with poor visibility into who can act, what scopes were granted, and how to revoke access centrally. The enterprise model introduces a policy checkpoint before the downstream token exists, which changes MCP from an app-side consent problem into an identity governance problem. For teams running agentic integrations, that is the difference between shadow access and auditable delegation.

Practical implication: Route downstream MCP authorisation through enterprise policy so access is centrally revocable and auditable.

NHI Mgmt Group analysis

MCP is becoming an NHI control plane, not just a protocol. The release adds enough structure around async work, client identity, and enterprise access to make governance decisions explicit instead of implied. That matters because the protocol now defines how non-human actors request, continue, and inherit access in production, which is exactly where identity programmes tend to lose visibility. Practitioners should treat MCP as governed delegation infrastructure, not an integration convenience layer.

Client identity metadata creates an identity lifecycle where none existed before. CIMD turns the client itself into a named, hosted identity artefact with stable metadata and trust anchors. That is a stronger model than ad hoc registration, but it also means the trust boundary now includes metadata hosting, domain control, and cache consistency. The practitioner implication is simple: if the metadata is stale or compromised, the authorisation decision is already wrong before the token is issued.

Cross App Access formalises enterprise control over agent reach. The old pattern hid delegated access inside app-to-app OAuth, which made user consent visible but enterprise policy opaque. With IdP-mediated policy in the loop, the governance problem shifts from “did the user click approve?” to “did the organisation explicitly allow this non-human access path?” That is the right question for IAM and NHI teams because agent reach without central policy is just consent dressed up as control.

Ephemeral protocol features do not remove credential risk; they make scope governance the primary issue. The article’s own backdrop shows how quickly secrets and tokens can sprawl around MCP ecosystems. That means the control objective is no longer merely protecting a secret store, but limiting how far a client, task, or agent can act once a credential exists. Practitioners should re-centre on scope, lifecycle, and revocation, because protocol maturity changes the shape of the blast radius more than it eliminates it.

Runtime governance gap: MCP now exposes the difference between a tool that can connect and a tool that can be governed. The release shows that agent ecosystems need policy hooks at metadata, task, and enterprise-consent layers, not only at the API layer. For identity leaders, the field is moving toward delegated access models that look much more like NHI governance than conventional software integration management.

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: MCP Security Guide

What this signals

Protocol maturity is shifting MCP governance from consent events to delegation systems. As Tasks, CIMD, and Cross App Access become normalised, teams will need to model MCP interactions as lifecycle-managed non-human access rather than one-off integrations. That means identity review, revocation, and audit design now belong in the architecture conversation, not as a later control overlay.

Ephemeral access does not equal low risk. Even when tokens are short-lived, the real governance question is how much authority a task or client can accumulate during its lifetime and how quickly that authority can be withdrawn. The more MCP becomes a standard path for agents and automation, the more security teams will need to anchor controls in scope and delegation rather than in token duration alone.

For practitioners

• Define governance for task handles Classify task handles as governed execution objects and decide which identities can create, resume, observe, or cancel them across long-running workflows.
• Inventory client metadata trust Review every MCP client metadata endpoint for ownership, hosting controls, redirect URIs, and key rotation so identity metadata cannot drift unnoticed.
• Move downstream access into IdP policy Use enterprise-managed access paths for MCP where possible so downstream authorisation is enforced through central policy rather than isolated app consent.
• Standardise M2M OAuth for headless agents Use a single machine-to-machine auth pattern for background services and headless agents so service identity and token scope are not reimplemented per integration.

Key takeaways

• MCP 2025-11-25 adds governance primitives that make long-running work, delegated OAuth, and enterprise policy easier to manage in production.
• The article’s own backdrop shows why this matters: MCP configuration files exposed 24,008 unique secrets in 2025 alone, so protocol growth is arriving alongside real credential sprawl.
• Security and IAM teams should treat client metadata, task handles, and enterprise-managed access as first-class identity objects, not just implementation details.

Key terms

• 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.
• Cross App Access: An ecosystem name for IdP-mediated app-to-app authorization in enterprise environments. It allows an identity provider to approve or deny AI app connections centrally, reducing hidden delegation and making downstream access revocable from one place instead of inside every connected tool.
• Task handle: A task handle is the durable reference returned for a long-running MCP execution. It lets a client poll status, request results, or cancel the work later. In identity terms, the handle is a capability, so it must be scoped to the same actor and context that created it.
• Machine-to-machine OAuth: An OAuth flow used by services or headless agents that authenticate without a human interaction step. In MCP, this pattern supports background automation, but it also requires strict scope, ownership, and revocation controls because no person is present to review each request.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle 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.