A safety filter that blocks every attack at one door can miss nearly a quarter of them at another.

This explores whether a prompt-injection defense that works at one entry point into an AI system has to be tested again at every other entry point. The corpus says yes, but per-channel testing is only half of what's needed. The most concrete evidence is a defense called COMPRESS in ChannelGuard, which keeps only the first two sentences of incoming text. At the gates between agents it stopped 100% of injections. At the user-prompt boundary it let 23.4% through Why does compression defense fail at the user prompt boundary?. The reason is that a sanitizer carries an unstated assumption about how attackers behave. COMPRESS assumes injected instructions get appended to the end, but users can put their payload at the start. Nobody had to be careless for this to happen. The assumption held on one channel and failed on another.

The same paper's suggested repair is to re-score whatever the compressor keeps, and to pass it on only if it still clears the same threshold. That turns a positional guess into a measurable check Should sanitizers re-score their compressed output before passing it?. Its cost, its blind spots, and whether it works outside the paper's setting are all untested, so it counts as a hypothesis. A related finding explains why the gap matters. In a planner, worker, verifier, synthesizer pipeline there are five internal hand-offs (planner to worker, tool to worker, memory to worker, worker to verifier, worker to synthesizer). Existing defenses inspect only the user's input, so an injection that arrives in a tool result or in memory can travel downstream unseen Do internal agent hops in pipelines need security monitoring?. The same worry shows up in a different form one layer down. The router that decides which model handles a request sits beneath prompt-level defenses, and it can be manipulated to send traffic to a weaker model Can attackers manipulate which model handles a request?. Prompt-level defenses assume the request went where it was meant to.

A different research area reached a similar conclusion. Work on reward hacking maps which defenses work identically across three settings (model weights, selection, and text) and which only work by loose analogy Which reward hacking defenses actually transfer across training substrates?. Practitioners called that map the most immediately useful part. The parallel is that transfer between contexts has to be checked. Even a defense that transfers directly still has to be confirmed in each new setting.

Per-channel validation still has a ceiling, because some attacks don't live in any one channel or unit. Skill scanners score each skill on its own. ColluSkill uses the scanner's feedback to make each skill look harmless while the chain of skills still does the damage, and it reaches 96% average attack success Can attackers evade skill scanners by refining individual skills?. The fix is to add validation at other levels. One option is to check the assembled workflow just before an irreversible action, where the whole risk picture can be put back together Where should workflow validation gates be placed for safety?. Another is to make the unit of defense a group of linked actions across agents and executions, revised as evidence comes in Should defence units span multiple executions and agents?. Per-hop checks, planning-boundary checks, and commit-point checks each catch attacks the others miss.

The practical rule is to validate each channel against its own attack shapes, then validate across channels. Stating a boundary won't do it. In one test, explicit authorization rules protected test files only when the agent's tools were also restricted Can explicit authorization boundaries prevent agents from modifying protected tests?. A defense that scores perfectly in one place tells you little about the next place until you've tested there.