Model Context Protocol Nov 2025 Specification Update: CIMD, XAA, and Security

The Nov 25, 2025, specification update for the Model Context Protocol (MCP) is out.

For those of us working in Identity, this is the update that starts to solve the hard problems of connecting AI agents to real-world business data. It moves the protocol away from custom solutions and aligns it with standard OAuth patterns that developers and security teams already understand.

Here is a breakdown of the identity and security changes in this release.

Client Identity Metadata Documents

One of the most practical changes in this update is how clients, such as AI agents, introduce themselves to servers. The spec now focuses on CIMD, which is a much cleaner approach than dynamic registration.

Instead of registering with every single server manually, an MCP client identifies itself using a URL it controls, like https://myapp.com/client.json. When the client connects, it uses this URL as its client_id. The authorization server just fetches the JSON file from that URL to verify the client's identity, logo, and redirect_uris. This change moves trust to DNS and HTTPS, which means you don't have to manage thousands of API keys or manual registrations, and establishes that if you trust the domain, you can trust the client.

Client ID Metadata Documents Are the Future of MCP Client Registration

Discover why Client ID Metadata Documents are replacing Dynamic Client Registration in the Model Context Protocol ecosystem for better security.

Enterprise-Managed Authorization with Cross-App Access

The update adds support for Authorization Extensions, specificallyXAA.

Integrating AI agents into an enterprise often forces a trade-off between user experience and security visibility. Users suffer from "consent fatigue" due to constant prompts, while IT teams struggle to track exactly which agents are accessing which data.

XAA solves this by shifting authorization from the individual to the organization. Instead of relying on users to manually approve every connection, IT administrators can create centralized policies that pre-authorize trusted AI agents (Requesting Apps) to access specific business tools (Resource Apps).

This flow is built on the Identity Assertion Authorization Grant, an emerging OAuth standard. It allows an agent to securely request a token from the Identity Provider on the user's behalf, ensuring access is both seamless for the employee and fully governed by IT.

Local Server Security

Running MCP servers locally on a developer's machine gets a specific security check in this update (SEP-1024). As detailed in the updated Security Best Practices, clients now have to get explicit user consent before installing or running a local server. They also can’t hide what they are doing — the client has to display the exact command being executed. This ensures that "consent" covers granting execution privileges on your machine, which is critical for preventing arbitrary code execution issues during local development.

Incremental Scope Consent

The November update also improves support for incremental consent via standard HTTP headers (SEP-835). An MCP server can now pause a request to say it needs additional permissions. It uses the WWW-Authenticate header to prompt the client to ask the user for that specific access right exactly when it is needed. This supports least privilege: agents don't need to ask for everything upfront. They can ask for permissions progressively as the user actually asks them to do things.

MCP Moving Towards Zero Trust

The November MCP specification update is a pivot point for MCP security. By standardizing on CIMD for identity and introducing XAA for governance, the protocol has moved away from ad-hoc connections toward a model that can support Zero Trust enterprise environments.

If you are looking to implement these secure patterns for your own agents or tools, check out our documentation on Auth for MCP to get started.