MCP Tool Call Authorization Models Compared

The Model Context Protocol standardizes how an AI model finds a tool and calls it. It says nothing about who's allowed to call that tool, under what conditions, or for how long. The omission is deliberate. MCP's designers left authentication, authorization, and transport security entirely to whoever builds the host, the client, and the server. This choice gives implementers the freedom to fit MCP into whatever identity system their enterprise already runs. The protocol ships with no default floor for security, and the NSA's May 2026 guidance states that many production MCP server implementations run with no authentication controls.

The risk compounds because of what MCP inverts about how software normally talks to software. In a conventional setup, a client queries a server and waits. MCP flips that: servers query and execute actions on behalf of clients, which opens attack paths that the API security tooling built over the last decade was never built to close. A firewall rule or an API gateway policy written for a known, fixed set of calls doesn't know what to do with a system designed to let the caller decide, in real time, what to call and with what arguments.

A traditional API client runs a fixed set of calls a developer wrote and tested in advance. An MCP client is a language model, choosing which tool to call, and constructing the arguments for that call, at the moment it runs, based on whatever text happens to be sitting in its context window. That text can come from a user, a document, a webpage the model just read, or output from another tool earlier in the chain. The authorization boundary in an MCP deployment doesn't just have to hold against an unauthorized caller. It has to hold against a caller that can be talked into misusing authorization it already has. That's the structural problem every enterprise deploying MCP has to solve for itself, because the protocol was never going to solve it for them.

The three trust boundaries every tool invocation crosses

Every tool call made through MCP passes through three separate trust boundaries, and weakness at any single one of them can cascade through an entire agentic pipeline.

The first boundary sits between the language model and the MCP client. The model reads a tool's description, a short piece of text explaining what the tool does and how to call it, and uses that description to decide when and how to invoke it. The model has no independent way to confirm that description is accurate or that it hasn't been tampered with since the last time it was read. That gap is the entry point for tool poisoning: an attacker who can alter a tool's description can redirect what the model does without touching a single line of the model's own code. The Postmark MCP incident from September 2025 shows how this plays out. A malicious npm package impersonating a legitimate email-sending MCP server passed standard review at install time, because it behaved exactly as advertised, until a later version quietly began covertly copying every agent-sent email to a domain the attacker controlled.

The second boundary sits between the MCP client and the MCP servers it talks to. The client has to authenticate itself to each server and verify that what comes back is legitimate. An industry security body identifies weak or missing authentication at this boundary as the most common implementation failure across MCP deployments, and the numbers back that up: only 8.5% of MCP servers currently use OAuth.

The third boundary sits between the MCP server and whatever systems it reaches on the model's behalf, file systems, databases, external APIs, cloud services. The server is acting as an agent for the requesting model, often carrying permissions that are far broader than any single request needs. Servers routinely aggregate credentials for several enterprise systems behind one interface, so risk concentrates in a single point of compromise. This is where a server exercises its own broad privileges on behalf of a user who was never entitled to them, or a proxy gets tricked into handing an attacker a valid authorization code it should never have released.

Multi-agent pipelines stack all three boundaries on top of each other. One agent's output feeds directly into another agent's input, so malicious content introduced at any single hop can propagate downstream, triggering unauthorized actions, leaking data, or hijacking the control flow of the whole chain. Detecting this kind of drift, tool poisoning, prompt injection, subtle changes in what an agent is actually doing versus what it's supposed to do, requires watching every tool invocation at the point where it happens, before it executes. Platforms like Runlayer combine visibility into every call with real-time threat scanning so an authorization violation or a compromised tool gets caught before it spreads across the rest of the pipeline.

Four authorization models on a spectrum from no enforcement to per-request identity binding

MCP authorization splits into four identifiable models, each answering the same three questions differently: who is calling, with what scope, and for how long. Most enterprises deploying MCP today are at the weak end of that spectrum, and the data on hosting platforms explains why: zero servers on one major hosting platform permit unauthenticated access, while a substantial share of servers hosted elsewhere do. The gap isn't a failure of individual engineering teams so much as a consequence of what the hosting environment defaults to.

