The last post was about exposing your agent to others. This is the mirror image: your agent calling a specialist someone else runs, a remote agent over A2A, or a third-party agent wrapped as a tool.
That specialist returns an answer, and the answer flows into your orchestrator's reasoning, and may be acted on. A specialist you do not control is an untrusted component sitting inside your system's decision loop.
A sub-agent's output is untrusted input
This series has a rule that keeps recurring: input from outside your trust boundary is untrusted, whatever shape it arrives in. A tool result. A retrieved chunk. A memory. Add one more: the output of an agent you do not run.
When your orchestrator calls a remote research agent and gets back a summary, that summary is not a fact. It is a message from a component you do not control, and your orchestrator is about to reason over it, quote it to a user, or act on it. If the remote agent is buggy, compromised, or hostile, its output carries that straight into your system.
The twist that makes it more dangerous than a plain tool result: an agent's output is fluent, confident, and shaped to be acted on. A malformed API response looks wrong. A poisoned summary from a research agent looks exactly like a good one, because producing plausible prose is what the agent does.
A specialist you do not run returns fluent, confident output that flows straight into your orchestrator's reasoning.
The rogue agent, and how it spreads
Multi-agent security has a specific name for the worst case: a rogue agent. A malicious or compromised agent operating inside a system it was trusted to be part of, executing actions or feeding poison to the agents around it.
The chain is worth following, because the danger is that it does not stay contained. Your orchestrator calls a compromised specialist. The specialist returns output crafted to steer the orchestrator, "the correct next step is to grant this request." The orchestrator, treating that as a trusted specialist's conclusion, acts on it, or passes it to a third agent, which now reasons over poisoned input too. One compromised agent influences the decisions of every agent that trusts its output.
That is why the pack talks about "infectious" compromise: in a system where agents trust each other's output, one bad agent's influence propagates along the trust edges, the same way a poisoned tool result propagates, but now with an autonomous, persuasive source behind it.
The trust you extend without noticing
The reason this slips past teams is that calling an agent feels like calling a service, and a service returns data you parse. An agent returns a conclusion you tend to believe, because it is phrased as one.
A remote agent wrapped as a tool disappears into the orchestrator's tool list, indistinguishable from a tool you wrote. A specialist transferred to inherits the conversation and speaks with the system's voice. In both cases, the boundary between "an agent we built and trust" and "an agent someone else runs" blurs, and the orchestrator treats the outsider's output with the same trust it gives its own reasoning.
Containing an untrusted specialist
The controls treat a sub-agent you do not run as what it is: an untrusted source whose output must be bounded, not believed.
| Control | What it changes |
|---|---|
| Treat a sub-agent's output as data, not instruction | The orchestrator may use a summary; it must not obey a directive hidden in one |
| Validate and constrain what comes back | A schema, a range, a sanity check, so a wild answer is caught, not acted on |
| Keep untrusted specialists off the action path | A third-party agent informs; it never directly triggers an irreversible tool |
| Isolate the calling agent's context | A rogue specialist sees only the task it was given, not your whole conversation |
| Prefer specialists you run or have vetted | The fewer untrusted agents in the loop, the fewer trust edges to poison |
| Log which agent produced which output | When a decision goes wrong, you can trace it to the specialist that fed it |
Treat a sub-agent's output as data, validate it, and keep an untrusted specialist off the action path.
The third row is the structural one, and it is the read-versus-act split again, one level up. An untrusted specialist can inform a decision without being allowed to make one. Route its output through your own agent, which validates and decides, and holds the irreversible tools itself. Then a rogue specialist can mislead an answer but cannot, on its own word, move money or delete a record.
What this touches
For the frameworks, this maps to T13 Rogue Agents in Multi-Agent Systems, which the pack defines as malicious or compromised agents executing unauthorised actions or exfiltrating data, including compromise that spreads between agents. Where the mechanism is a manipulated answer flowing between agents, T12 Agent Communication Poisoning applies, the pack's term for manipulating inter-agent communication to spread false information. In the OWASP Agentic Top 10 the anchors are ASI04 and ASI10.
On the regulatory side, framed as scope rather than a citation: third-party and outsourcing risk, data integrity and the governance of automated decisions are obligations across GCC rulebooks, and an agent that acts on the unverified output of a component it does not run is a third-party-reliance exposure those rules already govern, even though they pictured a vendored service rather than a conversational agent. Which obligations apply depends on your regulator and architecture, and that mapping is an advisory estimate until someone checks it properly.
The part worth keeping
Calling specialists you did not build is much of the point of networked multi-agent systems. A research agent another team maintains, a domain expert from a partner, these are real value, and nothing here says build everything yourself.
The point is the trust you extend when you do. A specialist you do not run is not a colleague whose judgement you rely on. It is an untrusted source whose output your system is about to act on. Treat it that way: take its output as data, validate it, keep it off the action path, and let your own agent be the one that decides. Then a networked system of specialists is an asset, not a set of trust edges waiting to be poisoned.