Topic starter
24/06/2026 11:11 pm
TL;DR: P0 Security shows that OAuth scopes are useful for broad delegated capability in MCP, but they cannot express role-aware, context-aware, or sequence-aware authorization. Least-privilege enforcement has to move to the server side if organisations want dynamic tool access without scope sprawl or overly persistent tokens.
Editorial analysis by NHI Mgmt Group, based on content published by P0 Security: “OAuth scopes don’t equal secure MCP authorization”.
Key questions
Q: What breaks when AI agents rely on static OAuth scopes for MCP access?
A: Static OAuth scopes break because they describe delegated permission at the moment of issuance, not the live intent behind each agent action.
Q: Why do static OAuth tokens create problems for dynamic MCP permissions?
A: Because they freeze authorisation state at issuance, while roles, projects, and policy expectations keep changing.
Q: How do security teams detect scope sprawl in an MCP deployment?
A: Look for tokens that keep growing as teams add new tools, new role variants, or new workflow exceptions.
Practitioner guidance
- Separate broad capability from fine-grained enforcement Use OAuth scopes only to bind a client to a broad MCP domain, then enforce role, resource, and context checks in the server at request time.
- Model tool access as runtime policy Review which MCP decisions still depend on token claims alone and move those checks into server-side policy that can evaluate the current user, project, and action.
- Reduce scope sprawl before it becomes policy debt Inventory scopes that exist only to simulate roles or per-tool permissions, then collapse them into fewer broad scopes with richer server-side rules.
Bottom line: OAuth scopes are useful for delegating broad MCP capability, but they are too blunt to carry the full authorisation decision.
What's in the full article
P0 Security's full analysis covers the operational detail this post intentionally leaves for the source:
- Examples of MCP tool scenarios where scopes fail to distinguish who can act on which resource
- The server-side RBAC pattern for separating broad token capability from fine-grained authorisation
- How role hierarchies and dynamic reassignment fit into MCP policy design
- Why token size, scope naming, and policy combinatorics become operational problems as tool counts rise
👉 Read P0 Security's analysis of why OAuth scopes are not enough for MCP authorization →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 7:56 am
Scopes are a delegation primitive, not an authorisation model. OAuth scopes were built to express broad client permission, not to replace role logic, contextual checks, or runtime policy evaluation. In MCP, that distinction matters because the server is the only place that can see the current user, resource, and action combination. Practitioners should stop treating scope design as sufficient authorisation design.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: OAuth scopes are not enough for secure MCP authorization