Model one is no authentication. Any caller that can reach the server can invoke any tool it exposes, with no scoping, no identity attached to the request, no audit trail, and no way to revoke access short of taking the server down. This is also the most common pattern in the wild at scale: a scan of more than 500 servers found that 38% had no authentication whatsoever, and Trend Micro separately identified 492 MCP servers exposed directly to the internet with zero authentication in place.

Model two is static API keys or personal access tokens. Research analyzing a large corpus of open-source MCP server implementations found more than half rely on a static key or PAT sitting in an environment variable, with only a small fraction using OAuth. A static key proves the caller holds a pre-shared secret. It proves nothing about which user is actually behind that call, what scope they should have, or how long that access should last. One token grants the same upstream access to every user behind it, and this shared-credential blast radius is one of the two most common configuration failures Maxim AI's enterprise checklist finds in production MCP deployments. Revoking access means rotating a credential that may already be copied into several places, and there's no audience binding to stop a token issued for one purpose from being used for another. Static keys are fast to set up, which is the whole reason they remain so common despite the weak scoping and thin audit trail they leave behind.

Model three is OAuth 2.1 with PKCE, and it's the model the specification itself mandates for HTTP transports. The March 2025 MCP specification formalized OAuth 2.1 as the authentication standard for remote servers. The July 2026 revision hardened it further, adding issuer validation under RFC 9207, client-identity metadata documents, and a clarified step-up flow for handling insufficient-scope errors, building on resource indicators under RFC 8707 and protected-resource metadata discovery under RFC 9728 that had already been required since the 2025-06-18 revision. Under this model, MCP servers are treated as OAuth 2.0 resource servers, separated structurally from the authorization server, matching how enterprise OAuth already works elsewhere. OAuth 2.1 enforces per-client consent, strict matching on callback addresses, and audience-bound tokens, so a token minted for one server can't be replayed against another. What it doesn't close is session-level inheritance: once a session is authenticated, every tool call inside that session inherits the session's grant, rather than each call carrying its own proof of current entitlement. OAuth 2.1 is genuinely hard to implement correctly, and that is the main reason it stays the spec's mandate without becoming the dominant pattern in actual deployments.

Model four is per-invocation, zero-trust authorization with just-in-time credentials and token exchange. Authorization checking moves past the initial handshake, and it evaluates each tool invocation against the caller's current permission set, which can shift based on context, identity, and session state. At full maturity, every tool call carries its own signed authorization token, validated against current policy at the moment of invocation rather than at the moment the session started, using tokens that are short-lived, narrowly scoped, and good for only a single use or a small number of uses inside a defined window. Token exchange is the mechanism doing the identity binding: each call carries the caller's identity-provider token, exchanged against a short in-memory cache on a cache miss, with no credential stored long-term per caller. The trade-off is explicit. Maxim AI's analysis finds that removing a user at the identity provider takes effect within the cached token's lifetime, up to five minutes, or the provider's own token expiry if that's shorter, meaning revocation is near-instant rather than truly instant. High-privilege operations need explicit re-authorization under this model instead of leaning on whatever the session already granted, so standing permissions for the most sensitive actions go away. Understanding where a given deployment currently sits on this spectrum, and how far it is from that target state, is the real first step toward MCP governance that can survive contact with production traffic.

Threat classes mapped to authorization gaps

Each authorization model closes off certain attack paths but leaves others wide open, so if you map threat classes to models, picking a model becomes an actual risk decision instead of a compliance checkbox.

Token passthrough stays open under models one, two, and partially three. If you forward an upstream token straight through to a downstream tool call instead of running it through OAuth 2.0 token exchange, a credential meant for one audience can reach systems it was never issued for. Wiz Research has documented how a compromised intermediate service can reuse a forwarded token against additional targets, a multi-hop risk that static keys can't prevent and that session-level OAuth 2.1 doesn't fully close either. Model four closes this by design, since no credential gets forwarded. Every call carries only the caller's current identity token, exchanged fresh each time.

