OAuth scopes are not enough for secure MCP authorization

At a glance

What this is: This analysis argues that OAuth scopes are a necessary but insufficient layer for secure MCP authorization because they cannot model dynamic, role-aware tool access.

Why it matters: IAM and NHI teams need server-side authorization controls for MCP so tool access can reflect current roles, context, and task boundaries instead of static token claims.

👉 Read P0 Security's analysis of why OAuth scopes are not enough for secure MCP authorization

Context

MCP authorization becomes a governance problem as soon as autonomous or semi-autonomous clients can act across multiple tools on behalf of different users. OAuth scopes can bound broad capability, but they do not answer the operational questions that matter to IAM teams: who can run which tool, on which object, under what conditions, and with what sequencing limits. That gap is especially important when MCP is used in multi-user environments where identity context changes faster than token lifetimes.

In practice, the issue is not whether scopes are useful. The issue is whether teams mistake broad delegated privilege for complete authorization. For NHI governance, that mistake creates a trust gap between token issuance and real-time decision making, which is why server-side policy enforcement becomes the control plane that actually matters.

Key questions

Q: How should teams secure MCP authorization beyond OAuth scopes?

A: Teams should use OAuth scopes only as a coarse capability layer and enforce the real authorization decision on the server. That means evaluating user role, resource ownership, and request context at runtime, so access changes when policy changes instead of waiting for token expiry.

Q: When do OAuth scopes become a weak fit for access control?

A: Scopes become a weak fit when access must vary by user, resource, or task sequence. At that point, the token can no longer express the real policy without scope sprawl, and the result is either excessive privilege or unmanageable complexity.

Q: What is the difference between scopes and role-based authorization in MCP?

A: Scopes describe broad delegated capabilities, while role-based authorization decides whether a specific user may perform a specific action in a specific context. In MCP, scopes can gate the domain, but RBAC or policy logic must decide the actual tool invocation.

Q: Why do MCP tools need server-side policy checks instead of token-only controls?

A: Server-side checks are needed because tokens are static and cannot react to role changes, resource context, or harmful call sequences. The server sees the request at decision time, which is when least-privilege enforcement actually has to happen.

Technical breakdown

Why OAuth scopes break down in MCP authorization

OAuth scopes are designed to describe broad delegated permissions, such as read versus write access to an API surface. MCP tool access is narrower and more situational, because the server often needs to decide whether a specific user can invoke a specific tool against a specific resource at a specific moment. Once you try to encode that level of detail into scopes, the model becomes brittle and hard to maintain. You are no longer describing capabilities. You are rebuilding policy in token names, which does not scale well in multi-user environments.

Practical implication: Use scopes only as a coarse boundary, then enforce tool-level decision logic on the MCP server.

How static tokens create authorization drift

OAuth tokens represent a snapshot of permission at issuance time. That is acceptable for simple delegated access, but it is a poor fit for environments where roles, responsibilities, and policy obligations change continuously. If a user is promoted, moved, or restricted after a token is minted, the token will not reflect that change until it expires or is revoked. In MCP, that creates authorization drift, where the server is still honoring an outdated permission state. The result is excess access that persists longer than the business intent.

Practical implication: Short token lifetimes help, but runtime policy evaluation is what closes the drift between identity change and access change.

Why sequence-aware access matters for AI tools

MCP calls are not always isolated events. A user or agent can chain several valid tool invocations into a higher-impact action that would not be allowed as a single request. This is a familiar authorization failure mode in automation systems: each step looks legitimate, but the sequence crosses a boundary that the policy never intended to permit. Scopes are too coarse to reason about that kind of intent. Server-side authorization can inspect context, sequence, and resource scope before each action is allowed to proceed.

Practical implication: Evaluate whether your MCP controls can block harmful tool chaining, not just individual permitted calls.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Internet Archive breach — unsecured GitLab authentication tokens exposed 31M Internet Archive accounts.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

OAuth scopes are a transport control, not a governance model. They can help bind a token to a broad capability surface, but they do not define the business rules that decide who may do what under which conditions. That distinction matters because MCP is being used in environments where identity, role, and context all change quickly. Practitioners should treat scopes as a first checkpoint, not the authorization decision itself.

