Delegation chain
also called agent delegation chain · agent-to-agent delegation · A2A delegation · delegated authority chain
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 — authorise the agent that is actually making 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 simply asks. 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 honestly, 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.
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.
What delegation chain is 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.
Related terms
On-behalf-of
On-behalf-of is the assertion, carried on a request, that an AI agent is acting for a named human rather than on its own account. Used for attribution it makes the request traceable to a person; used for authorisation it should bound the agent to the intersection of what the agent may do and what that person may do, so that naming a human can only narrow the agent’s authority and never extend it.
Action-level permissions
Action-level permissions authorise a specific operation on a specific named resource — one tool on one server, or one model — rather than granting access to a system as a whole. The unit is what matters: an agent granted a system inherits every operation that system exposes, including the ones next to the operation it actually needed.
Deny by default
Deny by default is an authorisation model in which an action is refused unless some permission explicitly allows it, and in which an explicit deny overrides every allow. An agent holding no roles, a role with an empty permission list, and a resource no permission names all produce the same answer — refused — so the failure mode of a misconfiguration is a blocked request somebody notices rather than a standing grant nobody does.
Workload identity
Workload identity is an identity for a running process — a container, pod, virtual machine or function — established by attesting the environment it is running in rather than by a secret it stores, and normally exchanged at runtime for a short-lived credential. It answers what is running and where, which is a different question from which agent is calling and which person the call is for.
Where Token Observe does this
The definition above is the field's, not the product's. This is the part of the product that implements it, for a reader who wants to see one.
Agent permissions
Deny by default, explicit deny wins, and delegation intersects — so an agent cannot borrow authority it was never granted.
Off by default; only enforce refuses anything
MCP gateway
One endpoint in front of every upstream tool server, and the same evaluator deciding a tool call that decides a model call.
A tool call routed around it is not governed here
Human approvals
One human decision, bound to one exact payload, spendable once.
An approval takes effect only when the agent retries
The terms next to this one
What it means for an agent to be allowed to do something, and why the answer stops being obvious the moment one agent can ask another.
Definitions are the easy part.
The glossary is written to be useful whether or not you ever buy anything. If you have got to the point of deciding how to implement one of these in your own estate, say what your agents do and you will get a straight answer about what it would actually take.
no form · no qualification step · no sales desk · the other three ways in