Confused deputy risk stays open under models one, two, and partially three as well. It needs two preconditions to exist: permission scopes that are broader than necessary, and no authorization check at the level of the individual action. Both are characteristic of static-key deployments and session-scoped OAuth alike. Microsoft's analysis describes the pattern directly: an attacker uses the server's own privileges to reach data or actions the user was never entitled to, sometimes without the user ever approving anything. Audience-bound tokens under model three cut this down substantially. Per-invocation scoping under model four closes it further, because it makes sure the privilege set active at the moment of invocation matches the current user's entitlements instead of something inherited from earlier in the session.

Tool poisoning and dynamic description updates stay open across all four models, because none of them inspect the content of a tool description. A poisoned description sails through any credential check untouched, because that check only verifies who's calling, not what they're being told to call. Microsoft's Incident Response team found that MCP reflects tool metadata updates dynamically, so in setups where a changed description doesn't trigger a re-approval step, the updated instructions go live in production with no human ever looking at them. OX Security's April 2026 disclosure found remote code execution against six live production platforms, rooted in a structural flaw in how MCP's STDIO transport is designed, but Anthropic has formally declined to fix that flaw at the protocol level, so a large number of potentially vulnerable instances are still running.

Credential aggregation blast radius is partially addressed by model three and closed by model four. A single MCP server often holds credentials for several systems at once, and it asks for broader scopes than any task actually needs. CVE-2026-32211, carrying a CVSS score of 9.1, describes a missing authentication vulnerability in the Azure MCP Server that let an attacker reach configuration details, API keys, and authentication tokens without presenting any valid credential at all, though a patch is now available. The "Agentjacking" incident affected a large number of organizations through injectable DSNs, reaching a high rate of successful agent execution in testing, and Sentry chose a partial fix, deploying only a payload-string filter rather than full remediation.

Multi-agent cascading injection stays open at every authorization level without additional pipeline-level controls layered on top. One agent's output becomes the next agent's input, and malicious content introduced anywhere in that chain can propagate forward, triggering unauthorized behavior, leaking data, or hijacking control flow across the full sequence of chained MCP processes. No single authorization model, on its own, stops this. Closing it means treating every inter-agent output as untrusted input and enforcing authorization independently at every hop. Enterprise deployments that take this seriously increasingly pair their authorization model with centralized policy enforcement and audit, so that every tool call, wherever it sits in a multi-agent chain, is traceable to a specific identity and checked against security policy before it's allowed to run.

The July 2026 spec revision and the new authorization baseline

The July 2026 MCP specification revision is the clearest signal yet that the authorization baseline for MCP is not fixed. It moves every six months or so, and enterprise planning has to treat it that way rather than freezing a deployment around whatever the rules said a year ago.

The headline change is structural. The revision eliminated the Mcp-Session-Id header. Under the prior model, you authenticated a session once, and every tool call inside that session rode on the strength of that single initial handshake. With the session anchor gone, every request now has to carry its own identity and version metadata and stand on its own merits at the moment it's made. That is a direct architectural push toward model four, the per-invocation, zero-trust approach, because the protocol no longer offers a session-level shortcut to fall back on.

The revision also hardened OAuth 2.1 itself. Issuer validation under RFC 9207 closes a gap that let a malicious authorization server masquerade as a trusted one. Client-identity metadata documents give servers a verifiable way to confirm which client is actually making a request. A clarified step-up authorization flow now handles insufficient-scope errors more precisely, so if a server needs more permission mid-session, it can ask. These additions build on resource indicators under RFC 8707 and protected-resource metadata discovery under RFC 9728, both of which had already been required since the 2025-06-18 revision and remain unchanged in this one.

None of this changes the fundamental division of labor the protocol set up from the start: MCP tells implementers how tools get discovered and called, and leaves every decision about authentication, scope, and identity binding to whoever builds the deployment. That division is why every organization running agents against MCP servers at any real scale has to treat authorization as a foundational architectural decision, made deliberately and revisited as the spec evolves. The spec will keep moving. The four models described here give a way to locate a given deployment on that spectrum today, and a way to reason about how far it still has to move.