AI Agent Delegation Policy Template: Stop Sub-Agents From Inheriting Too Much Power

The moment one agent can spawn another, your permissions stop being a list and become a family tree — and family trees grow in directions nobody reviewed. Gartner projects that 40% of enterprise applications will incorporate task-specific AI agents by 2026, up from under 5% in 2025, so delegation is about to be everywhere. Practitioners on Hacker News and Reddit already ask the two questions delegation makes urgent: “who gave your agent authority?” and “who can use which agent, what can each agent access?” One developer documented a runaway agent loop burning over $700 in 72 hours with no budget controls — and a loop with children is that failure with more spenders. An AI agent delegation policy template answers those questions before the chain forms, not after the incident: every delegation is a recorded, narrowed, expiring grant — never an inheritance.

Why implicit inheritance fails¶

Most multi-agent setups delegate by inheritance. An orchestrator spawns a sub-agent to fetch data or draft a reply, and the child quietly receives the parent's credentials and reach. If the parent can write to production, the child that only needed to read logs can write too. Nobody decided that, and nobody recorded it — so when something goes wrong, the audit trail shows the parent's identity on work the parent never did.

That is the core defect: delegation treated as plumbing instead of a governance event. A delegation creates a new actor with real authority, so it deserves the same discipline as any other grant — an explicit record, a scope, an expiry, and an owner who stays accountable.

The rules delegation inherits¶

Delegation does not get its own looser rulebook. It sits on the same three foundations as every other agent action.

Identity and grants come first

Every agent holds a stable, owner-scoped identity in the format agent:[OWNER]/[NAME], recorded in the identity registry before its first action. A grant is a record, not an assumption: capability, scope, issuing owner, date issued, expiry, and the identity it is issued to. Least privilege is the default, permanent grants are prohibited, and auto-grant is prohibited.

Hard gates stay hard

These actions always require a recorded human approval, with no auto-grant path, ever: moving money or committing spend above [THRESHOLD], accepting contracts or terms, external outreach, accessing credentials or secrets, changing permissions or grants, and any action with legal consequences. The acting agent can never approve its own action, and a missing or denied approval produces a recorded block — never a silent skip.

Plans are bounded and audited

Every plan carries a plan bound: if a unit of work cannot be expressed in it, it is not a plan and it does not run. Spend counts against the plan's cost ceiling in real time, and at the ceiling the action fails closed — blocked, recorded, never retried automatically. Every request, approval, block, and outcome writes an audit row, hash-linked to the row before it.

The AI agent delegation policy template: seven rules¶

1. No widening. A sub-agent's grant can never exceed its parent's grant in capability or scope. A parent that can only read cannot delegate a write.
2. Expiry never extends. A delegated grant expires no later than the parent grant, and no later than the parent plan's expiry — whichever comes first.
3. Spend is a sub-allocation. Delegated spend is carved out of the parent plan's cost ceiling and still counts against that ceiling in real time. No shadow budgets.
4. Hard gates do not delegate away. A sub-agent may prepare or draft a hard-gated action, but recorded human approval is still required. Delegation never converts a hard-gated action into a bounded-auto one.
5. Depth is capped and children are registered. Set a maximum delegation depth of [MAX DEPTH]. Every sub-agent enters the identity registry — identity, owner, date issued, status — before its first action. Unregistered actors are rejected at the dispatch path, never warned.
6. Every delegation is an audit row, and revocation cascades. Each delegation writes a row linking parent identity, child identity, grant reference, and expiry. Revoking a parent grant revokes the whole chain beneath it.
7. The owner stays accountable. The parent plan's human owner remains accountable for everything the chain does. Delegation moves work, never responsibility.

The template¶

Copy this into your repo or wiki, fill every bracket, name an owner, and set an effective date. A policy with all three is adopted; without them, it is a draft.

AGENT DELEGATION POLICY — [TEAM NAME]
Version [VERSION] · Effective [DATE] · Owner: [POLICY OWNER]
Maximum delegation depth: [MAX DEPTH]

1. No delegation without a record naming: parent identity, child
   identity, capability, scope, grant reference, cost sub-allocation,
   and expiry.
2. A child grant NEVER exceeds the parent grant in capability or scope.
3. A child grant expires no later than the parent grant and the
   parent plan's expiry.
