What Happens When AI Agents Spawn Sub-Agents

Modern AI agents don't work alone. An orchestrator agent receives a task and immediately delegates subtasks to specialized agents — a research agent, a code review agent, a deployment agent. Those agents may spawn their own sub-agents. Before you know it, a single user request has created a tree of five, ten, or twenty agents, each making autonomous decisions.

Who authorized the sub-agents? What scope do they inherit? What happens when one of them is compromised?

These questions don't have answers in most agentic frameworks today. The orchestrator spawns a sub-agent, and that sub-agent operates with the same permissions as the parent — or worse, with no permission model at all.

The Delegation Chain Problem

Consider this scenario: a CISO approves an AI agent to run security scans on the company's codebase. That agent decides it needs a dependency checker, so it spawns a sub-agent. The dependency checker needs to resolve package metadata, so it spawns a fetch agent. The fetch agent makes HTTP requests to external package registries.

The CISO approved one agent to scan code. Three agents are now making network requests to external services. No human reviewed or approved the expansion of scope.

This is the delegation chain problem. It has three dimensions:

• Scope inheritance — What permissions does a sub-agent inherit from its parent?
• Depth control — How deep can the delegation tree go before it requires human review?
• Blast radius — When a node in the tree is compromised, how do you contain the damage?

Tracking the Agent Tree

Every AI interaction in Shrike can carry delegation context — three fields that establish the agent's position in the tree:

• parent_agent_id — The direct parent that spawned this agent.
• task_chain — The full lineage: orchestrator→research→fetch.
• delegation_depth — How deep in the tree this agent sits (0 = root).

These fields are passed through every scan request — whether it's a prompt scan, a command scan, a SQL query, or an agent-to-agent message. The governance layer sees the full tree, not just individual nodes.

Scope Inheritance Model

Not every action needs independent approval. If a CISO approved an orchestrator to "scan code and report findings," the sub-agents performing those specific tasks shouldn't each need separate approval. That would make agents unusable.

The scope inheritance model works on criticality:

Low-risk actions within the parent's approved scope flow through automatically. High-risk actions always require human review, even if the parent was approved for that scope. Actions outside the parent's scope are escalated. And certain threats — prompt injection, jailbreaks, data exfiltration — are never overridable, regardless of who approved what.

Blast-Radius Containment

When a compromised agent is detected in the tree — maybe it's attempting prompt injection, or its session risk score exceeds the threshold — you need to contain the damage. But you can't just kill that one agent. Its sub-agents are still running, still making decisions based on context the compromised agent provided.

Blast-radius containment works by walking the tree. When a node is flagged, the system finds every agent that traces its lineage to that node — children, grandchildren, the entire subtree — and invalidates their sessions. Every pending action in the branch is suspended. Every approval in the branch is revoked.

This is a BFS (breadth-first search) traversal across the session cache. It's fast — sub-millisecond for trees of typical depth — because the parent-child relationships are indexed. The entire branch goes dark simultaneously. No child agent gets to execute "one more action" before the kill signal arrives.

Depth Limits

There's a practical limit to how deep a delegation tree should go. In our implementation, the hard limit is 10 levels. If an agent attempts to delegate beyond depth 10, the scan is rejected with a delegation_depth_exceeded error.

This isn't arbitrary. Deep delegation trees are a signal of either poor agent architecture or an attack attempting to create confusion through indirection. Most legitimate agentic workflows operate within 3-4 levels. Depth 10 provides headroom for complex enterprise workflows while preventing runaway recursion.

The Cross-Session Signal

The final piece is risk propagation across sessions. If a parent agent's session has a risk score above 0.3, all child agent sessions receive an elevated starting signal. This means the session correlation engine (L9) is already watching the child session more closely before it does anything suspicious on its own.

This creates a natural "trust decay" down the delegation tree. The deeper an agent sits, the less inherent trust it has, because risk accumulates from every ancestor. A third-level agent with a risky grandparent starts its session with the system already paying close attention.

Why This Matters Now

Multi-agent orchestration is moving from research papers to production. Anthropic's Claude can use tools. OpenAI's agents can call functions. Google's Gemini supports function calling. LangChain, CrewAI, and AutoGen make it trivial to build agent teams.

But none of these frameworks include delegation governance. They give you the tools to build agent trees. They don't give you the tools to govern them. That's the gap — and it's the gap where real damage happens.

If you can't see the tree, you can't govern the tree. If you can't govern the tree, every leaf is a risk.