Agent-to-agent delegation depth: where enterprise authority should stop

Agent frameworks propagate credentials. Credentials carry no depth and no attenuation, so authority is copied rather than narrowed at each hop — and nothing in the stack has a vocabulary for saying how far it may travel.

Part of Machine and signing identity

I funded the wrong end of this

When we stood up our first multi-agent workflow I asked the right question and accepted the wrong answer. I asked how we would control what the agents could do. I was told about scoped API keys, per-agent service accounts and network policy, and that sounded like control.

It was access control. What I had actually asked about, without knowing the vocabulary, was authority propagation — and no part of the stack had an answer, because no part of the stack had the concept.

We found out when an agent chain three hops from a human approval made a commitment nobody had authorised. Nothing broke. Nothing alerted. It just happened, correctly, according to every permission in the system.

Copying versus narrowing

The distinction that matters, in plain terms.

Agent frameworks almost universally implement the left column, because it is what the underlying platforms provide. The right column exists in capability-security literature and in a few protocols, and it is what the situation actually requires.

The measurement to run this week

One number tells you whether you have a problem: maximum depth from a human approval to a consequential action.

1. List your production agent workflows.
2. For each, trace from the human approval — or the human who configured the schedule, if there is no per-run approval — to the furthest consequential action.
3. Count the hops: agent, sub-agent, tool, service, downstream service.
4. Count the distinct systems reachable at depth three or greater.

The second number is the one that gets attention in a leadership meeting. It is usually larger than anyone expects and nobody has computed it.

A depth policy by consequence class

Depth limits should not be uniform. Tie them to what the action does.

The bottom row is the one engineering teams push back on, and the pushback is usually about deployment automation. That is a legitimate case and it is handled by a standing delegation with explicit bounds, not by unlimited depth.

What attenuation looks like in practice

A delegation that can only narrow is the enforcement mechanism. If an agent holds authority to spend up to $5,000 with approved vendors, any sub-delegation it issues must be within that envelope — a smaller amount, a subset of vendors, a shorter window.

human → agent A     scope: purchase, max $5,000, vendors [X,Y,Z], 24h, depth 2
        agent A → agent B   scope: purchase, max $500, vendor [X], 4h, depth 1
                  agent B → tool   scope: purchase, max $500, vendor [X], 4h, depth 0
                            tool → ✗  cannot delegate further

Verification at the final hop walks the chain back to the human. If any link exceeds its parent's envelope, the chain fails — not at audit time, at execution time.

The cost, honestly

Depth limits reduce what agent systems can do autonomously. That is the trade and there is no way around it.

What makes it acceptable is that the limit binds by consequence class rather than globally. A research agent reading internal documents at depth four is fine. The same architecture moving money at depth four is not, and almost nobody wants it to.

What a depth policy needs to express

Monotonic narrowing is the property most often missing. If a sub-agent can be granted anything its parent did not hold, the chain stops being a chain and becomes a suggestion.

Objections and honest limits

“Depth limits will constrain legitimate architectures.” They will constrain unbounded ones, which is the intent. Most production agent systems operate within two or three hops; a limit of three is generous and catches runaway recursion.

“The orchestrator enforces this already.” In its own code, which is the component the depth limit is meant to bound. Enforcement belongs at the service performing the effect.

Setting a depth policy

1. Measure your actual depth distribution. Most systems are shallower than the architecture diagram.
2. Set a maximum and enforce it at the effect. Not in the orchestrator.
3. Require monotonic narrowing. A child can never exceed its parent.
4. Carry constraints down the chain. Ceilings, counterparties and expiry, not just identity.

Terms used here

Delegation depth

How many hops separate a human's approval from the action performed under it.

Monotonic narrowing

The rule that each delegation can only reduce, never expand, the authority it inherits.

Constraint inheritance

Carrying value ceilings, counterparty limits and expiry down the chain rather than only identity.

Frequently asked questions

Is depth two not arbitrary? The specific numbers are a starting policy, not a finding. What is not arbitrary is that the limit should vary by consequence and should be enforced rather than documented.

Do any frameworks support attenuable delegation? Capability-based token schemes exist and some agent protocols are moving in this direction. Most production frameworks propagate credentials, which is why this is a policy and integration problem today.

How do scheduled workflows fit? They run under a standing delegation issued by a human, with explicit bounds and an expiry. The human is the one who signed the schedule's envelope.

What breaks when we impose limits? Workflows that were reaching further than anyone realised. That is the finding, and discovering it through a limit is cheaper than discovering it through an incident.

What depth is reasonable? Most production agent systems operate within two or three hops. A limit of three is generous and catches runaway recursion.

What is monotonic narrowing? The rule that a delegation can only reduce the authority it inherits. Without it the chain is a suggestion rather than a bound.

Where should depth be enforced? At the service performing the effect. Enforcing it in the orchestrator means the component being bounded is the one doing the bounding.

Sources and further reading

• LangGraph — human-in-the-loop documentation
• Capability-security literature on attenuation and delegation.
• CISA — known exploited vulnerabilities and incident reporting
• Model Context Protocol specification
• OWASP — Non-Human Identities Top 10