Model Context Protocol (MCP)

Model Context Protocol (MCP) is the de facto standard for connecting AI models and agents to external tools, APIs, and data repositories, and its authorization model has consequently become the boundary at which most agent access to enterprise systems is actually granted or denied. MCP servers act as OAuth 2.1 resource servers and MCP clients as OAuth 2.1 clients, which means an organization exposing internal capabilities over MCP is making an authorization architecture decision rather than merely integrating a tool format. The gap between what the specification requires and what deployments do is currently the dominant risk.

Authorization Model

Four properties distinguish MCP's authorization design from an ordinary API integration:

  • Per-server token audience: RFC 8707 Resource Indicators are mandatory, so a token issued for one MCP server cannot be replayed against another. This closes the confused-deputy path that arises when a single broadly scoped token is reused across every tool an agent can reach.
  • Incremental scope consent: agents request the minimum access each operation needs rather than a blanket scope at session start, which bounds the damage a redirected agent can do to the tools it has actually been authorized for.
  • Tool-level authorization: a server can require a different scope per tool and answer an under-scoped call with a step-up challenge, so granularity can match the individual tool rather than the server as a whole. The specification (current revision 2026-07-28) defines no role model inside a server, though; which role may call which tool is left to the implementation.
  • Enterprise identity bridging: the Enterprise-Managed Authorization extension uses the Identity Assertion JWT Authorization Grant (ID-JAG) to let an enterprise identity provider issue authorization grants that MCP servers honour, replacing per-server static credentials with tokens derived from single sign-on (SSO) identity.

Revision 2026-07-28 also changes how a client becomes known to an authorization server it has never seen. The client identifies itself with a URL, and the authorization server fetches the Client ID Metadata Document at that URL to learn the client's name and redirect URIs; Dynamic Client Registration (RFC 7591) is deprecated and kept only for authorization servers that cannot read those documents. Clients must now check the issuer in every authorization response (RFC 9207) before redeeming the code and may not reuse credentials obtained from one authorization server at another, which closes the mix-up attack in which a client is tricked into sending a code to the wrong server. For the owner of an authorization server, the review that registration used to force becomes a policy on which client ID domains to accept, as the OAuth 2.1 article describes.

Tool-level granularity is also what makes a human approval checkpoint meaningful: where a tool call is irreversible or high-value, the approval should be requested for that call through Client-Initiated Backchannel Authentication (CIBA) rather than confirmed inside the agent, since a dialogue the agent renders is not an authorization event the server observed.

The OpenID AuthZEN Working Group has adopted a dedicated profile for MCP tool authorization: COAZ-MCP, the Model Context Protocol binding of the COAZ (Compatible with OpenID AuthZEN) mapping framework. It projects MCP calls and their parameters into an authorization request and so externalizes those tool-level decisions to a policy decision point instead of implementing them inside each server. For organizations already running externalized policy-based access control (PBAC), this is the integration path that avoids a second, MCP-specific policy silo.

EmployeeAI agent (MCP client)MCP serverInternal systemEnterprise IdPAuthorization server prompttoken requesttoken for this server onlytool call + tokenacts within granted scopeID-JAG grant
The MCP server is the boundary: it is an OAuth 2.1 resource server, and the token the agent carries is valid for it alone.
AI agent (MCP client)MCP serverPolicy decision pointInternal systemToken validationTool authorization audience checkedtool calldecision requestpermitted call
Inside the server, validating the token and deciding whether a particular tool may be called are separate steps — and only the second is one an external policy decision point can answer.

Specification Versus Deployment

MCP's authorization design is sound; its deployment reality is not. Many MCP servers still authenticate with static API keys or personal access tokens rather than OAuth, and the local STDIO transport, which starts a server by running whatever command the client's configuration names, has produced a series of remote code execution vulnerabilities in the tooling built on it, among them CVE-2025-49596 in the project's own MCP Inspector. Static keys defeat every property listed above at once: they carry no audience restriction, no per-operation scope, no user context, and no expiry.

This matters because MCP servers are unusually easy to stand up, and an internally built server that wraps a privileged system with an API key inherits that system's full authority with none of the surrounding controls. The OpenID Foundation's AI Identity Management Community Group is running interoperability demonstrations specifically to show MCP flows secured with open identity standards, which is a reasonable signal of how many implementers still need convincing.

When Not to Use MCP

MCP is frequently applied where a narrower interface would serve better. Adopting it by default carries an abstraction tax: a well-designed command-line interface or an existing HTTP API often gives an agent everything it needs without an additional protocol layer. From an identity perspective the argument against reflexive adoption is stronger still, because every MCP server is a new authorization surface that must be inventoried, scoped, monitored, and eventually decommissioned. Where an existing API already enforces authorization correctly and the agent can call it directly, placing an MCP server in front of it adds a trust boundary without adding a control.

The case for MCP is strongest where it earns that overhead — structured tool contracts consumed by many heterogeneous clients, dynamic tool discovery, or a genuine need for the incremental consent model — and weakest where it is adopted simply because it has become the expected way to connect an agent to something.

Summary

MCP's authorization specification is a credible application of OAuth 2.1 to agent tool access, and the properties that matter (audience-restricted tokens, incremental consent, per-tool scopes, enterprise identity bridging via ID-JAG) are specified rather than aspirational; role-based decisions per tool are the one part a deployment must supply, ideally through the AuthZEN profile. The practical work is therefore not evaluating the protocol but governing its use: inventorying which MCP servers exist, eliminating static API key authentication, and deciding deliberately which integrations justify a new authorization boundary at all. Servers exposing sensitive systems should be treated as first-class resource servers subject to the same review as any other, and their tool invocations logged with both agent and user attribution. That dual attribution is what keeps abuse attributable after the fact, including the case where an agent has been redirected by injected instructions and every individual call it makes is correctly authenticated and within scope.