Delegation Multiplies Authority Unless Something Stops It

TL;DR: Multi-agent systems decompose work by handing authority downward. Almost every implementation copies the parent’s permissions to the child instead of subdividing them, so a pipeline of five agents each holding a £10,000 limit is a pipeline with a £50,000 limit that nobody agreed to. The fix is attenuation enforced at issue time, and spend that debits every ancestor.

The shape of the problem

An orchestrator receives a task. It is too big for one agent, so it splits it: a specialist for the analysis, another for the lookup, a third for the action. Each child is given what it needs to do its part.

Ask what “given what it needs” means in code and the answer is usually one of two things. Either the child inherits the parent’s credential, literally the same API key, or a new authorisation is minted with the scopes the child requires, drawn from a config file that describes the child’s job.

Both are the same bug. In the first case the child holds exactly the parent’s authority. In the second it holds whatever the config says, which was written by thinking about the child in isolation and not about the sum.

Neither asks the question that matters: can the parent afford this?

Where the money actually goes

Take a claims pipeline. An orchestrator holds authority to settle a claim up to £25,000. It delegates to an adjuster, which is allowed to authorise payments up to £25,000, because that is the size of claim it handles. The adjuster delegates a payments step, also £25,000, for the same reason.

Every limit in that system is correct in isolation. Every review of it passes. And on a busy afternoon the pipeline can pay out considerably more than £25,000 against a single claim, because each hop resets the clock.

The failure is not that someone set a limit too high. It is that the limits compose additively when everyone assumed they composed as a maximum.

Attenuation has to be refused, not documented

The correct rule is easy to state. A delegated authority may be narrower than its parent on every dimension and wider on none: scope, time window, budget, conditions, enforcement mode. A child can do less. It can never do more.

Most systems that have this rule have it as a convention. There is a design document, a code review checklist, maybe a lint rule. All of which work until the afternoon somebody is shipping a fix and the parent limit is inconvenient.

The rule only holds if the thing that issues authority refuses to issue an invalid one. Not warns. Refuses. The call fails, the pipeline does not start, and the engineer finds out at development time rather than the auditor finding out at quarter end. A constraint that can be worked around under deadline pressure is not a constraint, it is a preference.

Spend has to debit the ancestors

Attenuation on its own is necessary and not sufficient. Give every child a limit of £5,000 under a £25,000 parent, and ten children still spend £50,000.

The missing property is that consumption flows upward. When a leaf spends, the debit lands on the leaf and on every grant above it to the root. Two consequences follow, and both are the point:

The root’s ceiling is the tree’s ceiling. However the work is divided, the total is bounded by what the accountable human signed for.

An exhausted ancestor refuses a child that still has room. This looks wrong the first time an engineer sees it. It is exactly right: the child’s own allowance was never the operative limit.

That second case deserves its own outcome. “You are not permitted to do this” and “you were permitted but the tree has run out” send an operator to completely different places, and collapsing them into a generic error costs you the diagnosis.

Revocation is where it gets embarrassing

Suppose something goes wrong and you revoke the orchestrator’s authority. What happens to the adjuster that is mid-task, holding a grant minted twenty minutes ago?

In most implementations: nothing. The child’s authorisation is an independent object with its own expiry. Killing the parent has no effect on it, and the pipeline keeps running on borrowed permission until the token times out.

Revocation has to reach down the tree. Then comes the part that gets skipped: the system has to be able to answer what happened in between. Between the revoke and the last child stopping there is a window. Actions may have been permitted in it. “We revoked at 14:02” is not an answer to “what did it do at 14:03”. The record has to say.

The audit question nobody rehearses

Here is the question that ends the conversation in a review, and it is not hostile. It is the obvious one:

This action was taken by an agent. Walk me up the chain to the person.

If the answer involves a service account, you do not have a chain. You have a credential that several things share, and attribution stops there. If the answer involves a config file, you have a description of intent, not a record of authority.

The answer has to be a sequence of grants, each citing its parent, terminating in a human who signed. Regulated sectors will demand this explicitly. Everyone else will be asked it by a customer’s security team, which in practice arrives sooner.

What this costs you, honestly

It costs a design conversation you have been avoiding. Someone has to decide what the root authority actually is: the number, the window, the purpose. That number has an owner, and they have to be comfortable with it.

It costs a small amount of latency, because the check happens before the action rather than in a reconciliation job.

It does not cost a framework migration. Attenuation is a property of how authority is issued, not of how your agents talk to each other. You can hold whatever orchestration library you already chose.

The bottom line

Multi-agent architectures are good engineering. Decomposition is how hard problems get solved, and the pipelines being built now are genuinely more capable than the monoliths they replace.

They just quietly multiply permission while they divide work. The division is deliberate and reviewed; the multiplication is accidental and nobody owns it. Make authority subdivide, make spend flow upward, make revocation reach down, and the same architecture becomes one you can put a number on and defend.