OAuth on MCP exposes the boundary between login and delegated action

At a glance

What this is: This guide explains why OAuth on MCP is not just sign-in plumbing, but a resource-bound delegation model that must separate authentication, audience scoping, and tool-level authorisation.

Why it matters: IAM and NHI teams need this distinction because MCP servers, agent sessions, and upstream APIs each create different trust boundaries that cannot be safely collapsed into one bearer token.

Context

OAuth on MCP is about delegated action, not just login. The core security question is which actor is allowed to invoke a tool, under what resource boundary, and with what downstream authority.

In an MCP deployment, the server is the protected resource and the client may be an AI assistant acting on behalf of a user. That makes audience-bound tokens, resource indicators, and per-call authorisation part of the identity design, not optional extras.

The article frames a common implementation mistake: treating a bearer token as if it alone can authorise every tool call. That is atypical enough to keep showing up because the protocol boundary is easy to miss.

Key questions

Q: What breaks when an MCP server passes client tokens to upstream APIs?

A: Token passthrough creates confused deputy risk because downstream services may accept a token that was issued for a different audience. That breaks authorization boundaries and can expose data or actions beyond the original MCP request. Each upstream dependency should receive its own token with its own audience and scope.

Q: Why do OAuth scopes not work well for MCP tool authorization?

A: OAuth scopes are coarse and fixed at token issuance, while MCP decisions are often per call and depend on the user, the tool arguments, and the specific record involved. A scope can say an agent may access a category of capability, but it cannot reliably decide whether this exact invocation should run. That makes scopes useful for broad access, not fine-grained tool control.

Q: How should security teams govern MCP servers that wrap REST APIs?

A: Security teams should govern MCP servers as agent-facing identity surfaces, not as simple API adapters. The key controls are tool scoping, resource separation, token-based authentication, and clear usage guidance so the model cannot infer broader privilege than intended. If those controls are weak, the MCP layer can concentrate access in ways that are harder to audit than the original API.

Q: What is the difference between coarse OAuth scopes and fine-grained authorisation in MCP?

A: Coarse scopes describe broad capability classes such as read, write, or admin, while fine-grained authorisation decides whether this specific call is safe in this specific tenant, session, and context. Scopes label the door; policy decides whether the room should open.

Technical breakdown

Why OAuth on MCP is a resource-server problem

MCP authorization starts with the protected resource, not the authorization server. The MCP server must identify itself as the resource, advertise trusted authorization servers, and require tokens issued for its own audience. That design prevents clients from presenting a token meant for a different API and calling it delegated access. The 2025-06-18 spec makes this explicit by treating the MCP server as a protected resource with discovery metadata, token audience checks, and a required separation between the MCP token and any upstream token used behind the server.

Practical implication: Treat the MCP server as a first-class resource server and enforce audience checks before any tool execution.

Why bearer tokens do not equal tool authority

A bearer token proves a session exists, not that every tool call inside that session is acceptable. MCP tools can read code, mutate infrastructure, create tickets, or send messages, so the authorisation decision has to move from login time to call time. Scope strings such as read, write, or admin are useful coarse labels, but they do not encode tenant, repository, user intent, session context, or argument sensitivity. That gap is where fine-grained authorisation sits, and where broad scopes alone fail.

Practical implication: Design policy checks per tool call and do not let OAuth scopes stand in for operational authorisation.

How delegated upstream access should stay inside the server boundary

When an MCP server needs to reach GitHub or another upstream system, the upstream token should stay in the server's trusted boundary. The MCP client should receive a token for the MCP server, not the upstream service's bearer token. If the server forwards the client token upstream, it erases the separation between user delegation and service-to-service authority. That pattern is especially risky in agentic workflows because the agent can then inherit capabilities the user never intended for direct tool execution.

Practical implication: Keep upstream credentials server-side and issue separate tokens for the MCP boundary and the external API boundary.

Threat narrative

Attacker objective: The objective is to turn a delegated MCP session into broader API authority than the resource owner intended, enabling unauthorised tool use and downstream data or action exposure.

