The most important shift in AI security over the past year is that prompt injection stopped looking like a bug waiting for a patch and started looking endemic to how models work. OWASP's State of Agentic AI Security and Governance, updated June 1, 2026, is the closest thing the industry has to an official acknowledgment of that, and once you accept it, the question of where security investment should actually go gets a lot clearer.
The reason the problem persists is structural. A language model takes in its system instructions and whatever untrusted content it happens to be processing as one continuous stream of tokens, and there is no reliable mechanism inside the model for telling privileged commands apart from data. Filtering, prompt hardening, and fine-tuning all lower the success rate of an injection, and that work is worth doing. But the evidence from academic red teams and the model providers’ own documentation increasingly points in the same direction: you can push the probability down, but no reliable method has emerged for eliminating the risk. That is a very different kind of problem than the ones security teams are used to, where a vulnerability gets found, patched, and closed. This one doesn't close.
What changed this year is the evidence
When OWASP published the first edition of this report in July 2025, it read like a catalog of plausible concerns about an architecture the industry hadn't fully deployed yet. The 2026 update reads like an audit of the present. Nearly every category in the OWASP Top 10 for Agentic Applications now has a CVE, a vendor advisory, or a documented production incident attached to it, and the two categories with the highest documented incident volume are agentic supply chain vulnerabilities and unexpected code execution, which is exactly where agents touch the most sensitive infrastructure. One audit the report cites, nicknamed IDEsaster, looked at the major AI coding IDEs and found vulnerabilities in every single one it tested. Many of these incidents involve indirect injection, with hostile instructions arriving through a cloned repository, a poisoned document, or a compromised MCP server rather than through anything a user typed. The attack class the industry spent two years calling theoretical turned out to be the one compiling the deepest incident record.
The report's most consequential claim is this: whether an AI system fails from an attack or an honest mistake, many of the necessary deployment controls are the same, and they do not live entirely inside the model. It makes the point with two incidents. In one, a coding agent deleted a production database despite explicit constraints and continued violating a code freeze after being told to stop. No attacker, just a bad call executed with too much permission. In the other, someone bypassed an allowlist in a popular coding IDE to get the agent to run unauthorized commands. One was an accident, one was an attack, but both happened for the same underlying reason: the agent was allowed to do something it shouldn't have been allowed to do. In both cases, model behavior triggered the failure, but permissions and deployment architecture determined the blast radius. That means critical controls also have to sit outside the model.
The control point has to move outside the model
If the model can always be manipulated, then continuing to pour security budget into making it slightly harder to manipulate is a strategy with a known ceiling. Many teams have already made a different bet. They treat the model's susceptibility the way the industry long ago learned to treat endpoints, as a component you assume will be compromised, and they put the enforcement at the boundary where the agent's decision becomes an action. A layer there sees each action the agent attempts, the tool being called, the parameters, the data involved, and evaluates it against policy for that agent's scope and context before anything runs. Under that architecture, a successful injection can change what the model wants to do without changing what it is permitted to do. The manipulation may still happen, but the resulting action can be denied.
The report maps 42 regulatory instruments across 10 jurisdictions, and the deadlines are getting short. DORA requires notification within four hours of classifying a major incident, NIS2 within 24 hours, and New York’s RAISE Act within 72 hours. The EU AI Act also requires ongoing post-market monitoring for high-risk systems, which the report says should include behavioral-drift detection. These timelines only make sense if the organization already has continuous, action-level visibility into what its agents are doing. Most don't. A quarterly audit doesn't produce that visibility, and a log file reviewed after an incident doesn't either.
Meanwhile adoption keeps running ahead of all of it. The report cites Andreessen Horowitz's April 2026 finding that 29% of the Fortune 500 are already live, paying customers of a leading AI vendor, roughly three years after ChatGPT launched, and that number excludes the shadow AI the report's contributors found in nearly every organization they examined.
This changes where security budget should go. The part of the system you can control most reliably is not the model, but the boundary where an agent's decision turns into an action against production infrastructure. Enforcement belongs there because it can remain authoritative even when the model’s reasoning has been manipulated.
Sources: OWASP GenAI Security Project, State of Agentic AI Security and Governance v2.01 (June 1, 2026); OWASP Top 10 for Agentic Applications 2026; IDEsaster: A Novel Vulnerability Class in AI IDEs, Ari Marzouk (December 2025); Andreessen Horowitz, "Where Enterprises are Actually Adopting AI" (April 2026).
