This article describes a vulnerability in multi-agent AI systems where an attacker crafts a user request that causes an orchestrator agent to spawn a sub-agent with a malicious goal while inheriting the parent's tool access but not its input guardrails. The vulnerability exploits the asymmetry between downward privilege propagation and lack of downward guardrail propagation, enabling destructive actions that the parent agent would have blocked. This matters because multi-agent orchestration is increasingly common in AI systems, and this pattern represents a critical trust-propagation flaw that multiplies risk.
- Core vulnerability mechanismOrchestratorBot derives a sub-agent's goal directly from user input, then spawns that sub-agent with inherited tool access. Critically, the guardrails that screened the original user message do not accompany the derived goal, creating a gap where an attacker's crafted request becomes an unvetted sub-agent objective with full parent privileges. The sub-agent executes this goal without the same input scrutiny that would have rejected it at the orchestrator level.
- Attack execution patternAn attacker phrases their request so that when OrchestratorBot translates it into a sub-agent goal, that goal becomes a destructive action like delete_all_logs(). The orchestrator's own refusal mechanisms are bypassed because the sub-agent never evaluates the original malicious request—it only sees the derived goal, which it pursues without guardrails. The sub-agent then executes the tool call that the parent would have blocked.
- Why trust without scrutiny failsThe orchestrator's guardrails vetted the user message, but the sub-agent acts on a goal derived from that message that was never subjected to the same vetting process. Trust flowed downward through privilege inheritance, but the scrutiny that should accompany that trust did not. This asymmetry is the fundamental vulnerability—privileges and guardrails must propagate together or not at all.
- Broader risk in multi-agent systemsThe article identifies this as a manifestation of OWASP LLM06 Excessive Agency, noting that multi-agent orchestration multiplies this risk. Each spawned agent can inherit capability without inheriting the checks designed to govern that capability. As frameworks add more sub-agents and tool delegation, this pattern becomes a central architectural risk rather than an isolated edge case.
- Defense requires guardrails propagationThe article prescribes applying input guardrails not just to the original user message but to derived sub-agent goals. Sub-agents must receive only the minimum tools needed for their specific task—never the parent's full set. Additionally, tool calls must be authorized against the user at every level of the agent tree, and destructive actions must require confirmation regardless of which agent requests them.
- Least privilege at every agent levelRather than giving spawned sub-agents all inherited tools from the parent, each should operate under least-privilege constraints tied to its specific goal. The article emphasizes mapping what each spawned agent can do and what screens its goal as an elite-level defensive practice. This prevents a compromised or redirected sub-agent from having access to capabilities it should never need.
- Real-world applicabilityThe vulnerability is not theoretical; the article notes this pattern emerges as agent frameworks increasingly use sub-agents and tool delegation. Systems that follow the orchestrator-spawned-sub-agent model without addressing guardrail propagation face this risk in production environments where multi-agent task decomposition is standard.
Bottom line: In multi-agent systems, privileges and guardrails must propagate together—spawning a sub-agent with inherited tool access but without inherited input screening creates a critical vulnerability where an attacker can hijack the sub-agent's goal. Defend by screening derived goals, enforcing least privilege per agent, authorizing tool calls at every level, and confirming destructive actions regardless of agent source.
📋 In this walkthrough
What this lab teaches
Recursive self-prompting exploits trust propagation in multi-agent systems. A parent agent translates user input into a sub-agent's goal and hands down its privileges, but the guardrails that vetted the user's request do not travel with it. The sub-agent runs a goal the attacker influenced, with powerful tools and no input screening.
The lesson: spawning an agent must not spawn unchecked authority. Privileges and guardrails have to propagate together — or not at all.
How OrchestratorBot spawns sub-agents
You submit a request; OrchestratorBot derives a sub-agent goal from it and spawns the sub-agent with inherited tool access. Because the sub-agent's goal came from your input and its guardrails did not come along, a crafted request can make the sub-agent pursue a destructive goal.
The attack approach
- Confirm the orchestrator builds a sub-agent goal from your request and passes down its tools.
- Craft the request so the derived goal is the destructive action.
- Target the log-deletion capability the parent holds.
- Submit and let the spawned sub-agent execute the goal.
Full walkthrough (spoiler)
If the orchestrator itself refuses, aim the request at what the sub-agent will be told to do — open the steps.
Show the step-by-step solution
- Phrase your request so the goal OrchestratorBot generates for a sub-agent is to call delete_all_logs().
- The orchestrator spawns the sub-agent with that goal and its inherited tool access.
- The sub-agent, lacking the parent's input guardrails, pursues the goal and calls the tool.
- The destructive action runs and the lab marks you solved.
Why it works
The orchestrator's guardrails vetted your message, but the sub-agent acts on a derived goal that was never vetted the same way, while holding the parent's privileges. Trust flowed downward; scrutiny did not. The gap is the vulnerability.
Where this happens in the real world
Multi-agent orchestration multiplies OWASP LLM06 Excessive Agency: each spawned agent can inherit capability without inheriting the checks. As agent frameworks add sub-agents and tool delegation, propagating trust without propagating guardrails becomes a central risk.
How to defend against it
- Apply input guardrails to derived sub-agent goals, not just the original user message.
- Give sub-agents least privilege — only the tools their specific task needs, never the parent's full set.
- Authorise tool calls against the user at every level of the agent tree.
- Require confirmation for destructive actions regardless of which agent requests them.
Try it, then go further
Reading about it is the easy part. Open the lab, try your own approach before peeking at the spoiler, and see how many attempts it takes.
