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

For each MCP server an agent may connect to, the agent fetches OAuth 2.0 Authorization Server Metadata (RFC 8414) at the well-known URL:

GET https://<mcp-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.
• registration_endpoint: where to do Dynamic Client Registration.
• 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.

Dynamic Client Registration: how agents become clients

Most MCP deployments expect agents to register as OAuth clients dynamically (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.

The defaults in the MCP spec lean toward openness — the registration endpoint accepts requests without an initial-access-token gate, the registered client gets the scopes it asked for. Production MCP deployments tighten:

• 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. Gate Dynamic Client Registration with Initial Access Tokens and scope policies. Open registration is open in the worst sense.
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 the registration endpoint adversarially. What scopes can an attacker register a client for? What clients accumulate over time? What deprovisioning happens?