MCP Tool Call Authorization Models Compared

MCP tool call authorization is not one thing. It's five different models, each solving a different piece of the same problem: an AI agent, not a human, decides at runtime which tool to call and what data to hand it. Traditional OAuth was built for a person picking a fixed scope list at sign-in. MCP breaks that assumption completely, because the agent discovers tools dynamically and requests access to things nobody configured in advance.

The scale makes this urgent, not academic. MCP's SDKs have crossed 97 million monthly downloads, and there are more than 10,000 active public servers as of 2025. Yet only 8.5% of public MCP servers use OAuth at all, according to available security research. A single AI client might connect to thousands of servers it has never seen before. Pre-configured credentials don't scale to that, so the whole authorization model has to change shape.

Three consequences follow for anyone building this. Identity has to reach every single tool call, not just the moment a session opens. Scopes need to live at the tool level, because "access to the MCP server" tells you nothing useful about what an agent can actually do once inside. And consent has to be dynamic, since an agent can request a capability the user never thought about when they first logged in. Picking an authorization model here is an architecture decision, not a checkbox in a config file.

How the MCP authorization spec evolved from optional add-on to structured framework

Authorization in MCP started as optional, and technically it still is. When a server does support it, HTTP-based transports are expected to follow the spec; STDIO transports just pull credentials from the environment instead. That made sense in the early days, when client and server ran on the same machine and there was no network boundary to defend. Once servers started deploying remotely, the gaps became obvious fast.

The original spec let an MCP server act as both its own authorization server and resource server at once. That combined role is exactly what got separated. The June 2025 revision drew a hard line: MCP servers are OAuth Resource Servers, full stop, not Authorization Servers. Token issuance moved out to external identity providers, Okta, Azure AD, Auth0, that kind of infrastructure.

That split buys three things directly. Tokens get bound to a specific audience, so a token issued for one MCP server can't be replayed against another. It closes off confused-deputy attacks, where a server ends up acting with more privilege than the user actually granted. And it hands over SSO, MFA, and identity-level audit logging for free, without anyone having to build that from scratch.

November 2025 added step-up authorization. When a tool call needs more access than the current token allows, the server responds with a 403 and a WWW-Authenticate header carrying error="insufficient_scope" along with the scopes actually required. Simple mechanism, but it means servers don't have to pre-grant broad access just in case a session might need it later.

Then came the May 21, 2026 release candidate, finalized July 28, 2026, the biggest revision since the protocol launched. Sessions got removed at the protocol layer entirely. If a server needs to remember state across calls, it now mints an explicit handle and the client passes that back as a tool argument on the next call. Six Specification Enhancement Proposals hardened authorization further:

• Clients validate the iss parameter on authorization responses to block mix-up attacks (SEP-2468)
• Clients declare their OIDC application_type at registration so desktop clients stop getting misclassified (SEP-837)
• Registered credentials get bound to the issuing authorization server, with re-registration required if that server ever migrates (SEP-2352)
• Refresh tokens now get requested through the offline_access scope (SEP-2207)
• During scope step-up, clients compute the union of existing and newly required scopes rather than discarding the old ones (SEP-2350)
• Discovery through /.well-known/oauth-authorization-server got clarified (SEP-2351)

Enterprise-Managed Authorization also went stable as an extension in June 2026. And the spec clarified how clients should locate the metadata endpoint through /.well-known/oauth-authorization-server (SEP-2351).

Model A: Delegated external IdP, coarse-grained server-level access using existing identity infrastructure

This is the baseline pattern the June 2025 split was built around. The MCP server acts purely as an OAuth Resource Server. An external authorization server, Okta, Azure AD, Auth0, Keycloak, whichever one an organization already runs, handles issuing tokens and authenticating users. The MCP server's job is to validate tokens and check scopes. It never issues anything itself.

The upside is obvious: existing identity infrastructure just works. SSO, MFA, directory sync, all of it carries over without custom code. The spec calls out two grant types worth knowing. Authorization Code with PKCE (mandatory, not optional) covers flows where an agent acts on behalf of a specific human. Client Credentials covers machine-to-machine flows, an agent checking warehouse inventory with nobody standing behind it.

