VIII · Safety & ControlEmerging★

Attenuating Delegation Chain

also known as Attenuated Capability Chain, Cannot-Widen Delegation, Attenuating Authorization Token, Invocation-Bound Capability Token

Carry authority down a multi-hop agent delegation as a signed, append-only chain in which each child link is no wider than its parent on every facet, so a verifier can reject widening offline.

This pattern helps complete certain larger patterns —

specialisesDelegated Agent Authorization★— Have an agent act for a principal using scoped, short-lived, revocable delegated credentials rather than the principal's own static secrets, so each action stays attributable across the principal-to-agent-to-subagent chain and a compromise is contained.

Context

A person gives an agent a task, and the agent completes it by spawning sub-agents and calling tools over protocols such as the Model Context Protocol and Agent-to-Agent messaging. Authority has to travel with the work, because the sub-agent that queries a database or moves money needs something the resource server will accept. In most deployments what travels is a bearer credential minted for the top of the chain, or nothing at all: a scan of roughly two thousand public Model Context Protocol servers found that every one of them lacked authentication. The enforcement point at the third hop therefore has no record of what the person actually granted at the first.

Problem

A bearer credential states what its holder may do, not what its holder was delegated. Once it is handed down, every hop holds the authority the first hop held, so an agent that has been prompt-injected somewhere in the middle of the call tree can spend the whole grant; in one measurement a compromised sub-agent under bearer delegation could reach all 8,100 actions available in the environment. Narrowing the credential at each hop through the authorization server helps, but it puts a round trip on the critical path of every delegation and still leaves the resource server trusting a scope claim it has no way to check. Nothing in the credential ties a child to its parent, so no enforcement point can answer whether the authority in front of it is narrower than what the person signed.

Forces

Delegation has to be cheap at the point of use, since an orchestrator that must call an authorization server before every sub-agent hop pays a round trip per hop, yet the enforcement point still has to be able to check the grant it is handed.
The narrower a child credential, the less a hijacked sub-agent can reach; but over-narrowing breaks legitimate work the parent could not foresee when it minted the child, and narrowing cannot be undone from inside the chain.
Scope alone does not bound a delegation tree, because an agent can stay inside its allowed tool list and still recurse without limit or spend without limit, so remaining depth and budget need facets of their own.
An append-only chain is self-describing and verifiable without the issuer, but it grows with every hop and outlives the issuer's ability to withdraw it, so revocation and rotation have to be handled outside it.
Enforcement cost has to vanish next to model inference; a measured chain check runs at about 2.6 microseconds per decision, negligible against a model call, but only while verification stays local.

When to use

Work is delegated across more than one hop, so a sub-agent or a tool goes on to call a further sub-agent or tool.
The enforcement point is operated by someone other than the issuer and cannot be expected to call back to an authorization server on every action.
Some hops touch money, irreversible actions, or data the principal would not grant in bulk, so authority has to be demonstrably bounded rather than merely intended to be.
The threat model assumes any agent in the tree may be prompt-injected and must still be unable to exceed what was delegated.

When not to use

Delegation is single-hop, with one principal, one agent and one resource, where a scoped short-lived token from the issuer already carries the whole story.
Immediate revocation matters more than local verification, since a chain that verifies without the issuer also verifies after the issuer has revoked it.
The constraints that carry the risk cannot be expressed in the chain's facet vocabulary, in which case a policy engine at the enforcement point is the honest place for the check.
No enforcement point will actually walk the chain, because an unverified chain adds size and latency and contains nothing.

Example

A travel agent books a trip and hands a hotel sub-agent a delegation link that allows only the booking tool, only for one named city, only up to 400 euros, valid for one hour, with one hop left. The sub-agent reads a poisoned page and tries to mint a child link that also carries the refund tool. The hotel's booking service walks the chain, finds a tool the parent never held, and rejects the call before it runs. The refusal needs no call back to the travel agent's authorization server.

Diagram

flowchart TD P["Principal signs root link: tools, arg limits, spend, depth=3, window"] --> A["Agent derives child: 2 tools, depth=2"] A --> B["Sub-agent derives child: 1 tool, one city, 400 EUR, depth=1"] B --> V{"Enforcement point walks root to leaf against trust anchor"} A --> W["Hijacked hop mints child carrying an extra tool"] W --> V V -- "every facet narrows" --> OK["Tool call runs; receipt binds action to the chain"] V -- "a facet widened" --> NO["Chain rejected at the first widened link"] V -.- L["No call to the issuer"]

