You test a security fix on one AI agent, it works, then you add more agents. Why does it quietly stop?

This explores how a security measure that works when tested on a single agent can quietly stop working once that agent becomes part of a larger multi-agent system. The clearest case in the corpus is prompt hardening. In the Header Heist experiments, the same security instructions cut payload exposure by 40 to 75 percent for single agents, and did nothing for multi-agent systems Why does prompt hardening work for single agents but not multi-agent systems?. The single agent avoided malicious sites because the same agent that read the warning was the one deciding where to go. Once the work is split up, the agent that takes the risky action may never have seen the security context. The defense wasn't beaten. It just never reached the place where it was needed.

The failure is silent because a multi-agent setting is not automatically a new kind of security problem. Interaction can leave a failure unchanged, amplify it, create it through composition, or produce new properties altogether Does a multi-agent setting automatically signal a security effect?. Only the last three count as genuinely multi-agent effects. A defense tested on one agent covers the "unchanged" case and nothing else. The other cases fall outside what the test measured, so a passing result says nothing about them. One example is a single biased agent passing persistent behavioral corruption through six downstream agents using only ordinary messages. That bias carries no explicit semantic content, so paraphrasing defenses and detection miss it Can one compromised agent corrupt an entire multi-agent network?. Skills have a similar problem. Attacks that compose across several skills slip past lifecycle inspection that would catch each skill alone Where does agent reliability actually come from?.

A second way to fail silently is that the defense may never have been the thing doing the work. One study reported zero protected-test modifications from a bundle of clear authorization rules plus restricted tools, but no ablation shows which part mattered. The tools may have made the bad action unavailable, or the rules may have made the agent choose not to take it Do authorization rules or restricted tools prevent test modifications?. The companion finding points the same way. Naming a prohibition wasn't enough, and the boundary held only when paired with restricted tools Can explicit authorization boundaries prevent agents from modifying protected tests?. If you don't know which component carried the protection, you can't tell which one breaks when the system changes. That study's own data shows the gap is real: a 100% Judgment Bypass Rate sat alongside a 0% Unsafe Action Rate.

The corpus also points to defenses that are less likely to break. A filter checks one output at one moment, but an agent's risk runs through memory, retrieved content, tool calls and reach into its environment. That is why filters block moments without containing agents Can a model-level filter truly contain an agent with environment access?. Defenses that sit inside the operating environment fare better. One persistent agent logged 889 governance events over 96 active days because its safeguards lived in the memory layer it consulted while working Can governance rules embedded in runtime memory actually protect autonomous agents?. Deterministic checks that don't rely on an LLM's own judgment are another option Can deterministic checks protect LLM judges from failure?. What these have in common is that they don't assume the agent holding the risk also holds the warning.

The corpus doesn't directly test how these defenses hold up as agent counts grow. The evidence here is indirect: it shows where single-agent assumptions stop holding. It doesn't measure how quickly protection decays. The practical lesson is to re-validate a defense in the multi-agent setting itself, and to check whether the protective context reaches the agent that acts.