What is AI agent delegation (on-behalf-of)?
By Identra · Updated
AI agent delegation is the granting of a user's or system's authority to an AI agent so it can act on their behalf, often across further hops to sub-agents, tools, and APIs. Each hop should carry proof of who delegated what, to whom, for how long, and for what purpose.
Key numbers
- Machine identities outnumber human identities 82 to 1 in organizations (CyberArk Identity Security Landscape, 2025)
- 68% of organizations lack identity security controls for AI (CyberArk Identity Security Landscape, 2025)
- 79% of senior executives say AI agents are already being adopted in their companies (PwC AI Agent Survey, 2025)
How does delegation work in an agent stack?
Delegation starts when a person or service grants an AI agent permission to act for them. The user authenticates, the agent receives a credential, and from that point the agent's requests carry the user's authority. In OAuth terms this is the on-behalf-of pattern: a downstream service exchanges the token it received for a new token that lets it call the next service while still representing the original user.
Agent systems stretch this pattern hard. A single request can pass from user to orchestrator agent, from orchestrator to specialist sub-agents, and from each sub-agent to tools, MCP servers, and external APIs. Every hop is a fresh delegation decision, whether or not anyone designed it as one. Most stacks today skip the formal exchange and simply reuse whatever credential is in scope, which is where the trouble begins.
What is authority fan-out?
One grant multiplies. An agent wired into email, files, a CRM, and a deployment pipeline holds the union of every permission behind those connections, and any sub-agent or tool it invokes can inherit that union by default. A user who delegates a narrow task such as booking travel may implicitly delegate calendar reads, payment methods, and contact lists, because the agent's standing credentials cover all of them.
This is why delegation is a security topic and not just a plumbing topic. The blast radius of a prompt injection, a poisoned tool description, or a compromised agent equals the widest credential anywhere in the chain, not the narrow task the user had in mind. Fan-out turns one consent screen into dozens of effective grants.
Why do context and audience get lost across hops?
Bearer tokens carry scopes, but they rarely carry purpose. By the third hop, a downstream API sees a valid credential and nothing about the original intent, the original user, or the task that justified the call. Downstream systems end up authorizing the credential rather than the delegation.
Two classic failures follow. Audience loss: a token minted for one API gets replayed against another that happens to accept it, so authority leaks sideways. The confused deputy: an agent uses its own powerful identity to serve a low-privilege user's request, so the user borrows permissions they were never granted. Both failures share a root cause, which is that the chain of who asked whom to do what is not represented anywhere the enforcement point can see it.
Delegation patterns compared
Not all on-behalf-of implementations are equal. The pattern you choose determines whether an auditor can reconstruct what happened and whether an enforcement point can make a per-hop decision.
| Pattern | How authority flows | What the audit trail shows |
|---|---|---|
| Shared service account | Every user's requests ride one machine identity | Actions blur together; no attribution |
| Impersonation | Agent becomes the user; downstream sees only the user | User gets blamed for agent actions |
| On-behalf-of with token exchange | Each hop can mint a new token naming both the user and the acting agent, where the authorization server supports actor claims | Each hop is attributable to a specific actor and delegator when actor claims are issued |
What does auditable delegation require?
Auditable delegation means that for any action taken by an agent, you can answer four questions after the fact: who originally authorized it, which chain of agents and tools carried it, what authority each hop actually held, and whether that authority matched the task. In practice that requires:
- A distinct identity for every agent and sub-agent, so each actor in the chain is a first-class principal rather than a shadow behind someone else's credential
- Token exchange at every hop, in the style of RFC 8693, with actor claims that preserve the full delegation chain instead of overwriting it
- Audience-bound, short-lived, least-scope credentials minted for the specific downstream call rather than standing keys that cover everything
- Purpose binding, so the grant records why authority was delegated and an enforcement point can reject calls outside that purpose
- Runtime recording and revocation, so the chain can be reconstructed after an incident and cut mid-flight when a hop misbehaves
How Identra thinks about it
Delegation fails at runtime, not at design time. Architecture diagrams show clean on-behalf-of flows, but the live system is where a sub-agent reuses a stale token, a tool call crosses an audience boundary, or a chain quietly grows a hop nobody reviewed. Securing human, non-human, and AI-agent identity therefore means observing delegation chains as they execute: verifying at each hop that the actor, the delegator, the scope, and the purpose still line up, and breaking the chain the moment they do not.
Go deeper: The Non-Human Majority
Frequently asked questions
What does on-behalf-of mean in OAuth?
On-behalf-of is a token exchange pattern where a service that received a user's token trades it for a new token to call the next service downstream, while still representing the original user. Instead of forwarding the same credential everywhere, each hop can mint a token naming both the user and the acting service, preserving who delegated what across the chain when the authorization server supports actor claims.
Why is delegation risky in multi-agent AI systems?
Each hop from orchestrator to sub-agent to tool is a fresh delegation decision, but most stacks reuse whatever credential is in scope instead of narrowing it. Authority fans out: one consent screen becomes dozens of effective grants, and a prompt injection anywhere in the chain inherits the widest credential present. Downstream systems see valid tokens with no record of the original intent.
What is RFC 8693 token exchange?
RFC 8693 defines an OAuth flow where a client presents an existing token and receives a new one with different scope, audience, or lifetime. Its optional actor token and act claim can record who is acting on whose behalf, and chained exchanges can preserve the full delegation path, though issuing act claims is left to authorization server policy. For agent stacks, it is the standard mechanism for giving each hop a credential scoped to its actual task.
How do you audit what an AI agent did on a user's behalf?
Give every agent and sub-agent its own identity, exchange tokens at each hop so actor and delegator are recorded, and log each tool call with the acting identity attached. An auditable trail answers four questions: who originally authorized the action, which chain of agents carried it, what authority each hop held, and whether that authority matched the delegated task.