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.
Why This Matters for Security Teams
OAuth scopes look reassuring because they are familiar, but MCP tool authorization is not a classic API-permission problem. An agent can choose tools dynamically, chain calls, and pass arguments that change the risk of each invocation. That means a scope can confirm broad capability, yet still miss whether the specific action is safe, allowed, or appropriate for the current user and record. Current guidance from the OWASP Top 10 for Agentic Applications 2026 treats this as a core agentic control gap, not a minor tuning issue.
NHIMG research on the The State of MCP Server Security 2025 found that only 18% of MCP server deployments implement any form of access scoping for tool permissions, while 53% expose credentials through hard-coded values in configuration files. That combination creates a dangerous illusion of control: a token may have a scope, but the server still lacks meaningful context about intent, data sensitivity, or tool blast radius. In practice, many security teams discover this gap only after an agent has already overreached into data or tools, rather than through intentional design.
How It Works in Practice
OAuth scopes work best when access is predictable, static, and tied to a stable resource category. MCP tool calls are different. The authorization question is often: should this agent, for this user, with these arguments, on this record, be allowed right now? A fixed scope issued at token time cannot answer that reliably, because the risk may change from one invocation to the next.
That is why many practitioners are moving toward context-aware authorization. Instead of relying on scope alone, the platform evaluates the request at runtime using identity, user context, tool name, argument content, target resource, and policy. This aligns with the direction described in OWASP Non-Human Identity Top 10 and the AI Agents: The New Attack Surface report, which shows that 80% of organisations report agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
- Use OAuth scopes only as a coarse gateway, not the final decision point.
- Apply runtime policy checks for every tool invocation, especially when arguments reference customer, financial, or production data.
- Bind the agent to workload identity, then issue short-lived credentials for the specific task rather than long-lived tokens.
- Log the full decision context so auditors can reconstruct why a tool call was approved or denied.
For implementation, current best practice is evolving toward policy-as-code, ephemeral token exchange, and per-call authorization enforced at the MCP server or an authorization proxy. These controls tend to break down when teams try to reuse human OAuth patterns in multi-tenant agent environments because the token issuer cannot anticipate the tool chain the agent will assemble next.
Common Variations and Edge Cases
Tighter per-call authorization often increases engineering and policy overhead, requiring organisations to balance precision against operational complexity. That tradeoff becomes more pronounced when agents span multiple tools, business units, or tenants.
There is no universal standard for this yet. Some environments can tolerate coarse scopes for low-risk read-only tools, but that is an exception, not a default. In higher-risk workflows, the safer pattern is intent-based authorization with explicit allow rules for tool class, target data, and user binding. This is especially important in systems exposed to agent chaining, where one low-risk call can set up a higher-risk follow-on action.
NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks is a useful reminder that identity alone does not equal authorization, and the OWASP Agentic Applications Top 10 reinforces that agent behaviour, not just token possession, must be governed. The practical edge case is legacy infrastructure: systems that only understand bearer scopes will often need a mediation layer before they can support safe MCP tool control.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A01 | Scopes fail when agents act dynamically; this control covers agent misuse and overreach. |
| CSA MAESTRO | A1 | MAESTRO addresses agent autonomy, tool use, and governance gaps in MCP-style systems. |
| NIST AI RMF | AI RMF helps manage risk from unpredictable agent behaviour and insufficient controls. | |
| OWASP Non-Human Identity Top 10 | NHI-03 | Non-human identities need short-lived, scoped credentials instead of broad bearer scopes. |
| NIST CSF 2.0 | PR.AC-4 | Access control must be evaluated at request time, not only when a token is minted. |
Operationalize AI risk reviews for agent actions, escalation paths, and auditability.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
