Because those models were built around user sessions, not software entities that can request, combine, and act on delegated permissions. When the agent and the human are separate actors, the policy engine must understand both identities and the action being authorised, otherwise access becomes overpermissive or opaque.
Why This Matters for Security Teams
OAuth and OIDC are often treated as universal identity layers, but AI agents expose the limits of session-centric design. A human grants consent, yet the agent may chain APIs, refresh tokens, and act outside the original user intent. That creates a gap between delegated authorization and actual machine behaviour, especially when the agent can operate continuously or across multiple tools.
NHIMG research on The State of Non-Human Identity Security found that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which is exactly the kind of blind spot agents can exploit. Current guidance from the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework points toward runtime policy, stronger workload identity, and tighter control over delegated scopes.
In practice, many security teams encounter token abuse only after an agent has already combined permissions in ways the original OAuth consent screen never made visible.
How It Works in Practice
The core problem is that OAuth and OIDC were designed to answer “who is the user?” and “what has the user approved?” AI agents add a second actor that can autonomously decide which tool to call next, when to refresh credentials, and how to transform a narrow approval into a broader operational path. That means access control needs to evaluate the agent, the human, the task, and the context at request time.
In mature environments, the safer pattern is to treat the agent as a workload identity, not as a pseudo-user. That usually means short-lived tokens, task-scoped authorization, and policy checks that verify intent before each sensitive action. Where possible, teams should prefer ephemeral credentials, explicit audience restrictions, and workload attestations over long-lived refresh tokens that can be replayed or chained.
- Use separate identities for the human requester and the autonomous agent.
- Bind tokens to a specific workload, not just a login session.
- Limit scopes to the smallest action set needed for one task.
- Re-evaluate permissions at runtime using policy-as-code.
- Revoke or expire credentials automatically when the task ends.
This is why incidents such as CoPhish OAuth Token Theft via Copilot Studio and the OWASP NHI Top 10 matter: they show how delegated access becomes dangerous when the agent can be manipulated into reusing trust in unintended ways. For implementation detail, the OWASP Non-Human Identity Top 10 and NIST Cybersecurity Framework 2.0 both support least privilege, monitoring, and lifecycle control for machine identities.
These controls tend to break down when legacy SaaS apps only understand user consent and cannot express task-level, runtime authorization for autonomous agents.
Common Variations and Edge Cases
Tighter authorization often increases operational overhead, requiring organisations to balance task safety against developer friction and integration complexity. That tradeoff is real, especially when agents must move across SaaS apps, internal APIs, and human approval steps in one workflow.
There is no universal standard for this yet. Some teams use a human-in-the-loop approval on high-risk actions, while others rely on policy engines that evaluate claims, tool sensitivity, and session state on every request. Current guidance suggests that the more autonomous the agent, the less you should depend on static OAuth consent alone.
Edge cases appear when refresh tokens outlive the task, when an agent inherits a user’s broad enterprise role, or when one agent hands off to another in a multi-agent pipeline. In those environments, OIDC still helps with authentication, but it does not by itself solve delegation boundaries, constrained consent, or misuse of long-lived tokens. Resources like NIST AI Risk Management Framework and CSA MAESTRO agentic AI threat modeling framework are useful starting points, but they should be adapted to the exact autonomy level and blast radius of the agent.
In practice, the hardest failures show up when one approved action silently becomes a chain of token reuse, downstream API calls, and privilege escalation across systems that were never designed for autonomous delegation.
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, OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Agentic systems can abuse delegated OAuth scope chaining. |
| OWASP Non-Human Identity Top 10 | NHI-02 | OAuth tokens and refresh tokens are NHI credentials that need lifecycle control. |
| CSA MAESTRO | TA-3 | MAESTRO addresses threat modeling for autonomous agent authorization paths. |
| NIST AI RMF | AI RMF applies governance to autonomous decisions and misuse risk. | |
| NIST Zero Trust (SP 800-207) | 3.2 | Zero trust requires per-request verification of identity and context. |
Evaluate each agent request independently rather than trusting prior session state.
Related resources from NHI Mgmt Group
- How should security teams govern AI agents that use OAuth access?
- When is it crucial to implement least-privilege access for AI agents?
- How should security teams limit the risk from AI agents that have access to production systems?
- How should security teams govern AI agents that can access enterprise systems?
