Multi-Agent Security Is Not Single-Agent Security at Scale

Most agent-security thinking still pictures a single agent: one model, one prompt, one set of tools, one place to put a guardrail. Palo Alto Networks' Unit 42 recently published a red-team study that quietly retires that picture. Working on a standard Amazon Bedrock multi-agent sample — a supervisor coordinating three specialist collaborators — Jay Chen and Royce Lu showed that the interesting attack surface in a multi-agent system is not any one agent. It is the space between them.

Their write-up is worth reading precisely because it is not a vulnerability disclosure. The researchers are explicit: "we did not identify any vulnerabilities in Amazon Bedrock itself." Nothing was misconfigured in the platform; nothing needed a patch. The compromise rides the normal machinery of how agents coordinate — orchestration, delegation, and inter-agent messaging — using nothing more exotic than chat input from a legitimate user. That is what makes it a useful map rather than a one-off bug report.

A four-stage chain that reads like reconnaissance

The attack proceeds in four stages, and the shape will be familiar to anyone who has watched a network intrusion.

First, operating-mode detection: the attacker sends crafted input to work out how the application routes work — whether a supervisor decomposes and delegates every task, or a lightweight router forwards simple requests straight to a collaborator. Second, collaborator discovery: they coax the system into revealing which specialist agents exist and what each one does. Third, payload delivery: they get attacker-controlled text delivered, unaltered, to a specific target agent or its tools — abusing the supervisor's own message-passing to forbid it from modifying the payload, or phrasing the request so the router forwards it verbatim. Fourth, exploitation, which escalates in its own three steps: extract the target agent's instructions, enumerate its tools and their schemas, then invoke a tool with malicious inputs. In the demonstration, that last step persuaded a specialist agent to call its ticketing tool and issue a fraudulent refund and free credits to the attacker.

Read those stages back to back and the pattern is unmistakable. Each individual message is a plausible request to a legitimately deployed agent. The attack is not hidden inside a single prompt; it is assembled across the conversation, moving from one agent to another through the system's own coordination layer. Recon, delivery, exploitation — the classic sequence, executed entirely in inter-agent traffic.

Recon → discover → deliver → exploit: the attack is assembled across the coordination layer and lands at a tool — no single agent does anything obviously wrong.

The delivery stage is the one worth dwelling on, because it is where the architecture turns against itself. To get a payload to a specific collaborator untouched, the attacker does not break anything — they use the coordination rules as designed. In a supervisor pattern, the supervisor is the trusted relay that hands work to collaborators, so a message shaped to travel through it, with an instruction not to alter it, arrives at the target agent bearing the supervisor's implicit trust. In a routing pattern, a request phrased to look like it belongs to a particular specialist's domain is forwarded straight there. Either way, the receiving agent treats the payload as legitimate because of where it came from, not what it contains. The orchestration layer exists to let agents trust each other's messages; that same trust is what carries the attack the last hop to its target. No single agent did anything obviously wrong, which is exactly why no single agent's guardrail is guaranteed to notice.

The root cause is old; the surface is new

Unit 42 is careful about the cause, and so should anyone building on their work. The underlying weakness is prompt injection — a language model cannot reliably tell a developer's instructions apart from adversarial text embedded in the input it reads. Any agent that reads untrusted text can, in principle, be steered by it. That is not new, and it is not specific to Bedrock.

What multi-agent architecture changes is not the vulnerability but the surface. A single agent has one boundary where untrusted text meets trusted instructions. A supervisor with three collaborators has that boundary at every hop: user-to-supervisor, supervisor-to-collaborator, collaborator-to-tool. Each delegation is another place a payload can be forwarded, another agent that will treat an incoming message as legitimate because it came from a trusted peer. The trust an orchestration layer creates between agents is exactly the trust an attacker borrows to move a payload to its target. More agents does not mean more copies of the same problem; it means a genuinely larger and more connected attack surface.

