OAuth on MCP exposes the boundary between login and delegated action

At a glance

What this is: This is an implementation guide showing that OAuth on MCP must treat the MCP server as a protected resource and add fine-grained authorization at the tool-call layer.

Why it matters: IAM teams need this distinction because delegated access for AI assistants, service workflows, and human users all break when resource-bound tokens are treated as sufficient authority.

By the numbers:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
• 53% of MCP servers expose credentials through hard-coded values in configuration files.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read PermitIO's implementation guide for OAuth on MCP and delegated access

Context

OAuth on MCP is a delegated access problem, not just a login problem. The MCP server is the protected resource, and the client may be an AI assistant, a CLI, or another automation layer acting on behalf of a user.

The governance gap appears when teams treat a token as proof of total authority. MCP needs server-bound tokens, discovery through protected resource metadata, and per-call policy checks so that tool access stays separate from upstream API access.

Key questions

Q: How should security teams govern delegated tool access in MCP environments?

A: Treat MCP as a protected resource with its own audience-bound tokens, then enforce policy at the tool-call layer. OAuth establishes the session, but it does not decide whether a particular action is safe for the current user, tenant, or runtime context. If the server can mutate state, the authorization decision must happen at each call.

Q: Why do bearer tokens create risk in MCP if they are reused across systems?

A: Bearer tokens become risky when they are portable across trust boundaries. In MCP, a token issued for the server should not be passed through to GitHub, a database, or another upstream API. Reuse collapses delegation boundaries and makes one session token operate like universal authority.

Q: What do security teams get wrong about OAuth scopes for AI tools?

A: They often treat scopes as if they were the whole authorization model. In practice, scopes are only broad capability labels. Safe MCP governance still needs per-call checks that consider the tool, the arguments, the tenant, the user delegation, and the runtime context before action is allowed.

Q: Who should be accountable when an MCP server over-authorizes an agent?

A: The organisation operating the MCP server is accountable for the boundary it exposes, even when the agent is acting on a user’s behalf. If the server forwards tokens or accepts the wrong audience, the failure is in governance design, not in the user’s consent flow.

Technical breakdown

Protected resource metadata and audience-bound tokens

In MCP, the server is the protected resource and must advertise where authorization lives through protected resource metadata. That discovery step matters because the client should request a token intended for the MCP server, not reuse a token meant for GitHub, a database, or another upstream API. Audience binding is what keeps a bearer token from becoming portable authority across trust boundaries. The spec also uses WWW-Authenticate on 401 responses to route the client into the correct discovery chain before OAuth begins.

Practical implication: Practitioners should validate that MCP tokens are audience-bound to the server and rejected if they are presented as upstream API tokens.

OAuth 2.1, PKCE, and dynamic client registration in MCP

MCP uses OAuth 2.1 as the delegated access foundation, with PKCE protecting authorization code flow for public clients and dynamic client registration reducing manual setup. That combination solves client onboarding, but it does not solve authorisation depth. A valid session can still carry excessive scope if the server maps OAuth too coarsely to tool access. The practical danger is not broken authentication. It is a structurally valid token granting too much tool authority inside a session.

Practical implication: Practitioners should separate session authentication from tool entitlements and review whether OAuth scopes are too broad for the tools they gate.

Fine-grained tool-call authorization versus upstream token pass-through

The article’s central architectural point is that MCP authorization ends at the server boundary and must continue at the tool-call layer. Passing the MCP client’s token through to GitHub or another upstream service collapses two trust domains into one. Fine-grained authorization evaluates the subject, tool, arguments, tenant, and runtime context before each call. That is what prevents a delegated agent from turning a general session token into unrestricted operational power.

Practical implication: Practitioners should enforce per-tool policy checks and never forward the client’s token to an upstream API unchanged.

NHI Mgmt Group analysis

OAuth on MCP only works when the MCP server remains a distinct protected resource. The spec’s discovery chain is not cosmetic. It separates the server that receives the request from the upstream systems the server may later call on behalf of the client. That boundary is what prevents token portability from becoming accidental system-wide authority. Practitioners should treat audience binding as the first governance control, not a detail left to implementation convenience.

