{
"slug": "delegation-depth-policy",
"topic_id": "TOPIC-210",
"cluster": "Machine, Agent & Signing Identity",
"tier": "Tier A",
"title": "Agent-to-agent delegation depth: where enterprise authority should stop",
"summary": "A human approves an agent. That agent spawns sub-agents, which invoke tools, which call services. By hop four the authority in play has no recognisable relationship to what the human approved.",
"lede": "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.",
"date": "2025-12-12",
"category": "Developer",
"author_id": "whit-calloway",
"tags": [
"AI agents",
"delegation",
"multi-agent systems",
"capability security",
"attenuation",
"agent governance"
],
"image_title": "Delegation Depth Policy",
"schema": "Article",
"key_takeaways": [
"Credential propagation copies authority. Capability-style delegation narrows it, and the difference is what makes depth governable.",
"The policy question is not how many hops are safe in general, but how many are permitted for a given consequence class.",
"Measure your topology first: maximum depth from a human approval to a consequential action is a number most platforms have never computed."
],
"body": [
{
"type": "h2",
"text": "I funded the wrong end of this"
},
{
"type": "diagram",
"kind": "chain",
"alt": "Authority at each hop",
"caption": "Nothing in the common patterns caps this, so depth is whatever the architecture happens to produce.",
"nodes": [
{
"label": "Human approves",
"sub": "a scope",
"note": "recognisable",
"good": true
},
{
"label": "Agent acts",
"sub": "within it",
"note": "mostly"
},
{
"label": "Sub-agent spawned",
"sub": "inherits",
"note": "loosely",
"bad": true
},
{
"label": "Tool invoked",
"sub": "with what authority?",
"note": "unbounded",
"bad": true
}
]
},
{
"type": "p",
"html": "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."
},
{
"type": "p",
"html": "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."
},
{
"type": "p",
"html": "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."
},
{
"type": "h2",
"text": "Copying versus narrowing"
},
{
"type": "p",
"html": "The distinction that matters, in plain terms."
},
{
"type": "table",
"head": [
"",
"Credential propagation",
"Capability delegation"
],
"rows": [
[
"What is passed",
"A credential, or a token",
"A grant derived from a grant"
],
[
"Authority at each hop",
"The same",
"Narrowed, or the same at most"
],
[
"Depth",
"Unlimited and uncounted",
"Explicit and enforceable"
],
[
"Provenance",
"Lost",
"Verifiable back to the origin"
],
[
"Revocation",
"Per credential, if you know where it went",
"Revoke the parent, the chain dies"
]
]
},
{
"type": "p",
"html": "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."
},
{
"type": "h2",
"text": "The measurement to run this week"
},
{
"type": "p",
"html": "One number tells you whether you have a problem: maximum depth from a human approval to a consequential action."
},
{
"type": "ol",
"items": [
"List your production agent workflows.",
"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.",
"Count the hops: agent, sub-agent, tool, service, downstream service.",
"Count the distinct systems reachable at depth three or greater."
]
},
{
"type": "p",
"html": "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."
},
{
"type": "h2",
"text": "A depth policy by consequence class"
},
{
"type": "p",
"html": "Depth limits should not be uniform. Tie them to what the action does."
},
{
"type": "table",
"head": [
"Consequence class",
"Max depth from human",
"Attenuation required"
],
"rows": [
[
"Read-only, internal data",
"3",
"Scope narrowing at each hop"
],
[
"Write to internal systems",
"2",
"Scope and volume narrowing"
],
[
"External communication on our behalf",
"1",
"Explicit action allowlist"
],
[
"Financial commitment",
"1",
"Amount ceiling plus counterparty scope"
],
[
"Production infrastructure change",
"0",
"Direct human authorisation only"
]
]
},
{
"type": "p",
"html": "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."
},
{
"type": "h2",
"text": "What attenuation looks like in practice"
},
{
"type": "p",
"html": "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."
},
{
"type": "code",
"text": "human → agent A scope: purchase, max $5,000, vendors [X,Y,Z], 24h, depth 2\n agent A → agent B scope: purchase, max $500, vendor [X], 4h, depth 1\n agent B → tool scope: purchase, max $500, vendor [X], 4h, depth 0\n tool → ✗ cannot delegate further"
},
{
"type": "p",
"html": "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."
},
{
"type": "h2",
"text": "The cost, honestly"
},
{
"type": "p",
"html": "Depth limits reduce what agent systems can do autonomously. That is the trade and there is no way around it."
},
{
"type": "p",
"html": "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."
},
{
"type": "h2",
"text": "What a depth policy needs to express"
},
{
"type": "table",
"caption": "Four parameters, and what happens without them",
"head": [
"Parameter",
"Without it"
],
"rows": [
[
"Maximum chain depth",
"Authority propagates indefinitely"
],
[
"Monotonic narrowing",
"A sub-agent can hold more than its parent"
],
[
"Constraint inheritance",
"Ceilings and expiries are not carried down"
],
[
"Verification at the point of effect",
"The chain is advisory"
]
]
},
{
"type": "p",
"html": "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."
},
{
"type": "h2",
"text": "Objections and honest limits"
},
{
"type": "p",
"html": "“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."
},
{
"type": "p",
"html": "“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."
}
],
"faq": [
{
"q": "Is depth two not arbitrary?",
"a": "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."
},
{
"q": "Do any frameworks support attenuable delegation?",
"a": "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."
},
{
"q": "How do scheduled workflows fit?",
"a": "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."
},
{
"q": "What breaks when we impose limits?",
"a": "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."
},
{
"q": "What depth is reasonable?",
"a": "Most production agent systems operate within two or three hops. A limit of three is generous and catches runaway recursion."
},
{
"q": "What is monotonic narrowing?",
"a": "The rule that a delegation can only reduce the authority it inherits. Without it the chain is a suggestion rather than a bound."
},
{
"q": "Where should depth be enforced?",
"a": "At the service performing the effect. Enforcing it in the orchestrator means the component being bounded is the one doing the bounding."
}
],
"sources": [
{
"t": "LangGraph — human-in-the-loop documentation",
"u": "https://langchain-ai.github.io/langgraph/concepts/human_in_the_loop/"
},
{
"t": "Capability-security literature on attenuation and delegation."
},
{
"t": "CISA — known exploited vulnerabilities and incident reporting",
"u": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog"
},
{
"t": "Model Context Protocol specification",
"u": "https://modelcontextprotocol.io/specification"
},
{
"t": "OWASP — Non-Human Identities Top 10",
"u": "https://owasp.org/www-project-non-human-identities-top-10/"
}
],
"related": [
{
"slug": "signed-tool-registry",
"title": "The enterprise MCP registry",
"category": "Developer"
},
{
"slug": "retender-authority-chain",
"title": "Double brokering",
"category": "Vertical"
},
{
"slug": "fleet-command-authorization",
"title": "Who told 40,000 inverters to curtail?",
"category": "Vertical"
}
],
"image": "https://cdn.twc.sh/images/igcache/Delegation%20Depth%20Policy/1500_900/blog.jpg",
"wordcount": 994,
"url": "/blog/delegation-depth-policy.html",
"reading_time": "4 min read",
"seo_title": "Agent-to-agent delegation depth in the enterprise",
"meta_description": "A human approves an agent, which spawns sub-agents, which invoke tools. By hop four the authority has no recognisable relation to the approval.",
"hub": {
"slug": "topics/machine-identity",
"title": "Machine and signing identity"
},
"answer": "Shallower than most architectures assume, and bounded explicitly. A human approves an agent, that agent spawns sub-agents, which invoke tools, which call services. By hop four the authority in play has no recognisable relationship to what the human approved, and nothing enforces a limit.",
"answer_q": "How deep should agent-to-agent delegation go?",
"glossary": [
{
"term": "Delegation depth",
"def": "How many hops separate a human's approval from the action performed under it."
},
{
"term": "Monotonic narrowing",
"def": "The rule that each delegation can only reduce, never expand, the authority it inherits."
},
{
"term": "Constraint inheritance",
"def": "Carrying value ceilings, counterparty limits and expiry down the chain rather than only identity."
}
],
"checklist": {
"title": "Setting a depth policy",
"id": "depth",
"desc": "Four steps.",
"steps": [
{
"name": "Measure your actual depth distribution.",
"text": "Most systems are shallower than the architecture diagram."
},
{
"name": "Set a maximum and enforce it at the effect.",
"text": "Not in the orchestrator."
},
{
"name": "Require monotonic narrowing.",
"text": "A child can never exceed its parent."
},
{
"name": "Carry constraints down the chain.",
"text": "Ceilings, counterparties and expiry, not just identity."
}
]
},
"cta": {
"title": "Where this fits in Manav",
"html": "Manav anchors machine and agent authority to a named human through a signed delegation with scope, depth and enforced revocation — so an action at hop four still resolves to a person.",
"href": "../docs.html",
"label": "See delegation chains"
}
}