<\/p>\n\n\n\n
The OWASP GenAI Security Project has released its Top 10 for LLM for 2026. The rankings remain unchanged from last year, with Prompt Injection in first place and Sensitive Information Disclosure in second place, and there appear to be no major changes in the overall rankings.
However, a noteworthy change was hidden behind this. The leaders of the OWASP project stated at the outset, "Stop trying to create a model that can't be fooled, and instead create a system where important things aren't destroyed when the model is fooled." What exactly does this mean? For the past two years, the LLM industry has focused on optimizing AI models. However, according to the latest rankings, the focus should be on "risk containment" rather than optimization. The point is to shift the focus from perfect defense to limiting the blast radius of damage.
In fact, this assessment seems to accurately reflect the current situation. In this blog, we will analyze the important insights that can be gleaned by carefully interpreting the latest rankings.<\/p>\n\n\n\n
Starting with this ranking, evidence data will now be taken into consideration. Practitioner votes account for 751 points (TP3T), and the remaining 25 percent is based on evidence data related to 6,639 real incidents collected from public vulnerability databases and AI damage databases.<\/p>\n\n\n\n
The newly adopted 25% evidence data proved most effective in one area: 'Misinformation'. While it ranked low in practitioner votes, incident records helped it move up two places in the rankings.<\/p>\n\n\n\n
The very discrepancy between "practitioner votes and evidence data" contains an important implication. AI engineers and AI security practitioners tend to focus on attacker-initiated risks (injection, leakage, poisoning). However, records of actual incidents objectively show that the most serious incidents were not caused by attackers. "The model simply made a mistake, and subsequent processing accepted it without question"\u2014such simple occurrences are what become reported and result in actual damage.<\/p>\n\n\n\n
OWASP explains why this isn't just a simple output error, but a system-wide failure, as follows: "The model's output invokes tools, writes code, infers the system's state, authorizes operations, and connects agents. If the output is wrong at that starting point, it's no longer just a 'wrong output,' but a decision that affects the entire system."<\/p>\n\n\n\n
"Excessive Agency" rose to third place, with both practitioner votes and incident data showing the same trend. This indicates that actual damage is occurring in areas where agents are entrusted with the actual work. "Unbounded Consumption" rose four places in the rankings due to practitioner votes, as resource and cost depletion is now visible in the form of monetary amounts on invoices.
The significant rise in these two factors demonstrates that what has the greatest impact on entrepreneurship is not the unsightly output, but the actual actions taken and the money spent.
Most of the countermeasures against these risks, known as "least privilege," have long been discussed in the field of cybersecurity. The concepts of minimizing the scope of privileges, restricting credentials with short validity periods, rate limits and spending caps, and human approval for irreversible operations are the same measures whether it's AI or humans. These measures are fundamental management methods that AppSec has cultivated for over 20 years and can be directly applied to AI. If there is an element unique to AI, it is that "identifying the workers" itself becomes a task. Naturally, you cannot set the scope of privileges for workers who are outside of management. Only by understanding and designing in a way that can explain what AI components exist in your environment, which ones operate autonomously, what they can access, and who launched them, can the prerequisites for "least privilege" be met.<\/p>\n\n\n\n
"System Prompt Leakage" has been renamed to "Hidden Context Exposure." Also, "Cross-Modal Attack," which involves attacks hidden in images or audio, has been incorporated into Prompt Injection. "Fine-tuning Subversion" has been incorporated into "Data and Model Poisoning." "Output Handling" has dropped from 5th to 10th place, but its scope has expanded.
OWASP didn't add new categories, but rather integrated and reorganized existing ones in a rational way. This direction of integration should be understood as a suggestion.
The defense now extends beyond just the prompt input field to the entire context that the model loads. This categorization indicates that everything that enters the context window, regardless of its format or who enters it, should be treated as untrusted input.<\/p>\n\n\n\n
The 2026 edition is also notable for clarifying the overall scope of the LLM Application list. The scope of this list is the security risks of LLMs that exist in models incorporated as components of an application. It explicitly states that the moment a model becomes a "self-operating" entity\u2014that is, a model that has tools it can call, carries its memory across sessions, and drives downstream systems\u2014the list to refer to for identifying these risks changes from the Top 10 for LLM Applications to the Aggent Top 10.
Just because there are two lists with similar names doesn't mean you should judge a risk simply based on "which list it's on." When identifying application risks related to AI, you need to consider "what the component is capable of." The following three points are perspectives for specifically asking "what it is capable of."<\/p>\n\n\n\n
By checking these three points, you should be able to determine which OWASP list to look at, the extent of the impact, and where containment should be implemented.<\/p>\n\n\n\n
First, you should start by identifying coding assistants with write permissions to models, agents, MCP servers, and repositories, as well as any AI that the team has set up without informing IT management or security departments. If you can't actually set permissions and contain the risks based on that information, then it can hardly be called risk management.
We identify the components involved with AI and then classify them based on "what they can do." AI risks cannot be managed by simply organizing which OWASP list they are on, let alone listing components by vendor.
Many companies are starting to use AI in their application coding, but how many of them have clearly documented principles such as, "Treat AI-generated suggestions and fixes, including those from our own tools, as unverified input," and "Do not delegate authority over fix policies to patching agents unless you can take responsibility for their content"?<\/p>\n\n\n\n
In order for AI to truly accelerate application development, incorporating such mechanisms is essential.<\/p>\n\n\n\n
"Even if an AI model fails, we should create a system that prevents it from leading to catastrophic damage." This is the key takeaway from the new OWASP. So, who can create such a system, and how?
At the very least, we can say that "it's impossible for an AI model to handle the entire mechanism itself." Just like humans, AI components cannot properly control the scope of their own influence. That said, we shouldn't leave everything to the vendor of the model that produced the output either. If the vendor creates the models used for inspection and evaluation, the criteria for those judgments will become the same as those of the model that produced the output. In that case, the inspection model will likely overlook any oversights made by the output model.
The issue of "the same model being unable to handle control" is not something that can be resolved simply by improving performance. Certainly, the performance of frontier models continues to improve, and a model six months from now might not make the same mistake as today's model. However, this only reduces the probability of errors; it doesn't resolve the structural issue that the person auditing the model should not be the creator themselves.
Mend.io doesn't write application code. Our job is purely verification, and we verify the code written by our assistants, whatever it may be that generated.
The Mend platform currently offers detection of models, agents, and AI components in your environment, AI-BOM scanning, model risk and agent configuration risk scanning, system prompt hardening, red teaming, and runtime protection within the app or via proxies. We also provide SCA, SAST, container, and IaC scanning of the code itself. AI models are bound to be fooled; whether that becomes a problem depends on what you build around them.<\/p>\n\n\n\n