TL;DR: OAuth still works for delegated API access, but it breaks down when MCP-based AI agents plan and act across multiple tools with context-dependent permissions, according to Britive. Static scopes cannot express action-level intent, so practitioners need runtime authorization, short-lived access, and tighter guardrails around agent behaviour.
At a glance
What this is: Britive’s analysis says OAuth is fine for delegated API access, but it does not fit MCP agents that make runtime decisions across multiple tools and resource types.
Why it matters: IAM and NHI teams need a runtime decision layer because static scopes cannot safely express what an agent may do, for how long, or across which non-API surfaces.
Context
OAuth was designed for delegated access to APIs, not for identity subjects that choose tools, sequence actions, and change permissions mid-task. In an MCP environment, the problem is not authentication alone but whether the permission model can keep pace with runtime behaviour across tools, data stores, and downstream actions.
For IAM programmes, this is a governance gap in how authorisation is expressed. Static scopes and consent grants assume relatively stable intent, while MCP agents operate with context-dependent intent that can change from one action to the next. That mismatch is why runtime authorisation becomes the practical control question.
The article frames the issue around agentic tool use rather than generic API access. That makes it directly relevant to NHI and agentic AI governance, especially where agents need bounded access to databases, file systems, or other resources outside conventional OAuth assumptions.
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. In MCP, the agent can chain tool calls, change context, and trigger downstream effects that were never visible when the scope was granted. Security teams need per-action authorization, not just valid authentication.
Q: Why do MCP agents need runtime authorisation instead of one-time consent alone?
A: Because agent decisions are context-dependent and can change from one action to the next. One-time consent cannot capture what the agent is trying to do right now, for how long, and against which resource, so the control must evaluate each request at execution time.
Q: Where do OAuth-based controls fail in agent access beyond APIs?
A: They fail whenever the agent needs governed access to databases, file systems, data lakes, or other non-API surfaces. If the policy only covers API calls, the agent can still reach sensitive resources through paths the authorisation model never explicitly governed.
Q: How do teams govern runtime access for agents without creating standing privilege?
A: Issue access as short-lived, task-scoped credentials and tie each grant to a specific policy decision. Then review token scope, lifetime, and revocation paths as part of identity governance, not as an afterthought. That keeps the agent’s authority narrow enough to limit blast radius if the session is abused.
Technical breakdown
Why OAuth scopes break down in MCP tool chains
OAuth scopes are a coarse authorisation primitive. They work when a client needs bounded access to a known API surface, but MCP agents often need to combine many tools in one task and choose actions at runtime. That makes predeclared scopes either too broad to be safe or too granular to be operationally useful. The technical issue is expressiveness: OAuth can describe permission boundaries, but it cannot encode per-action intent, per-resource context, or time-bound action sequencing across heterogeneous tools.
Practical implication: do not rely on static OAuth scopes as the final authorisation layer for MCP agents.
Runtime authorisation as a per-action decision layer
Runtime authorisation evaluates each request when the agent actually tries to act. In this model, the decision is not made once at consent time, but at the moment of access using identity, task context, data sensitivity, environment, and risk signals. That is materially different from token-based delegation because the permission can be narrowed to a single resource and a single action, then revoked immediately after use. In NHI terms, the control moves from standing permission to ephemeral permission, which is much closer to how agent behaviour actually unfolds.
Practical implication: issue access only at request time and attach expiry, scope, and revocation to each action.
Why non-API surfaces matter for agent governance
OAuth authorises APIs, but MCP agents often need access to file systems, data warehouses, data lakes, and databases that are not cleanly represented as API calls. That matters because a governance model built only around API authorisation leaves blind spots where the agent can still retrieve, modify, or exfiltrate data through non-API paths. The architectural lesson is that authorisation has to follow the resource, not the protocol label. For identity teams, this is where agentic governance intersects with broader NHI lifecycle and permission boundaries.
Practical implication: map every agent-accessible resource class, not just API endpoints, into the authorisation design.
NHI Mgmt Group analysis
OAuth alone is a delegated API control, not an agent governance model. The article correctly separates consented API access from runtime tool use, and that distinction matters because agentic systems do not behave like static clients. Once an agent can plan across tools, a token no longer represents a stable permission boundary. Practitioners should treat OAuth as a transport mechanism, not the policy decision point.
Runtime authorisation exposes the failure of predeclared intent. Static scopes assume the request pattern is known in advance, but MCP agents make context-dependent decisions as they execute. That assumption breaks when the same agent needs to read one record, write another, and retrieve a file in the same task. The result is a governance model that must decide at action time, not provisioning time.
Non-API access is where many identity models quietly fail. If authorisation only covers APIs, the programme leaves an ungoverned perimeter around databases, storage, and other resource classes agents can reach indirectly. That creates a permission gap, not just a protocol gap. NHI governance has to extend to every resource an agent can touch, or the control boundary is artificial.
Identity blast radius is now action-shaped, not token-shaped. In MCP environments, the practical unit of risk is the action the agent can take right now, not the scope embedded in a token issued earlier. That shifts the centre of gravity from issuance-time trust to execution-time control. Teams that still measure exposure only by token lifetime will miss where the real risk accumulates.
Agentic governance must align the perimeter with behaviour. A useful concept here is the runtime authorisation gap: the distance between what a token permits and what the agent is actually allowed to do at the moment of action. Closing that gap requires policy that follows task context, resource sensitivity, and time, rather than fixed permission bundles. Practitioners should design for action-level governance, not token-level comfort.
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.
- Read next: MCP Security Guide
What this signals
Governance programmes that still treat OAuth scopes as the end of the authorisation decision will struggle as MCP adoption grows. The control point has shifted from who can authenticate to what an agent can do in the moment, which is why runtime decisioning belongs inside the identity plane.
Runtime authorisation gap: when permission is granted at consent time but behaviour occurs later, the policy boundary no longer matches the action boundary. That creates a practical gap between delegated access and governed execution, especially when agents can reach non-API resources through the same workflow.
For practitioners
- Define runtime authorisation as the decision layer Treat OAuth as a transport token and place per-action policy evaluation in front of every agent request. Use identity, task context, resource sensitivity, and time to decide whether the action should proceed.
- Map non-API resources into the agent control model Inventory databases, file systems, data lakes, and other non-API surfaces that agents can reach. Apply the same authorisation logic to those resources as you would to APIs.
- Bind agent access to short-lived, task-scoped permissions Issue permissions at request time with narrow scope and automatic expiry. Revoke access immediately after the action completes so the agent does not retain standing privilege.
- Require human approval for sensitive on-behalf-of actions Set approval gates for agent actions that expose sensitive data or cross ownership boundaries. Keep the agent inside the human owner’s privilege perimeter.
- Log who, what, why, and how long for each agent action Capture action-level evidence so revocation and investigation are tied to the exact request, not just token issuance logs. Use those records to support rapid privilege tear-down when behaviour drifts.
Key takeaways
- OAuth remains useful for delegated access, but it does not model the per-action decisions that MCP agents make across tools and resource types.
- The central governance problem is not authentication alone. It is whether access can be narrowed, evaluated, and revoked at runtime before the agent completes the action.
- Identity teams should move toward action-level authorisation so that agent behaviour, resource sensitivity, and permission scope stay aligned.
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, OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Static scopes can overgrant agent access across tools and resources. |
| NHI-07 — Long-Lived Secrets | Token-based access becomes a standing permission risk when it outlives the action. | |
| Recommendation — Constrain agent permissions to the narrowest action scope and avoid blanket access grants. Replace long-lived access grants with short-lived permissions tied to each action. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article centres on agent privilege that exceeds the intended runtime boundary. |
| Recommendation — Enforce runtime policy checks so agent privilege cannot expand beyond approved scope. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about authorising access at execution time across identities and resources. |
| Recommendation — Apply PR.AA-05 to evaluate each agent action before access is granted. | ||
| MITRE ATT&CK | TA0006 — Credential Access | The article addresses how access tokens and permission grants can be abused. |
| Recommendation — Map agent access paths to TA0006 and tighten controls around credential use. | ||
Key terms
- 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.
- Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
- On-Behalf-Of Authorization: On-behalf-of authorization is a decision pattern that evaluates both the calling service and the original user whose action triggered the request. It prevents delegated workflows from exceeding user intent by enforcing policy on the combined identity context instead of trusting the service alone.
- Object Level Authorization: Object level authorization controls access to individual records or resources, not just to an endpoint. It prevents users from reaching data that is technically available through a route but should remain hidden according to policy, role, or ownership. This is a key safeguard against broken access control.
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 August 15, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org