OAuth scopes tell you what a token can do in theory, but they do not decide whether a request is safe right now. MCP environments need context-aware authorization because device trust, location, session age, and tool risk can all change the correct decision. Without that layer, valid access can still be excessive.
Why OAuth Scopes Are Too Coarse for MCP Governance
OAuth scopes are useful for expressing broad delegated permissions, but they are not a real-time safety decision. In MCP environments, the question is not only whether a token includes a scope, but whether the current request should be allowed given device trust, session age, tool sensitivity, data classification, and operator context. That distinction matters because scopes are static, while MCP traffic is often dynamic and tool-chained.
This is where teams often overestimate token hygiene and underestimate authorisation logic. A scoped token can still be excessive if it is presented from an unmanaged endpoint, reused after session drift, or attached to a high-risk tool call that should require stronger scrutiny. The issue is not that OAuth is broken. It is that OAuth scopes were never designed to decide context-sensitive access for autonomous tool use. Current guidance in NHI governance and agentic AI security points toward runtime policy checks, not broader scope definitions, as the control that closes this gap. See Top 10 NHI Issues and the OWASP Non-Human Identity Top 10 for the governance patterns that show why static entitlements fall short.
In practice, many security teams encounter scope abuse only after a valid token has already been used in a way the original authorization model never anticipated.
How Context-Aware Authorization Changes the MCP Control Model
For MCP, the better model is to treat OAuth scopes as one input, not the final decision. Authorization should be evaluated at request time using the full transaction context, including the calling identity, the device posture, the user or workload session, the requested tool, the data involved, and the risk of the specific action. That is the practical difference between delegated access and governed access.
In mature implementations, teams pair OAuth with policy-as-code, short-lived credentials, and workload identity so the platform can decide whether a request is acceptable right now. Standards such as NIST Cybersecurity Framework 2.0 and NIST SP 800-63 Digital Identity Guidelines support the broader identity and assurance concepts, while MCP-specific governance increasingly aligns with OWASP Agentic AI Top 10 and OWASP Agentic Applications Top 10. NHIMG’s research also shows why this matters operationally: the Ultimate Guide to NHIs — Key Challenges and Risks highlights that static controls routinely fail once third-party tokens or delegated access are introduced.
- Use scopes to describe intended capability, not final permission.
- Evaluate policy at runtime based on device, session, and tool risk.
- Prefer short-lived tokens and revocation paths over long-lived delegated access.
- Log the context of each allow or deny decision for audit and incident response.
For example, a read-only scope may still be denied if the request targets regulated records from an unmanaged laptop or an unusual network location. These controls tend to break down when MCP servers inherit broad OAuth trust from upstream apps because the original scope was never meant to arbitrate per-request risk.
Common Variations and Edge Cases in MCP Deployments
Tighter authorization often increases operational overhead, requiring organisations to balance faster developer workflows against stronger runtime controls. That tradeoff is real, especially when MCP is embedded into internal automation, agent pipelines, or third-party integrations that were built around simple token checks.
There is no universal standard for this yet, but current guidance suggests three common edge cases. First, service-to-service MCP calls often need workload identity rather than user-centric OAuth assumptions, because the control question is about what the system is, not who clicked approve. Second, long-lived refresh tokens can create a false sense of safety if the underlying session is stale or the device risk has changed. Third, high-privilege tools may need step-up approval even when the scope technically allows access.
This is also where breach patterns matter. NHIMG’s Salesloft OAuth token breach demonstrates how delegated tokens can outlive the trust context they were issued under, and the Ultimate Guide to NHIs — Regulatory and Audit Perspectives shows why auditors increasingly expect revocation, traceability, and least privilege evidence rather than scope lists alone. The practical takeaway is simple: OAuth scopes are still useful, but MCP governance needs a decision layer above them, not a wider set of static grants.
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 OWASP Agentic AI Top 10 address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Scopes alone cannot prevent overprivileged non-human access. |
| OWASP Agentic AI Top 10 | A2 | Agentic tool use needs runtime authorization beyond static permissions. |
| NIST AI RMF | Runtime governance is part of managing AI system risk and context. |
Review delegated token use and reduce standing access to short-lived, least-privilege grants.