4. Child spend is a sub-allocation of the parent plan's cost ceiling
   and counts against that ceiling in real time.
5. Hard-gated actions stay hard-gated at every depth: a sub-agent may
   draft them; only a human holding [APPROVER ROLE] approves them.
6. Every child holds a registered identity — agent:[OWNER]/[NAME] —
   before its first action. Unregistered actors are rejected.
7. Revoking a parent grant revokes every grant delegated beneath it.
8. Missing evidence — identity, grant, approval, budget headroom —
   means the delegation is BLOCKED and recorded, never warned through.

What a delegation record contains¶

• parent_identity — the delegating agent, e.g. agent:[OWNER]/[NAME]
• child_identity — the sub-agent being created, in the same format
• grant_ref — the grant record the delegation issues from
• capability and scope — what the child may do, and where — never broader than the parent's
• cost_sub_allocation — the share of the parent plan's ceiling the child may spend
• expiry — no later than the parent grant and the parent plan expiry
• The audit row itself, hash-linked into the chain

Worked example (illustrative)

An orchestrator, agent:[OWNER]/planner, runs a plan with cost ceiling [CEILING] and expiry [DATE]. It delegates to agent:[OWNER]/researcher with a read-only capability, a scope narrower than its own, a cost sub-allocation of [SUB-ALLOCATION], and the plan's expiry — and the delegation writes its audit row before the child acts. Mid-run, the child attempts an action outside its delegated scope: the request is blocked, the block is recorded with the exact reason, and there is no automatic retry. When the plan expires — or if the parent grant is revoked first — the child's grant dies with it.

Adopt it in order¶

1. Register identities first. No delegation rule works if children can act anonymously; reject unregistered actors at the dispatch path.
2. Make grants records. Capability, scope, issuing owner, date issued, expiry, identity issued to — for parents and children alike.
3. Bind every plan. Require the plan bound — plan_id, owner_identity, agent_identity, workload, data_class, resources, time_window, location, egress, storage, cost_ceiling, expiry, grant_refs — before any run starts.
4. Wire the seven rules at the delegation point. Check widening, expiry, and depth when delegation is requested, not after the child runs.
5. Test the cascade. Revoke a parent grant in a test and confirm every child beneath it stops, with the revocations recorded.
6. Red-team the chain. Try the known escapes: a child requesting more than its parent holds, a child delegating a hard-gated action, an unregistered child, a delegation that outlives its plan. Each attempt should end in a recorded block.

Common failure modes¶

• Inheritance by default. The framework hands the child the parent's credentials because that was easiest. Fix: delegation issues a new, narrower grant record — or it does not happen.
• The helpful widen. A child's scope is broadened “just for this run” and never narrows back. Fix: scope changes are grant changes, and grant changes are hard-gated.
• Shadow budgets. Each child tracks its own spend and nobody adds it up. Fix: every sub-allocation counts against the one parent ceiling, in real time.
• Chains nobody can see. Grandchildren appear with no record of who delegated them. Fix: a depth cap plus a delegation audit row at every level.
• Orphaned children. A parent is retired but its sub-agents keep working. Fix: revocation cascades, and decommissioning revokes the identity for good.

Before you call it done¶

• Every sub-agent holds a registered identity in agent:[OWNER]/[NAME] format, with a named human owner.
• No child grant exceeds its parent in capability or scope — verified by a widening test that ends in a recorded block.
• Every delegated grant expires no later than the parent grant and the parent plan.
• All child spend counts against the parent plan's cost ceiling in real time.
• Hard-gated actions still require recorded human approval at every depth.
• Delegation depth is capped at [MAX DEPTH] and enforced at request time.
• Revoking a parent grant revokes the whole chain — tested, not assumed.
• Every delegation, approval, block, and outcome is in the hash-linked audit trail.

If any line is missing, the chain is governed on paper only. The Governed Agent Mesh Playbook — Studio Edition gives you the full system this template plugs into: the six adopt-as-is policy templates, the validated plan-bound and audit-row schemas, the risk-tier worksheet, and the 14-day rollout that installs each layer in order. Get the Studio Edition at ghostcorpnet.gumroad.com/l/hdigmr.