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: the April 2026 specification adds role-based access control within a server, so authorization granularity matches the individual tool rather than the server as a whole.
  • Enterprise identity bridging: the Enterprise-Managed Authorization (XAA) extension uses ID-JAG to let an enterprise identity provider issue authorization grants that MCP servers honour, replacing per-server static credentials with tokens derived from SSO identity.

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 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 — which 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 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. As of 2026 more than half of real-world MCP servers still authenticate with static API keys rather than OAuth, and a disclosed design vulnerability affected roughly 200,000 servers. 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 much of the ecosystem still needs 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, tool-level authorization, enterprise identity bridging via ID-JAG — are specified rather than aspirational. 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.