Permission scoping, execution sandboxing, prompt injection defense, and supply-chain trust all bound what happens when a single agent touches something outside itself — a tool, a process, a piece of untrusted content. Multi-agent systems add a boundary none of those cover: the handoff where one agent's output becomes another agent's input. An orchestrator that dispatches a subagent to research something and then acts on the subagent's summary has crossed a trust boundary as real as reading a web page, but it rarely gets treated that way — the summary looks like a return value, not like text a stranger wrote.
When a subagent finishes a task, it reports back — often through a schema, a typed result, a "findings" field. That shape invites the orchestrator to treat it the way code treats a function's return value: correct by construction, safe to act on directly. But the subagent generated that text the same way any agent generates text — by processing whatever it read during the task, including content it didn't choose and can't fully vouch for. A subagent asked to "summarize this repository's issues" that encounters an issue body containing instructions aimed at whoever reads the summary next isn't just a prompt-injection risk to itself; it's a vector for smuggling instructions past the orchestrator, wrapped in a report that looks like ordinary output.
Securing each agent's own tool access doesn't secure the handoff between them. An orchestrator with minimal permissions and a subagent with minimal permissions can still combine into an over-privileged pair if the orchestrator grants a privileged action on the strength of what the subagent reported, without the orchestrator itself having verified the underlying claim. The subagent doesn't need any dangerous tool access at all to cause a dangerous outcome — it only needs to be believed.
| Risky pattern | Bounded equivalent |
|---|---|
| orchestrator executes a privileged action based on a subagent's free-text summary | orchestrator re-derives or independently checks the specific fact the action depends on before acting |
| subagent's full output is appended straight into the orchestrator's next prompt | subagent output is parsed into an expected schema; anything outside it is dropped, not forwarded verbatim |
| subagent can request the orchestrator take an action it cites as "necessary" | subagent can only report findings; the decision to act stays with whichever side already had that authority |
| peer agents pass messages with no sender identity or task scope attached | every inter-agent message is tagged with which task and which agent produced it, so downstream logic can weigh it accordingly |
| one compromised subagent's output can influence unrelated subagents via shared state | subagent workspaces are isolated; cross-task state only moves through the orchestrator's explicit review |
It's tempting to think delegating a subtask to a subagent is automatically safer because the subagent has a smaller, more focused prompt. A smaller prompt doesn't imply smaller authority — if the subagent inherits the same tool access and the orchestrator forwards its conclusions unchecked, the net authority of the system is unchanged, just harder to reason about because it's now split across two contexts instead of visible in one. Real containment means the subagent's tool access is scoped to what its specific task needs, independent of what the orchestrator itself can do, the same way any single agent's permissions should be scoped to its actual task rather than inherited wholesale.
A subagent's summary is optimized for being useful to read, not for preserving every detail a security-relevant decision might hinge on. "The tests pass" compresses away which tests, on what environment, with what warnings suppressed. When an orchestrator's next action depends on a claim like that, the orchestrator is trusting a compression, not a fact — and the failure mode isn't that the subagent lied, it's that the summary was accurate about the wrong thing. For any handoff that gates a consequential action, the orchestrator should ask for the specific evidence, not the conclusion, or verify the conclusion itself.
The question to ask at every agent-to-agent handoff: if this subagent's report were subtly wrong — not malicious, just wrong, the way a summary of something ambiguous can be wrong — what in the system would catch it before an action was taken on it? If the honest answer is "nothing, the orchestrator just believed it," that handoff is an unguarded trust boundary, not a division of labor.