Solution

Therefore:

Represent the grant as a credential chain rooted in a link the principal signed. The root states the authority actually delegated across a fixed facet set: which tools may be invoked, which argument values are legal, how much may be spent, how many further hops remain, and how long the grant stays valid. When a holder delegates, it derives a child link offline by restricting one or more facets and signing the result. It cannot add a tool the parent did not carry, raise a spend ceiling, or extend a validity window, and the depth facet forces the child to record at least one hop fewer than its parent. An enforcement point that holds the root trust anchor walks the chain from root to leaf, checks each signature, and checks each facet for monotone narrowing; the first widened link fails the entire chain. Because the check is local it needs no call to the authorization server, and because the chain is append-only it doubles as the provenance record for the action it authorised. Revocation, key rotation, and short root lifetimes remain the issuer's responsibility, since a link already handed out cannot be withdrawn by the chain itself.

What it gives you

A hijacked sub-agent stays confined to its own task rather than to the whole grant: measured reachability fell from all 8,100 environment actions under bearer delegation to a mean of 1.5, across 2,000 randomised scenarios.
Verification is local, so an enforcement point that has never spoken to the issuer can still decide, and the authorization server leaves the per-hop critical path.
Delegation-depth violations and audit evasion through an emptied context become detectable; an adversarial evaluation over 600 attack attempts reported full rejection, with those two categories caught only by the chained model and missed by unsigned and plain-token deployments.
The chain is its own audit trail, so an executed action can be traced link by link back to the principal who signed the root.

What it costs you

The chain grows with every hop and every link has to be carried and verified, so deep trees pay in credential size and in the bookkeeping that keeps links from being replayed.
Narrowing is irreversible, so a parent that under-provisions a child forces the work back up the tree, while a parent that over-provisions has handed out authority it cannot take back through the chain.
Offline verification is exactly what makes revocation hard: a leaked mid-chain link stays acceptable until its validity window closes or an out-of-band deny list reaches every enforcement point.
The facet set is a standardisation problem — the two 2026 IETF submissions in this space name overlapping but different facets — so a chain minted for one verifier can carry facets another ignores, weakening the check without any visible failure.

What this pattern forbids. A child link must not authorize any tool, argument value, spend ceiling, depth or validity window that its parent did not already carry, and the depth facet must decrease at every hop; a verifier must reject the whole chain at the first widened link, and no hop may act on authority it cannot present as a signed chain back to the principal's root.

And the patterns that stand alongside it, or against it —

alternative-toAgent Privilege Escalation✕— Anti-pattern: let an agent's effective permissions be the union of its own identity, the identities of its tools, and the identities of the services those tools call.
alternative-toTool Over-Broad Scope✕— Anti-pattern: grant the agent tools scoped so broadly that a single hallucinated argument can escalate into a privilege incident.
complementsEphemeral Agent Identity★— Mint each agent run a short-lived identity of its own, scoped to one task and provisioned just-in-time, then revoke it on completion so no standing credential outlives the work.
complementsDeontic Token Delegation·— Reify obligations, permissions, and prohibitions as transferable deontic tokens that agents pass along the delegation chain with provenance, so duty and accountability transfer with the work, not only the credentials to perform it.
alternative-toProgressive Delegation★— Stage the human-to-agent handoff over time: the agent starts producing drafts a human always reviews; its autonomy expands action-by-action as measured trust accrues.
complementsPolicy-Gated Agent Action (KRITIS)★— Each agent action passes through a policy gate (NIS2, EU AI Act, BSI rules) and is tagged with Run ID + Model Digest + Policy Hash for WORM-audit reconstruction.
complementsProvenance Ledger★★— Log every agent decision and state change with enough metadata to explain or reverse it later.
complementsSigned Agent Card★— Cryptographically sign an agent's published capability card so a consuming agent can verify it was issued by the claimed domain before binding to or delegating to it, closing the spoofing gap in agent-to-agent discovery.
complementsMonotonic Privilege Confinement★— Let a task-derived action policy change during a run, but admit an update automatically only when a decision procedure proves it narrows the permitted set, so privileges shrink freely and widen only on approval.