TL;DR: OAuth for AI agents is a forced fit because the protocol assumes a human at a browser, a single resource owner, and one token tied to one resource, while agents are long-running processes that act across tools and users, according to Archestra. The practical issue is not that OAuth is broken, but that its trust model collapses when the client is not a person.
At a glance
What this is: This is an analysis of why standard OAuth assumptions fail for AI agents, especially around browser-based consent, resource ownership, and token scope drift.
Why it matters: IAM and platform teams need to treat AI agent authorization as a distinct design problem because human-centric OAuth patterns do not reliably govern server-side, multi-user, multi-tool agent behaviour.
Context
OAuth was built for a human user approving one application in a browser, not for a server-side process acting across multiple tools and users. That mismatch creates governance gaps in how AI agents authenticate, receive consent, and carry access across sessions.
The core issue is assumption failure, not protocol failure. When the client is an AI agent, identity is no longer tied neatly to one person, one browser session, or one downstream resource, so standard authorisation patterns need explicit redesign.
Key questions
Q: What breaks when AI agents use the wrong OAuth flow or token type?
A: The main failure is a confused trust model. If an autonomous agent is treated like a human user, teams may issue identity tokens where only authorization is needed, or rely on interactive login where no user exists. That creates broken automation, weak scope control, and audit gaps. APIs should only accept access tokens for enforced permissions.
Q: Why do AI agents make OAuth client registration harder to govern?
A: AI agents can multiply the number of clients, gateways, and delegated access paths that need oversight. That turns registration into a lifecycle problem, because each client must be traceable, scoped, and revocable. Without that governance, automation creates trust sprawl faster than teams can review it.
Q: What should security teams do about delegated access across sub-agents?
A: Security teams should require revalidation at each hop in the delegation chain. Every downstream agent should carry the current identity, current context, and the original intent so inherited access does not turn into a blanket pass.
Q: When should teams move from ad hoc OAuth integrations to a dedicated agent identity model?
A: They should do it once the agent is long-running, multi-user, or multi-tool, because that is where human-centred OAuth assumptions stop holding. At that point, registration, audience binding, and lifecycle governance need to be treated as one control plane rather than isolated patches.
Technical breakdown
Why browser-based consent breaks for AI agents
The authorization code flow assumes a person can see a consent screen, approve access, and complete a redirect. AI agents running in containers, queues, or CI jobs have no browser and no stable human operator at the moment a token is needed. Device flow is only a partial workaround because it reintroduces a human step. The practical problem is that the protocol’s primary trust event is human presence, while the agent’s runtime is server-side and often asynchronous. That means the consent ceremony no longer aligns with execution timing, which is why many integrations end up bolting human approval onto a machine workflow. See the AI Agent Authorisation Guide. See the AI Agent Authorisation Guide.
Practical implication: Design authorisation flows that account for non-browser execution and do not assume a live human can complete approval at token issuance time.
Why resource ownership becomes ambiguous in agentic workflows
OAuth assumes the application requesting a token is acting for the person who just authenticated. AI agents often act for a user who authenticated earlier, for multiple users in one process, or for a service identity that is not any one human. That makes the question “who is this token for?” materially harder than the classic user-to-app model. Token exchange and on-behalf-of patterns exist to preserve attribution, but they only work when the delegation chain is explicit. Without that clarity, access decisions drift from user context into process context, which is a governance problem as much as an authentication problem. See the Agentic AI Identity Guide. See the Agentic AI Identity Guide.
Practical implication: Make delegated authority explicit in the identity model so every agent token can be tied back to a named subject and purpose.
How token scope drift happens across many tools
Classic bearer tokens were often treated as broadly reusable credentials once minted. AI agents call multiple tools, so a token issued for one resource can be presented to another unless the resource server verifies audience binding. That is where scope drift appears: the token remains valid beyond the specific resource and task for which it was created. The issue is not token format alone, but whether the runtime enforces destination-specific use. In agentic systems, one token crossing too many services turns authorisation into an ambient property rather than a bounded decision. See the Zero Trust for AI Agents guide. Read Zero Trust for AI Agents.
Practical implication: Bind agent tokens to a single resource server and verify the intended audience at every hop.
Threat narrative
Attacker objective: The objective is to obtain reusable access that outlives the original human approval context and reaches beyond the intended resource boundary.
- Entry occurs when an AI agent receives a delegated token or registration path designed around human approval and a browser-based consent flow.
- Escalation follows when the same credential is reused across multiple tools or resources, allowing scope drift beyond the original authorisation boundary.
- Impact occurs when the agent can continue acting after the human context that justified the token no longer exists, creating unaudited cross-tool access.
Breaches seen in the wild
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
- Microsoft verified publisher OAuth phishing 2022: Malicious OAuth apps with a fraudulently obtained Microsoft verified publisher badge tricked UK users into granting mailbox access in 2022.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
OAuth for AI agents exposes an assumption collapse, not a simple implementation gap. The protocol was designed for a human at a browser, acting for themselves, on one resource at a time. That assumption fails when the actor is a long-running process that may outlive the user session, act for multiple principals, and invoke many tools without a human present. The implication is that agentic authorisation must be judged against runtime delegation, not browser-era consent choreography.
Audience binding is the first control that stops token scope from becoming ambient. Without an enforced audience, a token issued for one tool can be replayed against another, which turns a narrow delegation into a reusable credential. That is a governance failure in how authorisation boundaries are enforced, not just a protocol tuning issue. Practitioners should treat audience enforcement as a baseline control for any AI agent that crosses resource boundaries.
Delegation clarity matters more for AI agents than for conventional apps because the subject of authority can change mid-process. A single agent may act on behalf of one user, many users, or a service identity depending on the workflow. That makes token exchange and explicit on-behalf-of semantics essential to auditability and accountability. The practical conclusion is that identity architecture must preserve the represented principal at issuance time, not infer it later.
Dynamic registration changes the trust model by giving agents an identity without a human pre-registering every instance. That is useful, but it also means registration and lifecycle control become part of the authorisation surface, not a setup footnote. If the environment cannot govern how agents appear, rotate, and retire, then the access model remains human-shaped while the runtime is not. Practitioners should align registration, delegation, and resource binding as one control plane.
From our research library:
- 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
- Read next: AI Agent Authorisation Guide
What this signals
OAuth for AI agents: the useful shift is not to treat agents as slightly unusual apps, but as a different delegation shape altogether. Human-centric consent, principal attribution, and token reuse assumptions all weaken when the runtime is server-side and the actor may represent multiple people across one process. Teams should expect authorisation architecture to become a first-class design decision, not a default integration choice.
The practical programme implication is that identity teams need to separate user authentication from agent authorisation much more explicitly. If the represented principal, audience boundary, and lifecycle state are not all machine-readable, the organisation will keep discovering policy gaps only after the agent is already in production.
For practitioners
- Define the represented principal Require every agent workflow to state which user, service, or workload the token represents before any access is granted. See the Agentic AI Identity Guide.
- Enforce audience-bound tokens Bind each token to one resource server and reject requests presented to any other audience, even if the scope looks valid.
- Use explicit token exchange Adopt on-behalf-of exchange so downstream tools can see the actor chain instead of receiving a generic bearer token.
- Treat agent registration as lifecycle control Govern dynamic client registration, client metadata, and retirement as part of the access lifecycle rather than as setup plumbing.
Key takeaways
- OAuth’s browser-era assumptions do not map cleanly to AI agents that run server-side, act for multiple principals, and operate across tools.
- The main failure mode is scope drift, where a token issued for one resource can be reused elsewhere if audience checks are weak or absent.
- Practitioners need an explicit agent identity model that preserves delegation context, binds tokens to a single audience, and governs registration and retirement as part of lifecycle control.
Related NHI Mgmt Group resources: Agentic AI Identity Guide · AI Agent Authorisation Guide · Zero Trust for AI Agents · AI Agent Observability, Audit and Incident Response Guide
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 MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent delegation and scope drift are the core risk when OAuth assumptions fail for AI agents. |
| Recommendation — Map agent authorization paths to ASI03 and constrain delegated privilege to the minimum runtime scope. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article centers on authentication patterns that break when agents use human-shaped OAuth flows. |
| NHI-05 — Overprivileged NHI | AI agents can inherit broad tokens that exceed the task they are actually performing. | |
| Recommendation — Apply NHI-04 to replace browser-centric auth assumptions with agent-appropriate authentication flows. Use NHI-05 to keep each agent token tied to the smallest viable task and resource set. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Non-Organizational Users) | AI agents and external principals need authentication patterns beyond human interactive login. |
| Recommendation — Apply IA-9 to govern machine-to-machine authentication and delegated access for agent workflows. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | Reused agent tokens can enable credential misuse across tools and broaden access paths. |
| Recommendation — Track token replay and cross-resource abuse as TA0006 and TA0008 behaviors in detection content. | ||
Key terms
- Agent Delegation Chain: A delegation chain is the sequence of agents that pass tasks, context, or actions to one another before work is completed. In governed systems, each hop becomes a security boundary because identity, authority, and accountability can change as the task moves downstream.
- Audience Binding: A control that limits a token to a specific downstream resource or service. It prevents credential replay across tools and keeps delegated access aligned to the exact action the system was allowed to perform.
- On-behalf-of Token: An on-behalf-of token is a delegation mechanism that lets one identity call downstream services with authority derived from another identity. It is useful for tracing provenance, but it is not enough on its own because audit records still need the full human, agent, and tool chain.
- Dynamic Client Registration: Dynamic client registration is a protocol pattern that allows a software client to register itself with an authorization system automatically. For AI agents, it can reduce manual setup, but it also creates new identities at speed, which makes ownership, policy checks, and revocation essential.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity security 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 October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org