---
title: "Glossary: Delegation chain"
canonical_url: "https://tokenobserve.com/glossary/delegation-chain"
published: 2026-09-02
last_updated: 2026-10-21
---

# Glossary: Delegation chain

A delegation chain is the ordered list of agent identities a request has passed through when one AI agent asks another to act for it. The rule that makes it a security control rather than a breadcrumb trail is that effective permissions are the intersection of every link and never the union: the request proceeds only if every agent in the chain would have been permitted to perform that exact action alone, so passing work along a chain can only narrow authority.

## Also called

- agent delegation chain
- agent-to-agent delegation
- A2A delegation
- delegated authority chain

## In practice

A delegation chain appears the moment one agent can ask another to do something: a planner calls a researcher, which calls the agent holding the database credential; a triage agent hands a case to a refunds agent. Each hop is a real authorisation decision, and the obvious way to take it, authorising whichever agent makes the call, is the wrong one, because the agent making the call is, by construction, the one that was given the powerful grant. Deciding on its permissions alone makes that grant available to anything that can reach it.

This is the confused deputy problem, and in a multi-agent estate it is the default topology rather than an edge case. A triage agent holds a read on the order database and nothing else; a payments agent holds the refund tool. If the payments agent authorises refunds on its own permissions, the triage agent has refunds too: it only has to ask. Nobody escalated anything, no credential leaked, and every log line shows a legitimate agent doing something it is permitted to do. Under those semantics an organisation’s effective permission set is not what its roles say; it is the transitive closure of the call graph, a set nobody has drawn and no reviewer can attest to.

The rule that fixes it is intersection. The action is evaluated independently against every link, with the calling agent’s own roles as the last link, and the first link that does not allow refuses the whole request. The consequence is counter-intuitive enough that engineers meeting it reliably report it as a bug: two agents in a chain can jointly do strictly less than either of them can do alone. An orders agent and a payments agent that delegate to each other can do neither the order lookup nor the refund. That is inconvenient by design, and the direction of the inconvenience is the argument for it: an intersection fails by refusing something that should have been allowed, which arrives as a ticket, while a union fails by allowing something that should have been refused, silently, in an audit trail where every step looks legitimate.

Intersection has a second property that is noticed far less often and matters more in deployment: it makes an unproven chain safe to accept. In almost every real system the chain arrives as a request header written by the calling agent, and nothing signs it. Under union semantics that header is an attack surface: add a privileged agent to the list and inherit its grants. Under intersection, forging the header can only add links, and every added link must also allow, so the most an attacker achieves by forging is to deny their own request. A forged chain buys strictly less than an honest one, and less than sending no chain at all. That asymmetry is why delegation semantics are deployable over a plain header today, rather than only once every agent in an estate can mint signed token exchanges carrying an actor claim.

Which points at where the property runs out, and it is not forgery. The attacker’s move is omission: an agent that declares no upstreams is authorised on its own roles, and its own roles are the ones worth having. Intersection protects delegated authority only where the chain cannot be suppressed: either every agent is trusted to declare its upstreams truthfully, or the chain is derived from a credential the receiving side verified rather than a header the caller wrote. Where a request authenticates with an exchanged, workload-verified capability, the right answer to a caller-supplied chain header is to refuse the request outright rather than record an assertion as though it were proof.

Three implementation details decide whether any of this survives contact. An unresolvable hop must fail closed: an unknown or suspended upstream contributes no permissions, and no permissions has to mean deny rather than skip this link. The chain is attacker-influenced input, so its length is bounded and its entries validated: Token Observe accepts at most 32 entries on the model gateway and truncates to eight hops on the tool gateway. And the refusal has to name which link failed and out of how many, because an unattributed denial in a five-agent workflow is undebuggable, and an engineer who cannot find the missing grant will widen the broadest one until the error stops.

## Example: Three hops, and the link that refuses

A chain runs triage → orders → payments. The triage agent may read the order database. The orders agent may read the order database. The payments agent may issue refunds. The payments agent, at the end of the chain, calls the refund tool, and on its own roles it is plainly permitted to. The request is refused anyway, at link one of three: the triage agent that started the work holds no refund grant, so the intersection does not contain the refund tool, and the refusal says which link failed and why. Reverse the request (the same chain calling the order lookup) and it is refused at link three, because the payments agent holds no read on the order database. Two agents, two grants, and jointly neither action: the chain can only ever describe less authority than the agents in it hold individually.

## Routinely confused with

Trace or span tree: A trace records what called what, assembled after the fact by the system being observed. A delegation chain is an input to an authorisation decision taken before the call. They have the same shape and opposite jobs: a trace tree cannot refuse anything, and a delegation chain is worthless as evidence because the caller wrote it.

Token exchange with an actor claim: RFC 8693 token exchange proves a delegation chain cryptographically, minting a fresh token per hop that carries the subject and the acting party. A header-borne chain merely asserts it. The two reach the same authorisation model from opposite ends of the trust spectrum, and intersection is what makes the asserted form defensible until the proven form is available everywhere.

Impersonation: Impersonation replaces the caller’s identity with the target’s, so the resulting authority is the target’s and the original actor disappears from the record. Delegation keeps both identities and intersects their authority. A system that describes itself as delegating but authorises on the downstream identity alone is impersonating, and its audit trail says so incorrectly.

Role assumption: Assuming a role swaps the caller’s permission set for the assumed role’s, which is an accumulation step: afterwards you have what the role has. Delegation composes permission sets by intersection instead, so no hop in the chain can end up with more than it started with.