Fine-grained authorization is the real control plane for MCP, not OAuth scopes alone. Scopes can describe broad capability, but they do not decide whether a particular tool call is appropriate at a particular moment. The article correctly frames this as a tool-call problem, because identity, context, and intent all matter once the server is allowed to mutate state. Practitioners should stop using scopes as a proxy for full delegation governance.

Token pass-through is a trust-boundary failure, not an interoperability shortcut. When an MCP server forwards the client’s token directly to GitHub or another upstream API, it erases the distinction between delegated access to the MCP server and delegated access to the upstream resource. That creates hidden blast radius and ambiguous accountability. Practitioners should preserve separate tokens for separate resource boundaries.

Delegated action in MCP exposes a runtime authorization gap that classic SaaS OAuth patterns do not close. The article makes a useful distinction between logging in and authorising a tool call. That distinction will matter more as AI assistants, service workflows, and human delegates converge on the same MCP layer. Practitioners should design for delegated action as a first-class identity pattern, not a side effect of session authentication.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• For teams mapping delegated access into policy, the next step is to review OWASP Agentic Applications Top 10 for runtime tool-use risk and authorization gaps.

What this signals

Token portability is the hidden MCP governance risk. Once a server can forward client tokens to upstream services, the organisation has lost the clean line between delegated session and downstream authority. That is why server-bound tokens and tool-level policy need to be designed together, not sequenced as separate projects.

With 97% of NHIs carrying excessive privileges, the governance lesson extends beyond MCP: any identity that can act on behalf of a user needs explicit scoping, lifecycle ownership, and auditability before it can be trusted in production.

The named concept here is delegation boundary collapse: the point at which a token meant for one protected resource is reused as if it were authority over another. Teams should watch for this pattern anywhere agents, gateways, and upstream APIs share credentials or session state.

For practitioners

• Bind every MCP token to the correct resource audience Reject any token that was not issued specifically for the MCP server instance receiving the request. Do not accept upstream tokens as substitutes for server-bound tokens, even when the user already consented elsewhere.
• Enforce per-tool authorization at call time Evaluate tool name, arguments, tenant, user delegation, and runtime context before each tools/call request. Use OAuth only for session establishment, not as a substitute for operational approval.
• Keep upstream API credentials inside the server boundary Store or broker GitHub and other upstream tokens on the MCP server side only, and never forward the client token unchanged to the upstream service. Separate front-door authentication from back-end delegation.
• Align scopes to broad capability, not full authority Map scopes to coarse classes such as read, write, or admin, then back them with policy rules that can deny unsafe combinations of tool, tenant, and context.

Key takeaways

• OAuth on MCP is only safe when the MCP server remains a protected resource with its own audience-bound tokens.
• Scopes reduce complexity, but they do not replace per-call authorization for tools that can change state.
• Forwarding a client token to an upstream API collapses trust boundaries and turns delegated access into overbroad authority.

Key terms

• Protected Resource Metadata: A discovery document that tells a client how to interact with a protected server and which authorization servers it trusts. In MCP, it is the first step in binding a token to the correct resource boundary instead of assuming any bearer token will do.
• Audience-Bound Access Token: An access token issued for one specific resource or server, not for arbitrary reuse across systems. For MCP, audience binding prevents a token intended for the MCP server from being replayed directly against an upstream API or another service boundary.
• Fine-Grained Authorization: Authorization that evaluates the actual action being requested, not just whether a session exists. In MCP, it means checking tool name, arguments, tenant, and runtime context before a call is allowed, because OAuth alone does not answer those questions.
• Delegation Boundary: The point where one identity’s authority stops and another system’s authority begins. In MCP, that boundary must remain visible between the client, the MCP server, and any upstream APIs, or tokens become portable power instead of constrained delegation.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by PermitIO: OAuth on MCP: The Comprehensive Implementation Guide. Read the original.