OWASP’s 2026 LLM Top 10 and the shift much of the coverage is likely to overlook
The OWASP GenAI Security Project has released the 2026 edition of its Top 10 for LLM Applications. Prompt Injection remains in the number-one position. Sensitive Information Disclosure remains second. Based only on those headlines, the new edition might appear to have changed very little.
But an important shift did occur, and it is not visible in the rankings. The project leads begin with a different security premise: rather than attempting to create a model that can never be deceived, the surrounding system should be designed so that a successful deception does not cause anything important to fail.
That changes the nature of the task. For the past two years, much of the industry has focused on improving the model itself. This edition shifts attention toward improving containment. The objective is no longer perfect prevention, but control of the potential blast radius.
That direction makes sense. It also leads to a consequence that the list itself does not state explicitly, addressed later in this article.
Three shifts worth paying attention to
1. Misinformation moved higher because of evidence, despite the vote
This is the first edition in which empirical data contributed to the ranking process. Practitioner voting still accounted for 75 percent of the final weighting. The other 25 percent was based on 6,639 real-world incidents collected from public vulnerability databases and an AI harm database.
That 25 percent had its clearest effect on one category. Practitioners ranked Misinformation close to the bottom. The incident data placed it much nearer the top. As a result, Misinformation climbed two positions.
The difference between those two assessments is itself significant. Security practitioners tend to calibrate risk around attacker-driven scenarios such as injection, information leakage, and poisoning. The incident record points to another source of costly failures: cases where no attacker is involved at all. The model produces an incorrect result, and a downstream system treats that result as trustworthy.
The project leads explain precisely why this has become a system-level failure rather than merely a content-quality issue. Model output can trigger tool calls, generate code, infer the state of a system, authorize actions, and coordinate activity across multiple agents. An incorrect output at the beginning of that chain no longer remains just an output. It turns into a decision.
2. The impact shifted from what a model says to what a model does
Excessive Agency moved up to third place. In this case, practitioner voting and incident data pointed in the same direction: agentic deployments are increasingly where real damage occurs. Unbounded Consumption rose four positions based on practitioner weighting, reflecting the fact that resource exhaustion and cost overruns have become directly visible as operational expenses.
Placed side by side, those two movements reveal a clear pattern. The most consequential failures are no longer simply embarrassing or inaccurate responses. They involve actions being executed and money being spent.
There is an important positive aspect: most of the required security work is not fundamentally new. Least privilege already exists. So do narrowly scoped credentials with short lifetimes, rate and spending limits, and human approval for irreversible actions. AppSec has relied on these controls for roughly twenty years, and the same principles transfer to AI systems.
The challenge lies in the prerequisite. Permissions cannot be scoped effectively for components that have never been identified. Yet very few enterprises maintain a defensible inventory showing which AI components in their environment are capable of taking actions, what systems those components can access, and who deployed them.
3. The renamed categories reveal more than the ranking changes
System Prompt Leakage was renamed Hidden Context Exposure. Prompt Injection now incorporates cross-modal attacks concealed in images and audio. Data and Model Poisoning now also covers attacks that subvert fine-tuning. Output Handling dropped from fifth to tenth place while simultaneously expanding in scope.
OWASP chose to consolidate concepts rather than introduce additional categories, which is a sensible editorial decision. The direction of that consolidation is especially important: the relevant security boundary is the entire context, not simply the prompt field. Anything capable of entering the context window must be treated as untrusted input, regardless of the format in which it arrives or the party responsible for placing it there.
The boundary problem introduced by OWASP
The 2026 edition is unusually explicit about its scope. It ranks LLM security risks for a model operating as a component within an application. Once that model becomes an actor – with tools it can invoke, memory that persists between sessions, and downstream consequences created by its actions – the relevant framework shifts to the Agentic Top 10.
For that reason, inventory should be based on capability rather than on a specific OWASP list. Three questions should be applied to every identified AI component:
- Can the component call tools or invoke other systems?
- Does it retain state between sessions?
- What systems can it write to, and what exists downstream?
The answers to those three questions determine which list is relevant, how large the potential blast radius may be, and where containment controls need to be placed. They are also questions that cannot be answered without discovery. That is why inventory must precede the controls rather than follow them.
Priorities for the next quarter
- Start with enumeration. The inventory should include models, agents, MCP servers, coding assistants with repository write permissions, and AI systems deployed by individual teams without security being informed. Containment that cannot be scoped remains a presentation concept rather than an operational control.
- Classification should follow capability boundaries, not vendor names and not the particular OWASP list in which a component happens to appear.
- AI-generated remediation guidance should be treated as unverified input, including recommendations produced by internal security tooling. A proposed fix should not be passed into a patching agent unless the underlying remediation direction has already been validated.
- Monitoring should also be designed to detect silent failure. The acceptance criterion should move beyond “does the reproducer stop firing?” The more important question is whether the vulnerable execution path still exists.
- Finally, establish a local benchmark. Testing should be performed against vulnerabilities that have already been fixed in the organization’s own codebase. Planning should be based on those results rather than on an external average.
The consequence the list leaves unstated
The central instruction is to build the surrounding system so that, when the model fails, nothing important breaks. Taken one step further, that principle raises a structural question: who should be responsible for building and validating the system around the model?
The model itself cannot fill that role. A component cannot independently define and constrain its own blast radius. The same responsibility should also not rest entirely with the vendor whose model generated the output, particularly when the checking process relies on the same model family and the same underlying weights. In that structure, the author and the checker can share the same blind spots.
This is not a question of model capability. Frontier models are improving rapidly, and the errors they make today are likely to occur less frequently six months from now. The issue is structural, and structural weaknesses do not disappear with the next model release. The auditor cannot also be the author.
Mend.io does not generate application code. Its role is to verify that code, including code created by AI assistants, regardless of which system produced it.
The Mend platform currently provides discovery and AI-BOM capabilities for models, agents, and other AI components across an organization’s environment. It also includes model risk and agent configuration risk scanning, system prompt hardening, red teaming, and runtime protection delivered either in-app or through a proxy. These capabilities are available alongside SCA, SAST, container scanning, and IaC scanning for the application code itself.
The model will be fooled. The significance of that failure depends on the safeguards and system boundaries built around it.
