ChannelGuard: Safe Models Do Not Compose into Safe Multi-Agent Systems

Paper · arXiv 2607.19430 · Published July 20, 2026
LLM Failure Modes

Multi-agent LLM applications chain a planner, worker agents, a verifier, and a synthesizer, and every hop between agents is an unmonitored channel through which an adversary can smuggle instructions. Existing defenses guard only the input boundary (IBProtector, Llama Guard, perplexity filters, SmoothLLM) or run outside the application as opaque, stochastic provider-side content filters. We show that this gap carries a consequence practitioners rarely measure: on a 2,100-trace evaluation across eight attack families, five defenses, and three model backends, an undefended pipeline that appears fully safe under standard reporting (attack success 0.000 on tool- and memory-poisoning) owes that safety almost entirely to the cloud provider’s server-side filter (54 of 60 blocks on Azure GPT-5), and re-sources it silently to the agent model’s own alignment when run on a backend without such a filter. Outcome-only reporting hides this dependence.

Introduction. A modern LLM application is rarely a single model call. A planner decomposes a user request into subtasks; worker agents execute them, reading shared memory and calling tools; a verifier scores the workers; and a synthesizer produces the final answer. Every arrow in that pipeline (planner→worker, tool→worker, memory→worker, worker→verifier, worker→synthesizer) carries text from one component to the next, and none of these channels is monitored. An adversarial instruction injected at any point, whether a prompt injection in the user query, a poisoned tool result, or a malicious memory entry, can propagate downstream, and a single compromised worker can corrupt the pipeline’s final output [9, 27]. Existing defenses do not address this surface. Application-level filters (IBProtector [30], SmoothLLM [18], Llama Guard [11], perplexity thresholds [1]) inspect only the user input at the door and say nothing about content flowing between agents thereafter.

Discussion / Conclusion. and Limitations COMPRESS is order-dependent. compress keeps the first N=2 sentences, which assumes injections are appended rather than prepended. Appendix L quantifies this: the inter-agent gates (IB-2– IB-5) have a 100% compress-stop rate on attack traces, but IB-0’s compress band still leaks in 23.4% of cases (58/248), because user prompts more often place the payload in the first two sentences. A revised gate should either drop the COMPRESS band at IB-0 or re-score the retained prefix and PASS only if it also stays below θ. 8 Conclusion

Lines of inquiry this paper opens 12

Research framings built by reading the notes related to this paper — the questions it feeds into.

What drives capability and cost efficiency in agent systems? What causes silent corruption to amplify through delegated workflows? Does decoupling planning from execution improve multi-step reasoning accuracy? How should personalization be implemented to improve AI assistant effectiveness? How should we design LLM systems to maintain alignment and control? What determines success in training models on multiple tasks? Why does verification consistently lag behind AI generation? What coordination failures limit multi-agent LLM systems as they scale?