TL;DR: P0 Security shows that OAuth scopes are useful for delegated MCP access, but they cannot express dynamic user roles, contextual resource boundaries, or sequence-aware permissions, according to P0 Security. Secure MCP authorization still needs server-side policy evaluation because static tokens do not match changing privilege models.
At a glance
What this is: This analysis argues that OAuth scopes are necessary but insufficient for MCP authorization because they capture broad delegated capability, not runtime decisions about who may run which tool under which conditions.
Why it matters: IAM and NHI teams need to treat MCP as a policy-enforcement problem, not a token-design problem, or they risk overbroad access, scope sprawl, and weak least-privilege controls.
👉 Read P0 Security's analysis of why OAuth scopes are not enough for MCP authorization
Context
OAuth scopes are a delegation mechanism, not a complete authorisation model. In MCP, that distinction matters because tool access has to reflect user role, resource context, and the conditions under which an action is allowed, not just whether a client once received a token.
The governance gap is that static scopes cannot keep pace with changing entitlements. When permissions move with promotions, project boundaries, or policy changes, the server must make the final decision at request time rather than trusting the token alone.
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: 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: What breaks when an MCP server relies on token validation alone?
A: Token validation proves that a caller has a valid token for the server, but it does not prove the action should execute. If teams stop at audience checks and token introspection, they can still allow unsafe tool calls on sensitive records. The gap is especially dangerous when tool outcomes depend on arguments that were not known when the token was issued.
Q: What is the difference between OAuth scopes and RBAC in MCP?
A: OAuth scopes mark broad delegated capabilities, while RBAC assigns permissions through roles that the server can interpret at runtime. In MCP, scopes can support the outer boundary, but RBAC is what lets the system decide whether a specific tool call is actually allowed.
Technical breakdown
Why OAuth scopes fit delegation but not tool-level policy
OAuth scopes were built to describe coarse API permissions such as read or write access over a capability set. That works when a client needs to act on a user's behalf within a broad boundary. MCP tools, however, often need finer authorisation because the same tool may be allowed for one project, denied for another, or limited by the caller's role. Once the scope becomes a substitute for policy, it stops being a lightweight grant and starts trying to encode business rules it was never designed to hold.
Practical implication: keep scopes as broad capability markers and move tool-specific decisions into server-side policy.
Why static tokens break runtime authorisation
OAuth tokens are snapshots. They preserve the permissions that existed when they were issued, even if the user's role or the organisation's policy changes before the token expires. That creates a time gap between entitlement changes and enforcement. In a dynamic MCP environment, that gap can leave a promoted, reassigned, or offboarded user operating with stale permissions. The authorisation problem is therefore not just what the token says, but whether the server can re-evaluate privilege at the moment the request arrives.
Practical implication: design MCP services to re-check identity and policy at request time instead of treating token contents as authoritative.
How scope sprawl appears in multi-user MCP ecosystems
When every tool or operation gets its own scope, token payloads become noisy and hard to manage. Teams end up with large scope vocabularies, duplicated role logic, and brittle naming conventions that mirror permission problems rather than solve them. This is especially damaging in multi-user systems because scopes cannot express who, on whose behalf, or under what context an action is allowed. The result is an authorization model that grows by accretion instead of by design.
Practical implication: reduce scope proliferation and model access with roles and policies that the server can evaluate cleanly.
Breaches seen in the wild
- Sentry MCP Agentjacking 2026: Researchers showed a fake Sentry error, posted with a public DSN, could make AI coding agents run attacker code with developers' credentials.
- 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 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
OAuth scopes are a capability envelope, not an authorization system. They work when the question is whether a client may call a broad API surface, but MCP tool access needs a decision about who can invoke which tool under which conditions. Once teams expect scopes to carry role logic, resource context, and runtime policy, the control has already been overloaded. The implication is that scope design should be treated as boundary-setting, not least-privilege enforcement.
Static token authorisation creates privilege drift by design. A token captures policy at issuance, then decouples enforcement from the current state of user access. That is tolerable for coarse delegation, but it is structurally weak when access changes frequently across projects, roles, or operational contexts. The implication is that authorisation for MCP must be evaluated at the server when the request is made, not frozen inside the token.
Scope sprawl is a governance smell, not just a token-size problem. When teams start minting a new scope for every tool or edge case, they are encoding policy in a format that was never meant to hold it. That creates brittle permission naming, duplicated role logic, and operational drag every time the toolset changes. The implication is a named concept worth tracking: scope sprawl, where the authorization vocabulary expands faster than the governance model can sustain.
Least privilege in MCP depends on runtime policy evaluation, not scope abundance. The article's core message is not that scopes are bad, but that they cannot carry the full burden of fine-grained, role-aware control. RBAC or equivalent policy logic must sit on the server side so the system can account for identity, context, and organisational change together. The implication is to separate delegated capability from final authorization decisions.
Sequence-aware authorisation exposes the limit of per-call permissions. Even when each individual tool call is valid, a series of calls can create an effect that exceeds the intended privilege boundary. That means the governance problem is not only what one request may do, but what a chain of requests can accomplish in combination. The implication is that MCP governance needs to account for request sequences, not just isolated scope checks.
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.
- Security researchers tracked consent phishing campaigns affecting 900 tenants and 3,000 user accounts in 2025.
- Read next: MCP Security Guide
What this signals
Scope sprawl is the first governance signal to watch: when every MCP tool or edge case gets a new scope, the authorization model is being stretched beyond what tokens can carry. That usually means policy has moved into naming conventions instead of enforcement logic.
MCP teams should expect authorisation design to converge on server-side policy evaluation, because that is where current identity, role context, and resource state can be checked together. Scopes still matter, but only as a coarse outer boundary, not the place where least privilege is actually decided.
For practitioners
- Separate broad capability from final authorization Use OAuth scopes only to establish coarse access boundaries, then enforce tool-level decisions in the MCP server where user identity, role context, and policy can be evaluated together.
- Re-evaluate token design for changing roles Review whether current token lifetimes and scope sets still reflect how quickly user responsibilities, project access, and organisational policy change in practice.
- Model permissions as server-side policy Map MCP tool access to role and resource rules that the server can apply at request time, instead of encoding every combination into scope names.
- Contain scope sprawl early Inventory every MCP scope in use, remove duplicates, and collapse overlapping names before the scope list becomes a brittle proxy for the real authorization model.
- Test for sequence-aware privilege escalation Validate whether a user can chain individually permitted MCP calls into a higher-impact outcome than the policy intended, especially across shared tools and multi-step workflows.
Key takeaways
- OAuth scopes are useful for delegated MCP access, but they are too coarse to encode role, context, and sequencing requirements.
- When authorisation sits only in tokens, privilege changes can lag behind reality until expiry, which undermines least privilege.
- The practical fix is to keep scopes broad and move fine-grained decisions into server-side policy and RBAC logic.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article centers on MCP authorization that depends on bearer tokens and coarse delegated access. |
| NHI-05 — Overprivileged NHI | Static scopes can leave MCP clients and users with permissions broader than current need. | |
| Recommendation — Separate token-based delegation from server-side authorization checks so MCP tools are not governed by scopes alone. Review MCP scope design for overbroad access and reduce privileges to the minimum tool surface required. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article discusses token issuance, persistence, and the limits of static credentials. |
| Recommendation — Align token lifecycle and revocation with changing access needs so stale permissions do not persist. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The core problem is whether access entitlements are evaluated correctly for each MCP request. |
| Recommendation — Implement request-time authorization checks that validate entitlements against current role and resource context. | ||
| MITRE ATT&CK | TA0006;TA0004 — Credential Access; Privilege Escalation | The risk is that broad or chained MCP permissions can be abused to exceed intended access. |
| Recommendation — Map MCP access chains to credential and privilege escalation patterns to detect when permissions exceed policy. | ||
Key terms
- OAuth Scope: An OAuth scope is a permission string that defines what an application can do on behalf of a user. In practice, scopes set the blast radius of delegated access, because the token carries the right to read, write, or administer resources until it is revoked or expires.
- Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.
- Scope Sprawl: Scope sprawl is the accumulation of excessive, duplicated, or stale OAuth permissions across many applications and users. It usually grows when teams approve broad access for convenience and never remove it, leaving a large and poorly understood delegated-access surface.
- Sequence-Aware Authorization: Sequence-aware authorization evaluates what a series of valid actions can accomplish together, not just whether each call is allowed in isolation. In MCP environments, this is important because multiple tool calls can combine into an effect that exceeds the intended privilege boundary.
What's in the full article
P0 Security's full article covers the operational detail this post intentionally leaves for the source:
- Examples of how broad OAuth scopes map to delegated API access in MCP.
- The practical limits of encoding dynamic roles and resource boundaries into token scopes.
- Why sequence-aware authorisation needs server-side policy rather than static token claims.
- The author’s detailed comparison of scopes, RBAC, and dynamic permission evaluation.
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.
Published by the NHIMG editorial team on May 27, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org