1. Initial access occurs when a client is accepted with a token meant for the wrong audience, or when an MCP server forwards that token upstream instead of validating it as its own resource token.
2. Credential abuse follows because the bearer token now acts as a reusable pass for tool calls or third-party APIs that were never supposed to trust it directly.
3. Escalation happens when broad scopes or pass-through behaviour let the agent perform higher-risk actions than the user intended at login time.
4. Impact is a collapsed trust boundary where delegated action becomes indistinguishable from upstream API authority, increasing the blast radius of every tool call.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Audience binding is the real control plane on MCP: OAuth on MCP only works when the token is issued for the MCP server itself, not for a downstream API that the server happens to call. That breaks the old assumption that a bearer token can be treated as generic proof of delegated intent. In identity terms, the protected resource boundary now matters as much as the login event, and practitioners should model that boundary explicitly.

Token teleportation is a governance failure, not an integration shortcut: Passing a client token through to GitHub or another upstream API collapses two trust zones into one and removes the chance to enforce different policies at each boundary. The protocol is designed to keep the server responsible for upstream access, so the upstream token never becomes the agent's portable authority. Practitioners should treat pass-through as evidence of missing governance, not implementation convenience.

Fine-grained authorisation must sit at tool call time: OAuth can establish who the session belongs to, but it cannot determine whether this specific agent may delete a repository, write to production, or operate on poisoned context. That is the decisive governance gap in MCP deployments. Teams need to recognise that coarse scopes are necessary but insufficient, because tool risk is created by action, context, and audience together.

Delegated action is now the primary identity question for agentic systems: MCP makes the shift from human login to machine-mediated action visible, and that changes what IAM has to protect. The same session can carry very different risk depending on which tool is invoked and which upstream authority is touched. The implication is that identity governance must move from authentication success to action control and traceable consent.

Runtime consent needs a narrower concept of trust than traditional SaaS OAuth: In MCP, a user can approve a client session without approving every tool effect that follows. That means the governance model must distinguish between delegated presence and delegated permission. Practitioners should expect audit, policy, and approval logic to sit closer to the tool boundary than to the sign-in boundary.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

Authority should move closer to the tool boundary: MCP deployments will keep failing whenever teams treat sign-in as the end of the authorisation problem. The control that matters is whether the server can still distinguish a delegated session from permission to act on every downstream tool and API, which is exactly where many agentic workflows become overbroad.

Token separation is the architecture, not the implementation detail: Once an MCP server starts forwarding upstream tokens, the trust model has already been flattened. Teams that want durable governance should make separate credentials, separate audiences, and separate policy decisions the default design rather than an afterthought.

For practitioners

• Separate MCP and upstream tokens Issue an access token for the MCP server audience and keep any GitHub or other upstream credential inside the server's trusted boundary. Do not pass the client's bearer token through to a third-party API.
• Enforce policy at each tool call Evaluate subject, tool name, arguments, tenant, session, and environment before allowing tools/call execution. Use OAuth only to establish the session and use a gateway or policy layer for the actual decision.
• Require resource metadata discovery Make the MCP server publish protected resource metadata and require clients to discover the authorization server from that metadata before any token exchange. Reject flows that start from a hardcoded issuer alone.
• Map scopes to broad capability classes Use scopes for coarse categories such as read, write, or admin, then add per-tool and per-context rules for high-risk actions like delete_repo, webhook changes, or production writes.
• Keep device flow conditional Use device authorization only for constrained clients that genuinely cannot support browser-based authorization code flow with PKCE. Do not use it as a way to avoid proper redirect handling or client registration.

Key takeaways

• OAuth on MCP only works when the server is treated as a protected resource with its own audience-bound token boundary.
• Passing a client token through to an upstream API collapses delegated action into broad service authority and increases blast radius.
• Practical governance sits at the tool-call layer, where context and consent matter more than login success.

Key terms

• Audience-bound token: An access token that can only be used against a specific resource server or API. Audience binding limits replay, reduces token portability, and ensures that a credential minted for one task cannot be reused elsewhere.
• Protected Resource Metadata: Protected resource metadata is machine-readable discovery data published by a service so clients can find its authorization expectations. For agent registration, it tells the actor where to look for supported flows and how to discover the trust model without relying on ad hoc integration.
• Fine-Grained Authorization: Fine-grained authorization is access control that evaluates specific resources, actions, and context rather than granting broad application-level permission. For AI agents, this is the difference between merely connecting to a system and being limited to the exact data or action the task requires.
• Delegated action: An action performed by one identity on behalf of another, with some authority borrowed from the principal. In agentic environments, delegated action needs explicit scope, auditability, and revocation boundaries because the executor is not the same as the beneficiary.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.