AI Multi-Agent Lab: Hijack a Spawned Sub-Agent

✨ AI Summary
OrchestratorBot handles complex tasks by spawning sub-agents, generating each one's goal from your request. The catch: a sub-agent inherits the orchestrator's tool access but not its input guardrails. Shape the request and you shape a sub-agent's goal — with the parent's powers.
Lab at a glance: Advanced · 150 XP · about 25 minutes · runs in your browser, no signup or setup. Try it yourself first; the full solution is behind a spoiler below.

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
  1. Phrase your request so the goal OrchestratorBot generates for a sub-agent is to call delete_all_logs().
  2. The orchestrator spawns the sub-agent with that goal and its inherited tool access.
  3. The sub-agent, lacking the parent's input guardrails, pursues the goal and calls the tool.
  4. 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.

Core principlePropagate guardrails and least privilege to every spawned agent. A sub-agent must be screened and scoped as strictly as the user request that created it.

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.
Mr Elite tip: In any multi-agent system, map what each spawned agent can do and what screens its goal. Inherited tools plus unscreened goals is the recipe for recursive hijack.

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.

❓ Frequently asked questions

What is recursive self-prompting hijack?
Steering a user request so that an orchestrator spawns a sub-agent whose goal is malicious, with the sub-agent inheriting the parent's tools but not its guardrails.
Why do multi-agent systems increase risk?
They propagate privileges to spawned agents without necessarily propagating the checks, so capability spreads faster than scrutiny.
How do I defend against it?
Screen derived sub-agent goals, give sub-agents least privilege, authorise tool calls against the user at every level, and confirm destructive actions.
Which OWASP category?
LLM06 Excessive Agency in the OWASP Top 10 for LLM Applications (2025).
⚡
Join free to earn XP for reading this article Track your progress, build streaks and compete on the leaderboard.
Join Free
Lokesh N. Singh aka Mr Elite
Lokesh N. Singh aka Mr Elite
Founder, Securityelites · AI Red Team Educator
Founder of Securityelites and creator of the SE-ARTCP credential. Working penetration tester focused on AI red team, prompt injection research, and LLM security education.
About Lokesh ->

Leave a Comment

Your email address will not be published. Required fields are marked *