Why safe agents fail together: an execution-centered view of multi-agent security
A September 1, 2026 systematization of 197 papers argues multi-agent LLM security must be traced at execution level — and that most claimed multi-agent effects are never isolated.
What is this?
On September 1, 2026, Rui Yang, Junjie Xu, Zhengyu Liu, Neil Fendley, Yang Hong, Ziyang Li and Yinzhi Cao posted a 21-page systematization of knowledge on the security of multi-agent LLM systems to arXiv (cs.CR / cs.AI). It is not a new attack. It is an attempt to answer a question the field has been answering loosely: when a system made of individually well-behaved agents fails, is that a multi-agent security effect, or a single-agent failure that happened to occur in a multi-agent setting?
The authors’ starting position is that multi-agent systems move four things across principal boundaries — information, state, decisions, and authority — and that failures arising from those crossings are invisible to checks applied locally, inside each agent. Their corrective is methodological: analyse at the execution level, trace attacks end to end, and only then claim a system-level effect. They apply that lens to 197 works, covering six interaction interfaces, four adversary positions, seven system-level risks and eight recurring attack paths.
How it works
The organising contribution is a framework the authors call A-I-R, which classifies an attack by three coordinates rather than by its surface technique:
- A — adversary position: where the attacker sits relative to the system (four positions catalogued).
- I — interaction interface: the channel through which the attacker’s influence crosses a boundary — the six interfaces through which agents exchange messages, state, tool results and delegated authority.
- R — resulting system-level risk: what the system as a whole loses (seven categories).
The point of the coordinates is unification. Attack names in this literature proliferate faster than mechanisms; two papers can describe what looks like different attacks and be describing the same path with a different vocabulary. Fixing position, interface and outcome makes those collisions visible, and makes the eight recurring attack paths countable rather than anecdotal.
The defense side is organised symmetrically, as a five-part contract that any proposed mitigation must specify: its path target (which attack path it claims to close), its observation (what it can actually see at runtime), its intervention (what it does when it sees it), its trust boundary (what it assumes is honest), and its recovery (what happens after a breach that it failed to prevent).
Read as a checklist, this is where most published defenses come up short. The authors identify path closure and recovery as the two persistent weak points: defenses tend to detect or blunt an attack somewhere along a path without demonstrating that the path is closed, and they rarely say anything at all about restoring a system after corruption has propagated. That echoes a June 9, 2026 survey of 247 agent-security papers, which found current defenses to be useful building blocks but “weakly compositional” — and flagged multi-agent propagation as an emerging central concern.
Why it matters
For anyone running an orchestrator, a planner-worker topology, or a fleet of specialised agents sharing a task queue, the practical warning is that per-agent assurance does not aggregate. An agent that refuses harmful instructions in isolation can still relay a corrupted intermediate result, hand off inflated authority, or amplify a single poisoned input across a dozen downstream calls. Local guardrails have no view of that.
The second warning is about evidence. The authors also audit 44 evaluation and benchmark works and find recurring gaps: interaction effects are not isolated from single-agent baselines, metrics are neither comparable across papers nor diagnostic about why a defense worked, results rarely transfer across multi-agent designs, and open-system operation — agents joining and leaving, third-party participants — is largely untested. If you are buying or citing a multi-agent security claim, those four gaps are the questions to ask.
Defenses
The framework converts fairly directly into engineering practice:
- Map your interfaces before your agents. Enumerate every channel that carries information, state, decisions or authority between agents. Those crossings, not the agents, are the attack surface.
- Demand path closure, not detection. For each control you deploy, name the attack path it closes and test that path end to end. A detector that fires mid-path leaves the path open.
- Write down the trust boundary explicitly. Which agent’s output is treated as data and which as instruction? Ambiguity here is where authority quietly escalates.
- Do not let authority ride along with delegation. A sub-agent should receive the privileges its task needs, re-derived at the boundary, not inherited from its caller.
- Plan recovery. Assume propagation happens: define how corrupted shared state, memory and queued tasks are detected, quarantined and rolled back. This is the least-addressed half of the contract.
- Evaluate with counterfactuals. Run the same scenario single-agent before attributing a failure to multi-agent structure — otherwise you are hardening the wrong layer.
Status
| Item | Detail |
|---|---|
| Publication | arXiv:2609.00595, submitted September 1, 2026 (cs.CR, cs.AI), 21 pages |
| Corpus | 197 security works; 44 evaluation and benchmark works audited separately |
| Taxonomy | 6 interaction interfaces, 4 adversary positions, 7 system-level risks, 8 recurring attack paths |
| Related work | arXiv:2606.10749, June 9, 2026 — 247-paper lifecycle survey, converging on weak defense compositionality |
| Nature | Systematization and evaluation critique; no new attack, no vendor advisory, no CVE |
The figures above are the authors’ own counts over their selected corpus, and reflect the state of the published literature as of September 2026 rather than a measurement of deployed systems.