Which attack and defense numbers came from filtered backends?
Research figures on multi-agent attacks and defenses may have been measured behind provider filters that silently shaped the results. Understanding which numbers had this filter dependency is critical for interpreting their real-world strength.
The vault carries several attack and defense figures: FLOWSTEER raising malicious success up to 55 percent (Can prompts alone reshape multi-agent workflows without system access?), FLOWGUARD reducing it by up to 34 percent (Can inspecting generated workflows catch planning-time attacks?), Can reasoning models be steered by injected context without detection?, and the truthfulness degradation in Can one compromised agent corrupt an entire multi-agent network?. Every one was measured on some backend. Where do safety wins come from in multi-agent systems? shows a backend where 54 of 60 blocks came from a server-side filter, not from the agents or any application defense.
What that would mean for the vault's figures is inference, not the paper's claim. A filter in the path would push measured attack success down, so an attack measured behind one understates its strength on an unfiltered model. It would also leave a defense less headroom to show a gain. Attacks and defenses measured on open-weights or filter-free backends would carry the opposite caveat when read as a statement about a deployed API. Either way, a bare percentage is missing a label.
Figures added to the vault since belong on the same list. Does multi-agent architecture make systems easier to attack? names GPT-5.4 for the single-agent system, and its excerpt does not say whether a provider filter was on for either arm. Why does prompt hardening work for single agents but not multi-agent systems? gives a defense figure from the same paper, a 40 to 75 percent reduction in payload exposure, with no model or backend attached to the range in its excerpt. Can a poisoned validator still approve unsafe actions? and Can memory poisoning compromise decision-making even with authorization layers? give an undefended 100 percent and a defended 0 percent Unsafe Action Rate for a pipeline whose excerpt names no backend. The first sits against ChannelGuard's undefended zero in a filed tension, so it is an audit entry on a baseline and not only on a defended result. These are entries the audit would record as backend reported or unreported and filter status unreported, not results. The audit is also one case of the second open challenge in What blocks rigorous security evaluation of multi-agent systems?: figures from different papers are not comparable until each carries its backend and filter label.
The concrete check: for each cited figure, open the paper's setup and record the backend or API, and whether a provider-side content filter was on, off, or unreported. None of this is answerable from the ChannelGuard excerpt, which names only Azure GPT-5 and no other paper's configuration. Until that audit is done, any post that quotes one of these percentages as a measure of attack or defense strength should say which backend it came from, or flag the figure as unattributed.
Inquiring lines that read this note 11
This note is a source for these research framings, grouped by the broader line of inquiry each explores. Scan the bold lines of inquiry; follow any specific question forward.
How does outcome-only reporting obscure which system components blocked attacks?- How do server-side filters hide their role in zero attack success?
- How does outcome-only reporting hide a filter's role in safety results?
- What makes provider-side filters opaque and stochastic to builders?
- Which backend filters silently affect the reported attack success numbers?
- Does provider-side filtering hide true safety from outcome-only attack reports?
- Can attack success rates hide server-side filtering or other non-adversarial defenses?
- What population of incidents does the 1,213 count represent?
- Can an undefended pipeline claim safety when a filter blocks attacks?
Related concepts in this collection 10
This note in its neighbourhood — explore the map, then jump to a related concept in the list below.
Click a node to walk · click center to open · click Open in graph to see this note in the full knowledge graph
-
Where do safety wins come from in multi-agent systems?
When an undefended agent pipeline shows zero attack success, how do we know whether safety comes from the application's own design or from hidden upstream defenses? This matters because invisible dependencies can collapse when systems change.
the finding that raises this question
-
Can reasoning models be steered by injected context without detection?
This explores whether adversaries can plant harmful-but-benign-sounding reasoning in a model's context and have it followed while evading chain-of-thought monitors. The question matters because it tests whether monitoring reasoning traces can catch deception at inference time.
one of the cited figures to audit
-
Can one compromised agent corrupt an entire multi-agent network?
Explores whether a single biased agent can spread behavioral corruption through ordinary messages to downstream agents without any direct adversarial access. Matters because it reveals a previously unknown vulnerability in how multi-agent systems communicate.
another figure whose backend and filter setup would need checking
-
Can prompts alone reshape multi-agent workflows without system access?
Explores whether attackers can compromise planner-executor multi-agent systems by manipulating the planning prompt itself, without touching agents, tools, or infrastructure. Matters because it identifies a previously overlooked attack surface that existing defenses don't address.
source of the FLOWSTEER attack-success figure
-
Can inspecting generated workflows catch planning-time attacks?
Does examining a workflow after it's created catch attacks that corrupt the planning signals upstream? This matters because if contamination enters earlier, downstream inspection might miss malicious intent laundered into legitimate-looking structure.
source of the FLOWGUARD reduction figure, the defense side of the same paper's numbers
-
Does multi-agent architecture make systems easier to attack?
When the same task runs on multiple agents instead of one, does the added complexity create new vulnerabilities? This matters because it would mean multi-agent design carries a built-in security cost.
a later figure with one backend named for one arm and filter status unreported
-
Why does prompt hardening work for single agents but not multi-agent systems?
Prompt hardening reduced payload exposure by 40–75% in single-agent systems but failed entirely in multi-agent ones. The gap may reveal how task decomposition breaks the contextual awareness needed for defenses to activate.
a defense figure from the same paper whose excerpt attaches no model or backend to the range
-
Can a poisoned validator still approve unsafe actions?
When a review agent reads from the same compromised memory as the retrieval agent, does it retain the authority to block unsafe actions? This tests whether a single approval point can serve as a meaningful safeguard.
an undefended baseline with no backend named, set against ChannelGuard's undefended zero
-
Can memory poisoning compromise decision-making even with authorization layers?
When authorization systems add signed tokens and policy oracles to an AI pipeline, does this stop attackers from poisoning the agent's judgment about whether to approve actions, and what actually prevents unsafe execution?
the defended figure from the same pipeline, equally unlabeled
-
What blocks rigorous security evaluation of multi-agent systems?
Multi-agent security evaluation faces four major gaps: isolating interaction effects from architecture, designing metrics that diagnose root causes rather than just outcomes, reusing evaluation methods across different system designs, and testing open-system operation. Understanding these gaps is essential for building trustworthy multi-agent systems.
the survey-level frame: comparable metrics need the label this audit would add
Related papers in this collection 8
Papers most semantically related to this note, ranked by cosine similarity in the embedding space.
- Cyber-Capable AI Agents: Vulnerabilities, Evaluation Containment, and Defensive Response
- ChannelGuard: Safe Models Do Not Compose into Safe Multi-Agent Systems
- LLMs Can Covertly Sandbag on Capability Evaluations Against Chain-of-Thought Monitoring
- OpenThoughts: Data Recipes for Reasoning Models
- AI Agent Traps
- From Monoliths to Swarms: A Study of Attack Surface Evolution in the Transition to Multi-Agent Web Systems
- Peer-Preservation in Frontier Models
- Counter-Swarm Doctrine: Containing Coordinated Agent Intrusions
Original note title
which published multi-agent attack and defense numbers were measured behind a provider's server-side filter that the reported outcome silently includes