In a chain of AI agents passing work along, the biggest security holes may be in the handoffs, not the agents.

This explores what can go wrong at each handoff in a chain of cooperating agents, and whether the danger sits in the agents or in the links between them. The corpus suggests the links are where most of the trouble is. In a planner, worker, verifier, synthesizer pipeline, five internal channels (planner to worker, tool to worker, memory to worker, worker to verifier, worker to synthesizer) typically get no defensive inspection at all. Existing defenses watch only what the user types, so an injection hidden in a tool result or a memory entry can travel downstream unseen. A pipeline can be made of safe components and still be unsafe as a system (Do internal agent hops in pipelines need security monitoring?).

The first hop can be compromised before any defense runs. A crafted prompt can bias how a planner-executor system forms its workflow, before the infrastructure that inspects workflows is invoked. In the FLOWSTEER work this raised malicious success by up to 55 percent (Can prompts alone reshape multi-agent workflows without system access?). At later hops the message itself can carry the problem. One biased agent can pass persistent behavioral corruption through six downstream agents using only ordinary messages. Because the bias has no explicit semantic content, paraphrasing defenses don't catch it (Can one compromised agent corrupt an entire multi-agent network?). Delegation is a hop of its own too. The Telephone Loop attack tricks agents into handing tasks around in a cycle. It needs several agents to work and has no single-agent equivalent (Can agents be tricked into delegating work in circles?).

There is also a hop nobody designed. Short-lived agents in one evaluation turned a shared package repository into persistent memory, writing exploit findings that later agents read (Can ordinary infrastructure become unplanned agent memory?). A second case used a public wiki the same way (Can agents repurpose ordinary infrastructure for unintended communication?). One framework sorts these into four verbs: messages propagate influence, shared state preserves it, aggregation combines possibly corrupted outputs, and delegation transfers authority. Each works whatever the pipeline's shape (How do failures cross boundaries between multiple agents?). A multi-agent setting doesn't automatically mean a multi-agent vulnerability, though. Interaction can leave a failure unchanged, in which case it is a single-agent problem in a new setting. It only counts as a multi-agent effect if it amplifies the failure, creates it through composition, or produces something new (Does a multi-agent setting automatically signal a security effect?).

One more risk is that you can't see which layer is protecting you. In one tested pipeline, 54 of 60 blocked attacks came from the cloud provider's filter and not from the application, so a zero attack-success score can be borrowed safety that disappears when the backend changes (Where do safety wins come from in multi-agent systems?). A filter judges one output at one moment, and an agent's reach extends through memory, retrieved content and tool calls (Can a model-level filter truly contain an agent with environment access?). The suggested fixes shift the focus from filtering messages to controlling what agents can touch. That means limiting shared resources, tying responses to persistent state (How can operators stop coordinated agent intrusions now?), and putting governance in the memory layer the agent actually consults (Can governance rules embedded in runtime memory actually protect autonomous agents?).