Dynamic Client Registration, defined in RFC 7591, lets clients register themselves programmatically instead of requiring a human to provision credentials manually. That matters enormously once agents start connecting to servers nobody configured ahead of time.

The gap is granularity. Scopes here typically apply at the server level. A token says "this client can talk to the MCP server," not "this client can call deleteDocument but nothing else." Security and identity validation are strong. Portability across any OAuth-compatible IdP is strong too. Implementation complexity is the lowest of any model here, mostly just pointing Protected Resource Metadata at an authorization server that already exists. Speakeasy's guidance treats this as the sensible default for teams just getting started.

Model B: Enterprise-Managed Authorization, centrally provisioned access without per-server consent screens

EMA went stable in June 2026, and Anthropic, Microsoft, and Okta are all building it in. The shift here: the organization's identity provider becomes the actual decision-maker for who gets into which MCP server. Administrators write policy once. Users just log in the way they already do.

Mechanically, it works like this. During SSO, the client gets an Identity Assertion JWT Authorization Grant, an ID-JAG, from the IdP. That grant gets exchanged for an MCP access token. Nobody sees a per-server consent screen. Access decisions run off group membership, role, and conditional access rules defined centrally in the IdP, not scattered across dozens of individual server consent flows that admins have to track separately.

This is the direct answer to the 10,000-plus active server problem. Asking a user to click through a manual consent screen for each one they touch simply doesn't hold up operationally at that volume. With EMA, provisioned servers just show up on first login.

Security-wise, access control sits where enterprise policy and audit already live, inside the IdP. Flexibility depends on having an IdP that actually supports EMA, and on its own it's still coarse-grained unless paired with per-tool scopes. Implementation complexity sits in the middle: IdP configuration work on one side, EMA support on the MCP server side.

Model C: Per-tool scopes and RBAC at the function level, least privilege where it actually matters

"Access to the MCP server" isn't a permission worth having. "Can call generateImage" is. "Can call deleteDocument" is. Per-tool role-based access control binds an agent or consumer to a narrow allow-list of specific tools, not to a server, a session, or a static key that opens everything.

The pattern documented in a WorkOS AuthKit writeup (July 14, 2026) works like this. The session carries the authenticated user's permissions. Each tool declares what permission it needs and checks the session against that requirement the moment it's invoked. A tool needing image_generation refuses to run if the session lacks it, and more than that, it doesn't even show up in the agent's available tool list. A read-only tool can't perform a write, not because some policy engine blocks it on the way out, but because it never asks for write permission in the first place. The capability simply doesn't exist for it.

A document management example makes the role mapping concrete:

• Viewer: readDocument only
• Editor: readDocument, createDocument, updateDocument
• Admin: all five tools, including deleteDocument and shareDocument

There's a design goal sitting underneath all this worth naming: Agent Experience, or AX. Minimizing how often a human gets interrupted with scope prompts while still enforcing fine-grained control at the tool layer is the goal. And least privilege here also concerns what an agent is permitted to see. It's about which data those tools can reach once they run, enforced through session context and org-level data isolation.

Security is the strongest of any model on this list, since a compromised credential only reaches the specific tool functions it was scoped to. Flexibility is good too, tools can get added or pulled from an allow-list without reissuing any credentials. Implementation complexity is higher, though, since it needs per-tool permission declarations and a permission store behind them. Most teams don't run this standalone. They layer it on top of Model A or Model B.

Model D: Session-scoped and time-limited credentials, containing the blast radius of a compromised token

Most production MCP deployments today still hand an agent one long-lived credential that opens everything its connected servers expose. That's the problem this model exists to fix. Instead of a static API key sitting around indefinitely, the agent exchanges a broad identity for a narrow, short-lived token scoped to one task.

