Any team wiring an agent up to production tools reaches for the cheapest defence on the shelf, a small classifier that sits between the tools and the model, reads every tool output before the agent sees it, and drops whatever looks like a planted instruction. It needs no change to the model or the agent, which is why guardrail toolkits ship one. Teams pick between detectors on benchmark scores.
A researcher at the Japan Advanced Institute of Science and Technology took fifteen of these detectors, Meta's Prompt Guard 2 among them, and measured them on what they screen in a deployment, the serialised records, lists and confirmations that come back from an agent's tools. Getting trustworthy ground truth meant replaying two agent benchmarks' tool calls with no model in the loop at all, so every output was harmless by construction.
The detector that leads the popular public benchmark, where it catches around 95% of injections, caught 2% of them inside the agent. Both figures come from the same setting, each detector tuned so that false alarms stay rare. Another led one agent benchmark and sat near the bottom on the second. The ordering didn't survive the move between benchmarks.
The false alarms were worse than the misses. The share of perfectly ordinary tool outputs flagged as attacks ran from none at all to more than nine in ten, and the worst offender would have stopped nearly seven tasks in ten before anything malicious happened anywhere. One read a bare "Password updated." confirmation as a certain injection. False-alarm rates on ordinary prose predicted none of it.
Two of the fifteen publish enough to audit, and that is where the explanation turns up. The benchmark leader's training set holds that benchmark's own inputs, whole emails and tables with the attacks already inserted. The detector that led both agent benchmarks shares no data with any of them and was trained on agent-shaped inputs instead.
"Our central observation is that a detector works on inputs whose form resembles what it was trained on, and that benchmark scores mostly measure this resemblance rather than a general ability to detect injections."
The benchmark leader had also been trained on most of a third benchmark's attack strings, but as short prompts rather than tool responses. Inside tool outputs it caught them no better than attacks it had never seen. So familiarity with the attack text buys nothing, and the author's reading is that resemblance in the shape of the input decides where a detector works. That explanation rests on the two detectors whose training data is public; for the other thirteen it is inferred from what their model cards claim, and this study can't check it.
"Having seen the attack text does not help when the surrounding input is new."
A guardrail's headline number is a statement about where its training data came from, not about your system. A vendor quoting a detection rate is quoting a result from a corpus. Ask what the thing was trained on, and treat "we top benchmark X" as evidence about X.
The half of this a team can check for itself is also the cheap half, and it needs no attacker. Replay your agent's own tool calls against a clean environment, screen the results, and count the tasks the detector would have killed. That is measurable this week, and it is the number that otherwise arrives later as users filing tickets.
The author is careful that both environments are tidy simulations of YAML and JSON, and that presentation alone moved the false-alarm rates a long way, so absolute figures will shift on real traffic. Separately, this will get over-read as "detectors don't work." They did. The ones built for agent inputs kept false alarms near zero on both benchmarks and caught most injections. What failed was the leaderboard. And since every attack here came from a published template, the detection rates are ceilings. Nobody has measured what these do against an attacker holding the detector and tuning against it.
Sources
- Liu, Z., "Passing the Test You Trained On: Re-evaluating Prompt-Injection Detectors for LLM Agents" — https://arxiv.org/abs/2610.03448