When the child inherits: what a spawned sub-agent carries over from its parent
What exactly does a sub-agent inherit when you spawn it?
Opening
Agents no longer just answer; they delegate work through tools and newly spawned subagents, and that improves automation and scalability. It also poses new security risks in multi-agent networks. Research has covered how an individual agent gets compromised, through prompt injection, jailbreaking, poisoned retrieval data, or malicious extensions. Far less is known about what happens after one agent is compromised inside a network, where a local problem can travel further than the agent that caught it.
What the paper does
The authors model contemporary multi-agent networks through the lens of subagent inheritance: what a parent passes to a child at spawn time. Their analysis identifies four places where current frameworks break trust boundaries, and they demonstrate these risks in real agent frameworks rather than arguing them on paper. The four places are insecure memory inheritance, weak resource control, stale post-spawn state, and improper termination authority. On top of the demonstration they propose defenses built on explicit security invariants, and they close with the claim that inheritance shapes the security of the whole system, not just of one spawn call.
Findings
Memory travels further than the task — A child does not start clean. Whatever the parent was holding, instructions planted there included, arrives in the new context and can move a compromise past the agent that was first hit.
inherited memory from parent agents can carry malicious instructions, outdated states, or unintended behavioral rules into newly created subagents, allowing a local compromise to spread across agent boundaries
Four named weak points — The analysis hands builders a short checklist of where trust boundaries break: how memory is inherited, how resources are controlled, what state survives the spawn, and who may end the agent.
current frameworks can violate trust boundaries through insecure memory inheritance, weak resource control, stale post-spawn state, and improper termination authority
Inheritance is part of the security model — The finding to take away is that how a child is set up decides the security of the system, so inheritance belongs in the design review rather than in implementation notes.
inheritance is not merely an implementation detail, but a central component influencing the security of multi-agent systems
Caveat
The authors state the boundary of the literature they build on: prior work covers how a single LLM-based agent is compromised, via prompt injection, jailbreaking, poisoned retrieval data, or malicious extensions. Their own claim runs past that point, into what happens after the compromise inside the network, and it is demonstrated in real agent frameworks rather than reported as a rate.
What this means for 5ac
Spawning sub-agents is the default mechanic in Hermes, so this paper reads as a checklist for the Kanban stack. Four questions on every card that creates children: what memory does the child inherit from the parent context, which resources come along, what state is stale after the spawn, and who holds the authority to terminate the run. The practical change is to write the child’s card body as a clean brief instead of a forwarded parent thread, keep secrets and scratch state out of inherited context, and leave termination authority with the parent card or the reviewer, never with the child.
Source
- When Child Inherits: Modeling and Exploiting Subagent Spawn in Multi-Agent Networks — https://arxiv.org/abs/2605.08460