The mechanics: the agent presents its own identity along with the user's grant, and gets back a token scoped to one action, one resource, and a short expiry window. When the task or session ends, access ends with it automatically. Renewing that token requires a new authorization flow rather than silent background refresh. If the token leaks somewhere along the way, the damage is limited to one task and a short window of time, not indefinite access to an entire account.

The July 2026 spec change connects directly here. Since protocol-level sessions got removed, there's no ambient session sitting around for an attacker to hijack. A server needing cross-call state has to mint an explicit handle, and the client carries it forward as a tool argument. Step-up authorization from November 2025 fits naturally into this pattern too, since when a tool call needs more access, the server returns a 403 with the required scopes, and the client requests a fresh, narrowly scoped token rather than the whole session getting elevated permissions upfront just in case.

Security is strong here, since any credential compromise doesn't persist. Sensitive operations force explicit re-authorization rather than riding on standing access. It fits task-bounded agentic workflows well, but it's a poor match for long-running autonomous agents that genuinely need persistent access over hours or days. Implementation complexity requires token exchange infrastructure plus some mechanism for a human to approve re-authorization when it's needed.

Model E: MCP gateway as centralized control plane, enforcing all prior models at a single choke point

A gateway sits between AI agents and the MCP servers they talk to, and handles authentication, tool routing, access control, and audit logging for every single tool call that passes through. The problem it solves is scale: production agents now connect to dozens of servers exposing hundreds of tools between them, and trying to enforce least privilege, session scoping, and audit logging separately on each server is not something anyone can rely on consistently.

What the gateway centralizes:

• One point of SSO and identity validation, instead of wiring credentials into every server individually
• Tool-level RBAC enforced before a call ever reaches the server it's headed for
• A tamper-proof, OTEL-compatible audit log of every call, with identity attached
• Policy updates that propagate instantly across every connected server, rather than requiring changes in a dozen places
• Dynamic Client Registration and audience validation handled at scale, so agent fleets don't need hard-coded credentials scattered across them

The market backdrop matters here. MCP-related infrastructure hit an estimated $1.8 billion in 2025, according to CData via getmaxim.ai, with healthcare, finance, and manufacturing driving the strongest demand. Those are exactly the industries where an audit trail assembled from a dozen individually implemented servers won't satisfy a regulator. Least privilege only means something in practice if a centralized policy layer actually enforces it at runtime, across every server and every agent touching the system. That's the role the gateway fills.

Security governance is strongest here of any model, though the gateway itself becomes a single point of failure and a high-value target worth defending accordingly. It adds latency, and it has to support every MCP transport type and authorization model in use across the fleet. Standalone, it's the most complex model to build. Using a platform built for this purpose instead of assembling the pieces individually brings that complexity down considerably. For security and platform teams, a working gateway turns them into something closer to an enabler of agent adoption than a bottleneck standing in front of it, since one integration gives every team governed access instead of every team wiring its own OAuth plumbing from scratch.

The security threats each model must account for, and where each one leaves gaps

Documentation from Invariant Labs, the OWASP MCP Top 10, and Simon Willison's writing (April through May 2025) named several attack classes specific to this protocol: tool poisoning, rug pull attacks, tool shadowing, cross-server exfiltration, confused-deputy and OAuth weaknesses, and prompt injection. Each authorization model above addresses some of these directly and leaves others untouched.

Tool poisoning is the sharpest example. It's adversarial instructions hidden inside tool descriptions, parameter schemas, or response content, text an agent reads and treats as trusted operational context even though a human never wrote or approved it. A 2025 analysis of open-source MCP servers found that 5.5% showed indicators of tool poisoning.

None of the five models fix that on their own, because tool poisoning is a trust problem in the tool's content, not an identity problem in who's calling it. A perfectly scoped, session-limited, gateway-enforced token can still hand a poisoned tool description straight to an agent that then acts on hidden instructions buried inside it. Authorization controls who can call what. They don't inspect what a tool says once it's called. That's the boundary worth being honest about: these models solve access control, and access control is necessary but not sufficient. Whatever gets built on top of Models A through E still needs a separate answer for content-level threats that live inside the tools themselves, not in the credentials used to reach them.