MCP Server Identity Model: Authentication, Authorization, and Trust for the Model Context Protocol

What MCP is and what its identity model actually is

The three actors:

• MCP Client / Agent: the AI system that calls tools. Holds OAuth tokens. From the spec's perspective, an OAuth client.
• MCP Server: the thing that exposes tools to be called. From the spec's perspective, an OAuth resource server (and often also an OAuth authorization server, when it provides its own auth flow).
• OAuth Authorization Server: the issuer of access tokens. Sometimes co-deployed with the MCP server, sometimes separate.

The MCP protocol itself defines the message format for tool listing, tool invocation, resource access, and prompt serving. The MCP Authorization specification defines how OAuth 2.1 layers on top.

Server discovery and the trust bootstrap

How does an agent find MCP servers to use?

Three patterns in 2026, in increasing order of risk:

1. Pinned servers (allowlist): the agent runtime ships with a configured list of MCP servers it may use. The user cannot add new ones at runtime; an admin manages the list. Highest trust, lowest flexibility. Production-default for enterprise deployments.

2. User-provided servers with confirmation: the agent can use a server the user explicitly provides, but each new server is shown to the user with a confirmation prompt before the agent uses it. Trust delegated to the user, who is in the loop for each addition.

3. Auto-discovery from URLs in conversation: the agent picks up MCP server URLs from documents, web pages, or tool responses and starts using them. Highest risk; the agent's surface area is determined by content sources it doesn't fully vet. Acceptable only in low-stakes contexts.

The risks of accepting unknown servers:

