The problem
A delegation chain in an agent system looks harmless from the top. A case-worker’s assistant receives a request, decides part of the work belongs to a specialist, and calls it. The specialist decides part of its own work belongs to a narrower tool, and calls that. Nothing about this shape is unusual.
The trouble is what travels down the chain. Most frameworks hand each hop whatever the parent already had, because writing a narrower credential for every subagent is extra work and the parent’s credential is sitting right there, already authenticated and trusted. ARCH-001 names the resulting failure directly: a single-pass view of a request path misses the case where “agent A is authorized for an action, agent B is not, and B accomplishes it by asking A.” That blueprint calls it the delegation problem and states plainly that it needs identity that survives the hop, not a detector.
The identity does survive the hop, in most systems, in exactly the wrong sense. What the tool at the bottom of the chain sees is a single caller, and that caller’s authority is whichever credential happened to be in scope when the call was made, not the authority that was meant to travel with the task. A subagent asked to read one document ends up able to do anything the top of the chain could do, because nobody wrote down that it should be able to do less. The system keeps no record of what should have narrowed, so it never notices when it did not.
Forces
Task completion pressure pushes grants wider; blast radius pushes them narrower. An agent that hits a permission wall mid-task fails the task, visibly, today. An agent handed too much, and never exercising the excess, looks from the outside identical to one scoped correctly. The two failure modes are not symmetric: one shows up immediately, the other only once something goes wrong, which is exactly the condition under which a system drifts toward over-granting and nobody notices.
Delegation depth buys capability and costs auditability, because each hop is a place the original intent can be lost. Every hop that specializes work moves the chain one step further from the party who actually holds the accountable relationship, the case-worker or end user who started the task. A three-hop chain is a chain with three independent places where the original scope can be quietly restated, and only one of those restatements needs to be wrong.
Per-hop attenuation is correct and expensive; a single static grant is cheap and wrong. Deriving a narrower credential at every hop, and checking it at every call, is real engineering work: a caveat structure to design, a verification step at each tool boundary, a record of what was derived from what. A single shared credential handed down the whole chain costs nothing to build. It is wrong in a way that does not show up until it is exercised against something it should never have touched.
The pattern
The rule is simple to state and inconvenient to build: authority never widens at any hop. Whatever a subagent receives from its caller must be expressible as a restriction of what the caller held, never as an addition to it.
The mechanism is not new. Macaroons, described by Birgisson et al. in 2014, attenuate a credential by contextual caveat: a holder derives a new macaroon from one it holds by appending a caveat, a predicate the credential must satisfy at verification time, and no operation removes a caveat once added. A derived macaroon is therefore never more powerful than its parent, though it can be exactly as powerful if nothing new was added: the guarantee is that authority never widens, not that every hop must shrink it. That mechanism was built for cookies and cloud services, not agents; this pattern carries the same idea into a delegation chain between agents. That is a restatement of an established mechanism in a new context, not a discovery, and the honest thing to do is say so plainly.
Applied to an agent hop, a caveat is a restriction on scope, magnitude, expiry, or target: fewer tools, a smaller budget, a shorter window, a specific resource id rather than an open class of resources. Bounded Grant names the shape a grant needs before it is handed anywhere at all: scope, magnitude, expiry, and revocation, all four present, or the grant does not qualify as bounded. Attenuating Delegation is the discipline of handing down a grant that is bounded and no wider than its parent’s, at every hop, not just the first. In practice a real chain narrows at each hop, because each specialist needs less than the generalist that spawned it, but the rule the pattern polices is weaker and harder: never wider, whether or not a given hop adds a new restriction of its own.
Two more things make the rule hold in practice rather than only in a design document. First, the check has to happen where the call lands, not where the chain was designed on a whiteboard: Authority at the Call Site puts the control at the tool call itself, because a caveat only checked upstream is a caveat a downstream implementation detail can quietly ignore. Second, an action that cannot be undone needs more than a narrower grant behind it; it needs a gate the model cannot argue past, which is what Capability Gate and Approval Gate are for. Microsoft’s least-privilege guidance for agent tools names the same components separately: scope and magnitude bound the grant, tool binding ties a credential to the operation it is good for, and a downstream authorization check confirms the bound at the point of use rather than trusting the caller’s word.
The failure this pattern exists to name is not a broken chain. It is a chain where every individual hop looks correctly scoped in isolation, and the composition is what fails: a hop re-grants, deliberately or by default, authority an earlier hop had already stripped away. That failure does not require an attacker, only one engineer on one subagent reaching for a convenience credential because threading the attenuated one through was more work than the deadline allowed. A check that only verifies a grant is present, not its relationship to the grant one hop up, lets it straight through.
Worked example
Consider a loan-origination chain in a regulated institution. A case-worker’s session is scoped to read and write applications in one region, and to approve amounts under a set threshold. The case-worker asks an orchestrating agent to pull an applicant’s file and draft a decision.
The orchestrator delegates document retrieval to a research subagent. What it hands down is not its own session. It is a derived grant, read-only, scoped to this one applicant’s case id, expiring at the end of the current session, a strict narrowing of what the orchestrator itself holds.
The research subagent needs one external call, a credit-bureau lookup, and delegates that single call to a bureau-integration tool. The grant narrows again: one case id, one query type, no write capability at all, an expiry measured in minutes rather than the session’s remaining hours. Nothing at this hop could approve anything even if asked to; the derived grant never carried approval scope, and macaroon-style attenuation has no operation to loosen it back in.
Now put a decisioning subagent at the next hop, built by a separate team, whose job is to turn the bureau response into a recommendation. Under deadline pressure, that team wires its tool calls through a shared service account with branch-wide write access, because the account is already configured and the narrower, retrieval-only grant above was never threaded through the new code. The decisioning subagent cannot see anything it was not supposed to see; the exposure is not in retrieval. But it can now call the approve action, not because it broke anything, but because someone re-granted, at the last hop, exactly what the first hop had already taken away.
Attenuating Delegation does not fix this with a code review. It fixes it by refusing to accept a service-account credential as valid input at that call site at all: the approve action honors only a credential that traces, hop by hop, back through the derived chain to the case-worker’s own session, and rejects anything else, however legitimately configured elsewhere. A shared service account is not that credential, however convenient it was to reach for, so the decisioning subagent never holds a passable answer to the check. Any approval still due routes through an explicit Approval Gate back to a human, rather than through an ambient credential three hops removed from the person the authority belonged to.
When not to use it
The discipline has a real cost, and it is not owed everywhere. A single agent calling its own tools directly, inside one trust boundary, with no hop to another agent, has nothing to attenuate. Authority at the Call Site, one check at the point of use, covers that case without the caveat-derivation machinery this pattern asks for.
A short chain fully owned by one team, where every hop is source code in the same repository rather than a call across a trust boundary, does not need a caveat structure or a replayable Decision Record either, because there is no trust boundary for either to police. Building that machinery for calls that are, underneath the agent framing, ordinary function calls inside a single process adds indirection without a matching security boundary to justify it.
A scoped internal pilot, running against no production data, can defer the full discipline as a deliberate, named tradeoff. What it cannot do is carry that deferral, unexamined, into the point where the system starts touching real accounts or real money. The moment a chain crosses a team boundary, a trust boundary, or the line into production data, the case for attenuating every hop stops being optional.
Related patterns
Bounded Grant supplies the shape a narrowed grant has to have: scope, magnitude, expiry, and revocation, all four or none. Authority at the Call Site is where the narrowing actually gets enforced, at the tool call rather than upstream of it. Capability Gate and Approval Gate cover the actions no grant, however tightly scoped, should be allowed to authorize on its own: destructive and irreversible acts stay behind a gate regardless of what the calling agent’s credential says. Decision Record is what lets an auditor replay, after the fact, exactly which caveat chain authorized a given action and against which policy version. That is the only way to confirm, once a chain is long enough that nobody holds the whole thing in their head, that no hop quietly re-granted what an earlier one gave up.