Prompt injection is now the number one security threat to AI systems, and the attack volume backing that claim is not subtle: reports this year point to a roughly 340% year-over-year increase in injection attacks against deployed agents. Pair that with a stat from AvePoint's 2026 State of AI report — 88.4% of organizations experienced at least one agent-related security incident in the past year — and a picture emerges that most engineering teams are quietly living with. We shipped agents that can act, not just answer, and we did it faster than we built the machinery to test whether they act safely.
The industry's answer is red-teaming. NIST extended its adversarial ML taxonomy to cover autonomous agents — indirect prompt injection, memory poisoning, supply-chain attacks on agent tools. OWASP shipped a Top 10 for Agentic Applications. The Five Eyes cybersecurity agencies jointly published guidance on the careful adoption of agentic AI. There are now dozens of red-teaming frameworks and tools competing to scan your agent for jailbreaks.
All of that is good. But there's a quiet assumption underneath most of it that deserves to be pulled into the light: red-teaming is treated as a tooling problem, when in practice it is mostly a data problem. The scanner is the easy part. The hard part is the attack corpus, the judgment about whether a given response actually constitutes a breach, and the labeled trajectories that let you tell "the agent refused correctly" apart from "the agent got lucky." That is data work, and it is the part teams consistently underinvest in.
