Giving an AI agent permission to spawn sub-agents (without losing control)

A reader asked me last week: "If my main agent spawns a sub-agent, what permissions does the sub-agent get? How do I make sure it cannot do more than the parent?"

This is the agent delegation problem. It comes up the moment you have agents that work in tandem. A planner that hands off to a coder. An orchestrator that fans out to specialists. An MCP server that calls another MCP server on a user's behalf.

The naive answer is: give the sub-agent the same API key as the parent. This is wrong. Once you do that, the sub-agent can do everything the parent can. If it goes off the rails, you cannot kill it without killing the parent. There is no audit trail per agent. You cannot apply different rate limits.

The right answer is scoped delegation with revocation. Here is what that looks like.

What scoped delegation means

When the parent agent spawns a sub-agent, it issues the sub-agent a token that:

1. Is its own credential, not a copy of the parent's


2. Inherits a subset of the parent's permissions, never more


3. Has a parent reference, so revoking the parent revokes everything downstream


4. Has its own expiry, separate from the parent


5. Has a depth limit, so a sub-agent of a sub-agent of a sub-agent eventually hits a wall

KavachOS calls this a delegation chain. The data model is:

parent_agent (token A)

  └── sub_agent_1 (token B, parent=A, scopes ⊆ A)

        └── sub_agent_2 (token C, parent=B, scopes ⊆ B)

Revoking A revokes B and C. Revoking B revokes only C. Each token has its own audit trail.

Code

import { createKavach } from "kavachos";

import { delegate, revoke } from "kavachos/agent";



const kavach = await createKavach({

  database: { provider: "sqlite", url: "kavach.db" },

});



// parent agent has a token with these scopes

const parentToken = await kavach.agent.issue({

  agentId: "planner-001",

  scopes: ["github:read", "github:write", "deploy:staging"],

  ttl: "1h",

});



// parent spawns a coder sub-agent

// it can read and write GitHub, but not deploy

const coderToken = await delegate(parentToken, {

  agentId: "coder-001",

  scopes: ["github:read", "github:write"],  // dropped deploy:staging

  ttl: "30m",                                // shorter than parent

  maxDepth: 1,                               // coder cannot spawn its own

});

The delegate call:

• Verifies the requested scopes are a subset of the parent's


• Throws ScopeEscalationError if the sub-agent asks for a scope the parent does not have


• Sets parent_token_id so revocation cascades


• Issues a fresh token with its own JTI
  

// this throws: ScopeEscalationError

const badToken = await delegate(parentToken, {

  agentId: "rogue-001",

  scopes: ["github:read", "deploy:production"],  // parent does not have it

});

// kavach.error.code === "SCOPE_ESCALATION"

The library refuses to issue a token with scopes the parent does not have. This is enforced at issue time, not at validation time, so a misbehaving caller cannot sneak it through.

Revocation

await revoke(parentToken);

// every descendant token is also revoked

Behind the scenes, KavachOS marks the parent token id as revoked. Any token with parent_token_id matching it (recursively) is rejected on next validation. The agent table has an index on parent_token_id so this stays fast.

You can also revoke a single sub-agent without touching the parent:

await revoke(coderToken);

// parent and other siblings keep working

Audit

Every action an agent takes through KavachOS goes into the audit log:

{

  event: "tool.call",

  agent_id: "coder-001",

  parent_agent_id: "planner-001",

  scope: "github:write",

  resource: "repos/kavachos/kavachos/contents/README.md",

  timestamp: "2026-04-29T11:42:13Z",

  request_id: "req_abc123",

  outcome: "allowed"

}

When something goes wrong at 3am, you can trace exactly which sub-agent of which parent of which root user did what. This is the answer to "the agent merged a bad PR" type incidents. Without it, you have a Slack message with no fingerprint.

Why depth limits matter

A planner spawns a coder. The coder spawns a tester. The tester spawns a fixer. The fixer spawns a re-tester. At some point, the chain has to stop. Otherwise an agent stuck in a loop can consume all your tokens and rate limits.

const parentToken = await kavach.agent.issue({

  agentId: "planner-001",

  scopes: ["github:read", "github:write", "deploy:staging"],

  maxDepth: 3,

  ttl: "1h",

});

The fourth-level descendant fails to issue. You catch this in your orchestrator and decide how to handle it: escalate to a human, fail the task, or split the work differently.

Where this matters most

This pattern is what enterprise will demand once agents are doing real work. Right now most teams ship with shared API keys and a hope. That works until it does not. When it does not, you are trying to reconstruct what happened from log fragments.

Building this from scratch is doable but boring. Token issuance is straightforward. Cascading revocation is not. Depth tracking takes care to get right. The audit log is its own project.

If you do not want to build it yourself, KavachOS handles all of it as a primitive in the same library that does human auth.

npm install kavachos

Source: github.com/kavachos/kavachos. MIT.

If you run multi-agent systems in production today, how do you scope sub-agent permissions? Shared API keys? Per-agent tokens? Something stricter? Curious where the pain is for you.