Federated Delegation: One Agent Acting for Another

Real work rarely fits inside one agent. An orchestrator calls a specialist; a specialist calls a service in another organization; that service reaches a database it alone can see. Each hop needs authority, and the tempting shortcut is to hand the next agent your credentials and let it act as you. That shortcut is how a single compromised step becomes a full account takeover. Federated delegation is the discipline of passing authority down a chain of agents so that each one can act on your behalf without ever being able to act as you — and so that every hop is narrower than the one before.

When one agent needs another

A capable agent is often just a coordinator. It breaks a request into parts and hands each part to something better suited: a search agent, a payments service, a partner's system in a different security domain. The moment it does, it faces a question every distributed system faces — how does the next component get the authority to do its part, on behalf of the original user, without being handed the keys to everything.

This is federation: authority has to travel across boundaries between components, teams, and organizations that do not fully trust each other. The naive answer is to forward whatever token the first agent holds. But that token was minted for the first agent and the whole account. Passing it onward gives the next hop far more power than its narrow job requires, and erases any record of who actually did what.

Impersonation is not delegation

It helps to name the two things that look alike. Impersonation means the second agent becomes the user — its actions are indistinguishable from the person's own, and no trace remains that an agent was involved. Delegation means the second agent acts for the user while remaining itself — the system can always see both the principal whose authority is being used and the actor actually using it.

The difference is not academic. Under impersonation, a compromised sub-agent can do anything the user could, and the logs will blame the user. Under delegation, the same compromise is bounded by the narrow authority that was passed, and the record names the agent that stepped out of line. For anything that crosses a trust boundary, delegation is the only safe default.

⚠️

The shortcut that backfires. Forwarding the user's own token to the next agent is impersonation in disguise — it maximizes blast radius and destroys accountability.

On-behalf-of: carrying the principal

The workhorse pattern is called on-behalf-of, or O B O — a flow in which an agent exchanges its own credential plus the user's context for a new token that is explicitly scoped to the next call and stamped with who is acting for whom. Standards express this directly: OAuth 2.0 Token Exchange — Open Authorization, the common standard for delegated access — carries an actor claim naming the delegate, so a resource can read both the principal and the chain of actors that reached it.

Concretely, when Agent A needs Agent B to do something, A does not forward the user's token. It requests a fresh, delegated token that says this action is for the user, performed by Agent B, limited to this one resource. Agent B presents that token; the resource sees the user's authority and Agent B's identity at once, and can enforce policy on both.

Agent A gets a delegated token so Agent B can act for the user across a trust boundary — without holding the user's own credential.

Down-scoping at each hop

Delegation is only safe if authority shrinks as it travels. Each exchange should attenuate the token — narrowing its scope, locking its audience to a single resource, and shortening its lifetime. A chain that preserves full authority at every hop is just impersonation with extra steps; a chain that narrows at every hop means a leak deep in the chain is worth almost nothing.

The mechanism is a token exchange at each boundary. The incoming token is presented, the actor is recorded, and a new token comes back that is strictly smaller: fewer permissions, one intended audience, a tighter clock. This is the point where least privilege becomes real in a multi-agent system — not as a policy on paper, but as a token that literally cannot do the extra thing.

Each token exchange records the actor and returns a strictly smaller token.

Who does what

It is worth walking the responsibilities, because federation fails when one party assumes another has done the checking. The user consents to their authority being used on their behalf. The orchestrating agent exchanges its token rather than forwarding the user's. The sub-agent calls with the delegated token and never sees the user's original credential. And the resource verifies both the actor and the scope before doing anything.

Each role has exactly one job it cannot delegate away. If the orchestrator forwards instead of exchanges, the boundary is already broken. If the resource checks the scope but ignores the actor, a stolen delegated token from one agent can be replayed by another. The safety comes from every lane doing its part, not from any single clever token.

Each party has one job it cannot hand off; the chain is only as safe as the weakest lane.

The delegation record

For delegation to be provable after the fact, the chain has to be written down as data, not inferred from scattered logs. At minimum the record ties a principal — the user whose authority is used — to a delegation grant, names each actor that performed a step in the chain, and binds the whole thing to a scope that says what was permitted. Read together, these let anyone reconstruct exactly whose authority reached which resource, through which agents.

This record is what turns delegation from a runtime convenience into an accountability mechanism. When something goes wrong, you do not ask did the user do this; you ask which actor, acting under whose delegation, exceeded which scope. That question has a precise answer only if the relationships were captured at the time.

A principal authorizes a delegation; each actor performs under it, bounded by scope.

Where delegation chains break

Even a well-designed chain fails in familiar ways. It breaks when a hop does not attenuate — the exchange hands back a token as broad as the one it received, so authority never narrows. It breaks when the audience is not locked, letting a token minted for one resource be replayed against another. And it breaks when depth is unbounded — an agent that can delegate to an agent that can delegate again, with no limit, is a chain no one can reason about.

The connection to agent risk is direct. Prompt injection or a poisoned tool result deep in a chain tries to make some sub-agent do more than its hop allows. Attenuation, audience-locking, and a bounded delegation depth are what make that attempt fail locally instead of cascading back up to the user's full authority. Treat any hop that does not shrink the token as a defect, not a nuance.

⚠️

Bound the depth. Cap how many times authority may be re-delegated; an unbounded chain is impossible to audit and trivial to abuse.

What builders and leaders decide

For engineers, federated delegation turns a vague call the next service into concrete choices: exchange tokens instead of forwarding them, stamp every hop with an actor, attenuate scope and lock audience at each boundary, and record the chain as first-class data. These compose with intent-bound authorization — each delegated token can itself be bound to a specific task — and with the shared identity that lets a resource recognize an actor at all.

For leaders, the payoff is containment and accountability across organizational lines. When agents from different teams and vendors cooperate, delegation ensures a failure in one is bounded by the narrow authority it was passed, and that every action names both the user and the agent responsible. That is what makes multi-agent systems that span trust boundaries governable rather than merely possible.

Exchange tokens at every boundary; never forward the user's own credential.
Stamp each hop with an actor identity, so the chain of who-acted-for-whom is always visible.
Attenuate scope, lock the audience to one resource, and shorten lifetime at each hop.
Bound delegation depth and record the chain as data you can audit.

Key takeaways

Delegation lets an agent act for the user while remaining itself; impersonation lets it become the user and erases accountability.
Use on-behalf-of token exchange so a resource sees both the principal and the acting agent.
Authority must shrink at every hop — attenuate scope, lock audience, and shorten lifetime.
Record the chain as data: principal, delegation, actors, and scope, so any action can be traced.
Bound delegation depth; an unbounded chain cannot be audited and is easy to abuse.
Attenuation and audience-locking make a compromise deep in the chain fail locally instead of cascading to full authority.

Glossary

Federation: Extending authority across boundaries between components, teams, or organizations that do not fully trust each other.
Delegation: An agent acting for a user while remaining itself, so both the principal and the actor stay visible.
Impersonation: An agent acting as the user, indistinguishable from the person, leaving no trace that an agent was involved.
On-behalf-of (OBO): A flow where an agent exchanges its credential plus user context for a token scoped to the next call and stamped with the actor.
Token exchange: Trading an incoming token for a new one, recording the actor and returning strictly narrower authority.
Actor claim: A field in a delegated token naming the agent that is acting, as distinct from the principal it acts for.
Attenuation: Deliberately reducing a token's scope, audience, and lifetime as it passes to the next hop.
Audience restriction: Binding a token to one intended resource so it cannot be replayed against another.