• The server itself may be malicious. Its tool results can attempt to manipulate the agent (prompt injection on the agent's planner), exfiltrate context, or trick the agent into invoking other tools harmfully.
• The server's OAuth flow may be designed to harvest credentials, register the agent under attacker control, or redirect tokens.
• The server's tool descriptions may misrepresent what tools do; the agent invokes "summarize this document" and gets "exfiltrate document contents to attacker.com."

Treat MCP server URLs with the same caution as code dependencies. The allowlist is the production default; the auto-discovery pattern is for research demos.

OAuth authorization server metadata

Discovery is two hops. The MCP server MUST publish OAuth 2.0 Protected Resource Metadata (RFC 9728), usually advertised in the WWW-Authenticate header of its first 401. That document names the authorization server. The agent then fetches OAuth 2.0 Authorization Server Metadata (RFC 8414) or OpenID Connect Discovery from that issuer:

GET https://<authorization-server>/.well-known/oauth-authorization-server

This returns a JSON document describing:

• issuer: the authorization server's issuer URL.
• authorization_endpoint: where to send the user for consent.
• token_endpoint: where to exchange codes for tokens.
• client_id_metadata_document_supported: true when the server accepts a Client ID Metadata Document URL as the client_id.
• registration_endpoint: where to do Dynamic Client Registration, if offered.
• scopes_supported: the set of scopes the server defines.
• response_types_supported: which OAuth response types are accepted.
• token_endpoint_auth_methods_supported: how the client may authenticate to the token endpoint.

The agent uses this metadata to drive the OAuth flow without per-server hand-coding.

Client registration: CIMD first, DCR as fallback

The 2025-11-25 MCP authorization spec changed the default. Authorization servers and clients SHOULD support OAuth Client ID Metadata Documents, and MAY support Dynamic Client Registration, which the spec keeps "for backwards compatibility." A client that supports everything follows this order:

1. Use a pre-registered client_id if it has one for that server.
2. Use a Client ID Metadata Document if the server advertises client_id_metadata_document_supported.
3. Fall back to Dynamic Client Registration if the server publishes a registration_endpoint.
4. Ask the user to paste client details.

With CIMD, the client_id is an HTTPS URL that the client controls, such as https://agent.example.com/oauth/client.json. The authorization server fetches that JSON document, checks that its client_id field matches the URL exactly, and validates the redirect URI against the document. Nothing is written to the server's client table, so there is no registration sprawl to clean up. The server-side risks move instead: fetching a client-supplied URL is an SSRF vector, and a localhost redirect URI lets an attacker claim to be a legitimate client. Block special-use IP ranges on fetch, cap the document size, show the client_id hostname on the consent screen, and warn on localhost-only redirects. The longer explainer is the apex post on Client ID Metadata Documents.

For enterprise tenants there is a third layer on top: the Enterprise-Managed Authorization extension lets the customer's own identity provider decide, per user, which MCP servers an agent may reach, using an ID-JAG token exchange instead of a per-server consent screen.

Dynamic Client Registration, when you still need it

Older clients and servers still use DCR (RFC 7591). The agent POSTs a JSON document to the registration endpoint:

{
  "client_name": "Calendar Assistant",
  "redirect_uris": ["https://agent.example.com/oauth/callback"],
  "grant_types": ["authorization_code", "refresh_token"],
  "scope": "tools:read tools:write"
}

And receives back a client_id, client_secret (or alternative auth credential), and a registration_access_token for managing the registration.

Open DCR accepts requests without an initial-access-token gate and grants the scopes the client asked for. If you keep a DCR endpoint, tighten it:

• Initial Access Tokens (RFC 7591 §3): gate the registration endpoint. The IAT is issued out-of-band by an admin or by an automated provisioning system that authenticates the agent platform.
• Scope policies per IAT class: different IATs map to different allowed scope sets. An agent registering with an "internal-tools" IAT can request internal-tool scopes; an external-agent IAT cannot.
• Software statements (RFC 7591 §2.3): a signed JWT from the agent platform vendor attesting "this software is what it claims to be." Lets the MCP server know the registering software is a vetted agent runtime, not arbitrary code.
• Registration TTL: registrations expire and require refresh, so stale clients accumulate less.

The pattern: treat DCR as authenticated registration, not anonymous. Anonymous registration is fine for development; production needs gates.

Per-tool authorization within a server

The MCP spec defines tool listing and invocation but does not standardize per-tool authorization. Once the agent has a valid access token for the MCP server, the server's logic decides which tools the token is permitted to invoke.

The patterns:

Per-tool OAuth scopes. The MCP server defines scopes like tools:calendar:read, tools:calendar:write, tools:email:send. The OAuth server issues tokens scoped per tool. The MCP server checks scope in the access token against the tool's required scope.

Pros: standard OAuth machinery, easy to audit. Cons: requires re-issuing tokens when the agent needs new scopes (chatty for highly-dynamic agents).

External policy evaluation. The MCP server, on each tool invocation, calls out to an external policy engine (OPA, Cedar, Permify, Authress, Auth0 FGA) with the principal (from the access token), the tool name, and the arguments. The policy engine returns allow/deny.

Pros: fine-grained, dynamic, decoupled from token issuance. Cons: per-call latency, requires policy authoring.

JIT permission elevation. The agent does not hold broad scopes. For each tool call, the agent requests a narrow short-lived token from the auth server. The auth server evaluates against policy and either issues the token, denies, or escalates to human approval. The agent presents the narrow token to the MCP server.

Pros: minimal standing surface, every action has an explicit grant. Cons: highest latency, requires JIT support in the auth server.

Production deployments commonly combine: coarse OAuth scopes for "this agent may use this server's tools at all," plus per-call policy evaluation for "this specific invocation is permitted given the principal, the resource, and the context."

Cross-server delegation and the chain problem

When an agent uses multiple MCP servers and operations span them (read a document from server A, send it via server B), how does authority flow?

Three patterns:

1. Independent tokens per server. The agent holds one OAuth token per MCP server. Each tool call uses the relevant token. The MCP servers do not need to know about each other.

2. OAuth token exchange across servers. Server A issues a token; the agent exchanges it via RFC 8693 for a token bound to server B's audience, with attenuated scope. Server B sees the chain in the exchanged token's claims.

3. Capability tokens. The token from server A is a capability that the agent can attenuate and pass to server B without contacting any issuer. Useful for deep chains where issuer roundtrips are prohibitive.

Pattern 1 is the default and the simplest. Patterns 2 and 3 matter when the audit trail needs to show cross-server authority flow, or when a downstream server needs to make decisions based on the upstream context.

Audit log requirements for MCP

Per-invocation audit on the MCP server should record:

• Principal: the OAuth client_id (the agent), the user it acts for (from the token claims), the source IATor IAT class if available.
• Tool: which tool was invoked.
• Arguments: what the tool was called with (sanitized for sensitive data).
• Result: success / denied / approval_required / error.
• Decision rationale: which scope or policy rule produced the result.

The MCP server is positioned to be the most informative audit point in the agent stack. It sees the full tool invocation graph as it happens. Servers that ship strong audit log structure for the MCP layer (and stream it to SIEM) are the ones that make agent incident response possible.

Implementation guidance

1. Pin your MCP server allowlist for production. Auto-discovery is a research feature, not a production one.
2. Adopt OAuth 2.1, not OAuth 2.0. PKCE mandatory, refresh-token rotation mandatory. OAuth 2.1 Explained for the details.
3. Support CIMD, and gate any remaining Dynamic Client Registration endpoint with Initial Access Tokens and scope policies. Open registration is open in the worst sense; CIMD fetches need SSRF protection.
4. Per-tool scopes for coarse authorization, policy engine for fine-grained. The combination is the production pattern.
5. One OAuth issuer per organization is the cleanest deployment, with each MCP server as a distinct resource audience.
6. Short-lived tokens, sender-constrained. Token Management for AI Agents covers the rationale.
7. Audit everything, principal + tool + args (sanitized) + result + reason. Stream to SIEM.
8. Test client identification adversarially. Can a CIMD URL point at an internal address? Can a localhost redirect impersonate a known client? If DCR is on, what scopes can an attacker register for, and what clients accumulate over time?