Static token design creates ephemeral trust debt. When permission is frozen into a token, the system inherits the assumptions that were true only at mint time. That debt grows when roles shift, access reviews lag, or multiple tools can be chained into an outcome that exceeds the original intent. The control objective is not more token detail, but less reliance on token permanence.

Fine-grained MCP authorization belongs where the context lives. The server is the only place that can reliably evaluate user identity, resource ownership, workload state, and policy at request time. That is the practical separation of duties between delegated access and enforcement. Teams should design for runtime decisions, not scope inflation.

Scope sprawl is the predictable failure mode when teams overfit OAuth to tool governance. Every new tool mapped to a new scope makes permissions harder to audit and tokens harder to reason about. A cleaner model is broad scopes plus server-side policy, with explicit checks for role, resource, and sequence. That gives practitioners a control structure they can actually operate.

From our research:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to the State of MCP Server Security 2025.
• 53% of MCP servers expose credentials through hard-coded values in configuration files.
• Use Top 10 NHI Issues to frame scope design alongside credential hygiene and access review.

What this signals

Scope-first MCP designs will not survive contact with real governance needs. Teams adopting autonomous tool access need runtime checks that can respond to identity drift, role changes, and task chaining. The control problem is no longer whether a client has broad permission, but whether the request is still valid in context at the moment it executes.

Ephemeral credential trust debt is the hidden risk in token-centric authorization. Once a static token is treated as a proxy for ongoing authority, every delayed revocation, stale role mapping, or overbroad scope becomes a residual access problem. That is why the operational focus should shift toward request-time policy evaluation and explicit ownership of MCP tool permissions.

The governance pattern here aligns closely with the NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10, because both stress access control as a living process rather than a one-time token decision. For NHI programmes, that means MCP authorization should be reviewed as part of least-privilege design, not as an OAuth implementation detail.

For practitioners

• Use scopes only for coarse capability binding Limit OAuth scopes to broad areas such as billing, calendar, or contacts, then enforce per-tool authorization in the MCP server using current user and resource context.
• Move role checks to runtime policy evaluation Re-evaluate user role, project ownership, and organizational policy on every sensitive MCP request so token claims do not outlive the access they were meant to represent.
• Test for tool-chaining abuse paths Review whether multiple allowed MCP calls can be combined into an action that exceeds intended privilege, and block that sequence with server-side controls and step-up checks.
• Reduce scope sprawl before it becomes brittle Keep scope names broad and stable, and avoid creating one scope per tool action when the permission logic belongs in policy rather than in token design.

Key takeaways

• OAuth scopes are useful for coarse MCP delegation, but they do not provide enough context for least-privilege authorization.
• Static tokens create access drift when roles, resources, and tool sequences change after issuance.
• Server-side policy evaluation is the control that turns MCP access from broad delegation into enforceable governance.

Key terms

• MCP authorization: MCP authorization is the control layer that decides whether an agent or client may use a specific tool in a specific context. In secure deployments, it must go beyond token claims and incorporate user identity, resource ownership, and policy at request time.
• OAuth scope: An OAuth scope is a coarse permission label attached to a token to indicate the kind of access a client may request. Scopes are useful for delegated API access, but they are too blunt to express nuanced role, resource, or sequence-based decisions on their own.
• Runtime policy evaluation: Runtime policy evaluation is the act of checking access rules when a request is made, rather than relying only on permissions embedded earlier in a token. For NHI governance, it is the mechanism that keeps authorization aligned with current roles and business context.
• Scope sprawl: Scope sprawl happens when teams create too many scope names to model fine-grained permissions, making tokens harder to manage and audit. It is a common sign that authorization logic belongs in policy enforcement, not in token taxonomy.

What's in the full article

P0 Security's full post covers the implementation detail this analysis intentionally leaves at the control-design level:

• How OAuth scopes are typically mapped to broad API capabilities in MCP environments
• Where scope-based models break down when teams need per-tool and per-user authorization
• Why static tokens become a maintenance problem when roles and policies change
• How server-side RBAC and policy logic can complement delegated access without scope inflation

👉 P0 Security's full post covers the scope limits, runtime policy argument, and RBAC balance in more detail.

Deepen your knowledge

MCP authorization, scope design, and runtime policy enforcement are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for AI agents or tool-enabled services, it is worth exploring.