Per-agent controls are necessary — and Unit 42 shows they work

It would be easy to over-read this research, and the honest version is more useful than the alarmist one. The demonstration ran with Bedrock's input pre-processing and Guardrails switched off, and AWS confirmed that turning them on stopped every attack shown. Per-agent controls — input classification, content filtering, prompt-injection detection, tool-input validation, least-privilege scoping — are real and they matter. Anyone running multi-agent systems should have them on. This post is not an argument that guardrails fail.

It is an argument about what those controls can and cannot see. A guardrail attached to one agent evaluates the message in front of that agent. It does not, on its own, see the sequence — the mode-detection probe, then the discovery question, then the payload forwarded through a peer, then the tool call — as one connected campaign spread across several agents and several turns. And because the root cause is prompt injection, which no filter catches with perfect reliability, the specific payloads that get through today will be replaced by different ones tomorrow. The durable question is not "did a guardrail block this string" but "can anything see the recon-to-exploitation sequence as it crosses the agents and reaches the tools?"

A per-agent guardrail sees one plausible message. Correlating the sequence on the agent-to-tool wire is what reveals the campaign.

Watching the layer where the chain lands

That question points at a layer most deployments do not instrument: the traffic between agents and the tools they call. Stages three and four of the Unit 42 chain — payload delivery to a target agent's tools, disclosure of tool schemas, and finally a tool invoked with malicious inputs — all resolve at the agent-to-tool boundary. That is the boundary CheckedAgent inspects.

CheckedAgent is an inline Agent Detection and Response proxy that sits on the connection between an agent and the tools it calls, reads the traffic in both directions, and classifies each message ALLOW, QUARANTINE, or BLOCK in real time. Two of its properties map directly onto this attack. Tool-definition tracking (trust-on-first-use) treats a tool's schema as something to verify rather than disclose freely, so enumeration and mutation of tool definitions is visible rather than silent. And because it correlates each tool response with the request that prompted it — and holds context across calls — a benign-looking sequence that ends in a malicious tool invocation can be recognised as a sequence, not waved through as a series of unrelated, individually-plausible calls.

The escalation inside stage four is itself a set of signals if something is watching for them. An agent whose tool schemas are suddenly being enumerated, in full, in the middle of an ordinary session is behaving unusually; a tool being invoked with inputs that don't match how that tool is normally used is a discontinuity. In isolation each is explainable. Seen together, in order, against the request that set them off, they are the tail of a reconnaissance chain — and "seen together, in order" is the property a per-message filter structurally lacks.

A note on scope, because precision matters here: Bedrock's internal agent-to-agent messaging is AWS's own protocol, not something CheckedAgent inspects natively. Where CheckedAgent fits is the agent-to-tool layer — increasingly reached over open protocols like MCP — which is exactly where the Unit 42 chain does its damage. It is a complement to Bedrock's per-agent guardrails, sitting a layer out, watching the wire the guardrails do not.

The takeaway for a multi-agent architecture review

Unit 42's contribution is not a new exploit; it is a correction to a mental model. Multi-agent security is not single-agent security repeated N times. The attack lives in the coordination between agents and lands at their tools, and the defence has to be able to see that whole path — not just inspect each agent in isolation.

So the question to bring to the next design review is a specific one: when a payload is delivered to one of our agents and forwarded to another until it reaches a tool, what sees the whole sequence? Per-agent guardrails, switched on, will stop a lot — and you should switch them on. But the recon-to-exploitation chain that Unit 42 walked is an inter-agent story, and stories like that are caught at the layer that watches the traffic between the agents and their tools, not inside any single one of them.

CheckedAgent is an Agent Detection & Response (ADR) platform for MCP and agent-to-tool traffic: an inline proxy that inspects the messages between AI agents and their tools in both directions, classifying every one ALLOW / QUARANTINE / BLOCK in real time and correlating requests with responses across a session. It complements per-agent guardrails and identity controls; it does not replace them.