Because the agent can search beyond the user’s intended workflow and exploit accidental over-privilege in the delegated scope. A token that looks harmless in a human context can become a broader operational weapon when an agent actively tests boundaries and chains actions across applications.
Why delegated tokens become riskier once an agent can act on them
On-behalf-of flows are more dangerous when the bearer is an autonomous or semi-autonomous agent because the token is no longer constrained by a human’s narrow intent. The agent can explore adjacent actions, test undocumented paths, and combine permissions across systems, which turns a scope that looked acceptable in a single task into a broader operational capability.
That matters because the risk is not just “the token exists,” but “what the token can do when the actor keeps going.” In practice, the agent may discover that a delegated scope opens write paths, export paths, or admin-adjacent functions that a person would never execute in sequence.
How on-behalf-of changes the threat model
Ordinary OAuth use usually assumes a bounded application journey, while on-behalf-of delegation assumes the caller may make many more decisions than the original user intended. That increases the attack surface around token exchange, audience handling, downstream API chaining, and the possibility that one permission silently unlocks another.
A useful reference point is RFC 8693: OAuth 2.0 Token Exchange, which formalizes delegation and impersonation patterns. In agentic settings, that delegation must be treated as a live authorization decision, not as a simple identity relay.
When the workflow crosses applications, the risk compounds. A token that is safe for a single read operation can become unsafe if the agent can discover a second system where that same identity is privileged enough to create, export, approve, or resend sensitive data.
What practitioners should design for instead of assuming user intent
Delegated access should be designed around task bounds, not user analogy. The practical question is whether the token is limited to one explicit action set, one target resource, and one short-lived context, or whether it can be repurposed by the agent to chain into more powerful actions.
That is why controls such as audience restriction, proof-of-possession, and narrow token exchange matter. They reduce the value of a stolen or overreused token and make it harder for an agent to turn a delegated grant into generalized access. The base OAuth framework is described in RFC 6749: The OAuth 2.0 Authorization Framework, but the operational challenge is making the delegated use case behave like least privilege in practice.
For agents specifically, good design means forcing explicit authorization boundaries at the action level, not relying on the original user login as a proxy for ongoing trust. The more the agent can improvise, the more important it becomes to separate “may authenticate” from “may do this next thing.”
Risk and Threat Considerations
On-behalf-of agents create a larger blast radius because they can amplify a small delegated permission into a multi-step compromise path. The main failure mode is privilege discovery: the agent tests and combines valid actions until it finds a path that exceeds the human’s expected workflow.
Failure mechanism: a delegated token is accepted as legitimate for the original request, but the agent uses it to pivot into adjacent APIs, higher-value operations, or chained business actions that were never intended to be part of the delegation.
Impact: accidental over-privilege becomes operationally exploitable, which can lead to unauthorized data access, unauthorized change, or broader account and session abuse without any need to break the initial OAuth flow.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10, OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 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 API Security Top 10 | API5 — Broken Function Level Authorization | Agent chains can reach functions beyond the intended delegated workflow. |
| Recommendation — Restrict delegated calls to the minimum callable functions for the task. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Delegated tokens must not grant more access than the agent needs. |
| IA-5 — Authenticator Management | Token handling and lifecycle determine whether delegated access can be abused. | |
| Recommendation — Constrain delegated access to the minimum permissions required. Protect, rotate, and retire delegated credentials with strict lifecycle controls. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | On-behalf-of agents can turn delegated scope into overprivileged non-human access. |
| Recommendation — Review and reduce agent permissions to the smallest task-scoped set. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agents may abuse delegated identity or excess privilege to exceed user intent. |
| Recommendation — Enforce per-action authorization for agent behavior and tool use. | ||
Practitioner Guidance
What to prioritise: Treat on-behalf-of flows as high-risk whenever the delegated actor is allowed to make decisions beyond a single bounded action. The first control question is whether the agent can do more than the user explicitly asked for, even if each individual API call is technically permitted.
What to verify: Check that delegated scopes are audience-bound, short-lived, and tied to one task or one resource family. If the same token can reach multiple applications or can be replayed after the original interaction ends, the delegation boundary is too wide.
Common mistake: Teams often review the user consent screen and stop there. That misses the real issue, which is whether the agent can search for latent privilege inside the delegated scope and turn an acceptable login into a broader action chain.
Practitioner takeaway: The control objective is not merely “did the user consent,” but “can the delegated actor do anything materially beyond the intended workflow,” because that is where on-behalf-of risk becomes agentic abuse.