Delegation chains in agentic systems

What a delegation chain is

When a person asks an agent to do something and the agent calls a tool which calls a service which writes to a database, four things happened and one record usually survives: the database write, attributed to whichever credential the last service held.

A delegation chain is the alternative: a set of linked assertions such that, given the final action, you can walk backwards to the human who authorised it and see what they consented to. Each link answers who is acting, on whose authority, and within what bounds.

Why this is the binding constraint on agent governance

Every governance obligation that attaches to agents resolves, eventually, into a question about authority. Regulators ask whether human oversight was exercised. Auditors ask who approved an action. Incident responders ask whether behaviour was authorised or anomalous. Internal escalation asks who is accountable.

None of those is answerable from a service principal. And unlike most control gaps, this one cannot be closed after the fact: you cannot reconstruct authority for actions already taken if the authority was never recorded. Organisations discover this during their first agent-related audit, which is the worst moment to learn it.

Anatomy of a chain

Each hop carries three facts, and they must remain separable rather than being merged into one credential:

Across multiple hops the chain must also survive propagation, which is the problem Transaction Tokens at the IETF OAuth working group addresses: preserving and cryptographically carrying the original authorization context rather than re-deriving or implicitly trusting it at each service boundary. See the standards tracker for current status.

Four ways chains break

1. Credential borrowing. The agent holds the human's own credential or session. Every downstream log shows the human, and no control can distinguish agent action from human action afterwards. This is the most common and the most destructive, because it looks like it works.
2. Authority laundering at a boundary. A service receives a request with delegation context, then calls the next service using its own standing credential. The chain terminates silently at that hop and everything beyond it is attributed to infrastructure.
3. Scope widening on exchange. A token exchange issues a downstream credential with broader permissions than the original consent, usually because the downstream service required a coarse role. The chain is intact but meaningless, since the recorded consent no longer bounds what happened.
4. Log-side truncation. The tokens carry everything correctly and the logging layer records only the caller identity, discarding the delegation claims. This is the most frustrating failure because the architecture is right and the evidence is lost at the last step.

Building one that survives an audit

1. Never let an agent hold a human credential. This is a policy decision available today with no dependency on any standard, and it is the precondition for everything else.
2. Issue the agent its own attested identity derived from its runtime rather than a stored secret.
3. Carry user authority as a separate token via OAuth token exchange, minted per invocation rather than held.
4. Narrow scope at each exchange, never widen. Make widening a policy violation your issuance layer refuses rather than a review finding.
5. Propagate rather than re-derive. A downstream service should receive the authorization context, not reconstruct it from its own assumptions.
6. Log the chain, not the caller. Every consequential action records acting identity, principal, consented scope, and the chain identifier that links hops.
7. Test reconstruction quarterly. Pick a real action from logs, name the accountable person, and time how long it took. That number is your actual evidence position, and it belongs in your 42001 management review.

Multi-agent fan-out

One human request in a multi-agent system may become hundreds of downstream calls across several agents and tools. Three properties keep that tractable:

• A stable chain identifier issued at the human interaction and carried through every descendant call, so the fan-out can be collapsed back to one authorisation.
• Monotonic scope narrowing. No descendant may hold authority exceeding its parent. Enforced at issuance, this bounds the whole tree by the original consent.
• Depth and breadth limits. An agent that can spawn agents without bound is an availability and blast-radius problem before it is a governance one.

The CSA Agentic Trust Framework's maturity model implicitly requires this: an agent cannot be promoted past its early levels if its actions cannot be traced to an authorising principal.

Frequently asked questions

What is a delegation chain in an AI agent system?

It is the linked record connecting a human's authorisation to the action software eventually performed on their behalf, across every intermediate hop. Each link records three separable facts: which identity is acting, on whose authority, and within what consented scope. Given a final action, a complete chain lets you walk backwards to the accountable person and see what they agreed to.

Why can't we reconstruct authority from our existing logs?

Because most logging records the identity that made the call, not the authority under which it was made. A database write attributed to a service principal tells you which component acted; it does not tell you which human authorised it or what they consented to. Attribution and delegation are different things, and the second cannot be derived from the first after the fact.

Can delegation chains be added to an existing agent deployment?

Yes, but it is expensive because it requires changing token issuance and logging together, across services that currently work. More importantly, it is not retroactive: actions already taken without recorded authority cannot have it reconstructed. This is why it is worth doing before the first audit rather than after, and why we treat it as a design decision rather than a control to layer on.

What breaks a delegation chain most often?

Credential borrowing, where an agent holds a human's own credential and every downstream log shows the human. After that, authority laundering, where a service receives delegation context then calls onward with its own standing credential, silently terminating the chain. Both look like working systems, which is why they persist until an audit asks a question they cannot answer.

Which standards address delegation for agents?

No ratified standard covers it end to end. OAuth 2.0 Token Exchange (RFC 8693) and on-behalf-of patterns handle per-hop delegation and are ratified. Transaction Tokens, an IETF OAuth working group draft, address propagation across service chains. The individual IETF draft on AI agent authentication composes these rather than proposing anything new. See our standards tracker for current status of each.

How do you test whether your delegation records are adequate?

Take a consequential agent action from last week's logs, and without asking anyone, name the person accountable for it and the scope they consented to. Time how long it takes. If it requires a conversation, you have attribution rather than delegation. Run this quarterly and record the result; it is exactly the evidence an ISO/IEC 42001 clause 9.1 assessor will ask for.