The 2026 edition of the OWASP Top 10 for applications with LLMs is not just for updating a list of risks. It reinforces a change that already affects those who design products with artificial intelligence: the more the model receives context, accesses data, calls tools and performs actions, the less security can be restricted to the technical layer.
OWASP published the new edition on August 3, 2026. The official page highlights updated rankings, expanded threat coverage, and research backed by thousands of real-world AI-related security incidents. The document also connects the risks of applications with LLMs to references such as NIST, MITER ATLAS, CWE and OWASP's own Top 10 for agentic applications.
For product teams, the main reading is practical: it's not enough to ask if the model responds well. It is necessary to define what it can read, what it can reveal, what it can decide and what it can do when it is wrong or manipulated.
What really changed in the Top 10 for LLMs in 2026
The methodology gained a component that helps explain the new order. In addition to the evaluation of the community of experts, the 2026 edition compared these perceptions with incidents observed in the real world. Analysis of the report records a set of 7,714 incidents, of which 6,639 contained sufficient information for classification. Practitioners' votes continued to account for 75%, while incidents accounted for the other 25%.
The result was not a complete break with 2025. The first two risks remained in the same positions, but there were relevant movements in the rest of the list and an expansion in the meaning of some categories.
| Position in 2026 | Risk | Position in 2025 | Main change |
|---|---|---|---|
| 1 | Prompt Injection | 1 | Stays at the top and starts to consider multimodal inputs, memory and agentic systems more clearly |
| 2 | Sensitive Information Disclosure | 2 | Maintains position and continues to deal with undue exposure of sensitive information |
| 3 | Excessive Agency | 6 | Move up three positions with the advancement of agents, tools and autonomous actions |
| 4 | Supply Chain | 3 | Drop one position, also paying attention to confidence in models, artifacts and components |
| 5 | Data and Model Poisoning | 4 | It drops a position and broadens the perspective on data manipulation and the model adaptation process itself |
| 6 | Unbounded Consumption | 10 | Moves up four positions, bringing availability closer to cost control and computational consumption |
| 7 | Misinformation | 9 | Gains priority as incorrect outputs feed into decisions and automation |
| 8 | Hidden Context Exposure | 7 | Extends and renames the old System Prompt Leakage |
| 9 | Vector and Embedding Weaknesses | 8 | Continues to cover risks in vectors, embeddings and recovery architectures |
| 10 | Improper Output Handling | 5 | Cai no ranking, apesar de manter e ampliar riscos ligados ao uso inseguro da saída do modelo |
The migration of positions and the change in scope are reproduced consistently by analyzes of the 2026 document. In particular, Excessive Agency rises from sixth to third place, Unbounded Consumption goes from tenth to sixth and the former System Prompt Leakage is now treated as Hidden Context Exposure.
O ranking não deve ser interpretado como uma ordem automática de implementação. Um risco que aparece em décimo pode ser crítico em determinado produto. The usefulness of the list is in offering a common language to identify surfaces that, in AI applications, escape conventional software review.
Autonomy is no longer just an engineering decision
Excessive Agency's rise to third place is probably the most direct change for those working in product.
Um chatbot que apenas sugere uma resposta tem um raio de impacto. An agent capable of changing files, calling APIs, querying corporate systems, sending messages, or executing an entire flow has another. The risk is no longer just in the quality of the response and now depends on the permissions granted to the system.
Steve Wilson, co-chair of the OWASP GenAI Security Project, related the rise of Excessive Agency precisely to the fact that current agents navigate, use tools, access systems and act on behalf of users. The associated recommendation is to limit permissions and monitor the behavior of these applications on an ongoing basis.
This turns seemingly functional decisions into security decisions.
If an assistant needs to consult a calendar, for example, the product must decide whether it really needs to edit appointments. Se pode editar, é preciso definir em quais situações, em nome de quem e quando a ação exige confirmação. An “auto-approve” feature isn’t just an experiential convenience: it modifies the possible impact of a failure.
For the PRD, the question is no longer just “which tool does the agent need to use?” and goes on to include “what is the smallest permission required to deliver this function?”.
Hidden context should not function as a protection mechanism
Another significant change is the replacement of System Prompt Leakage with Hidden Context Exposure.
The new name magnifies the problem. The context invisible to the user can contain much more than a system prompt: developer instructions, tool schematics, policies retrieved by RAG, operational information, and other data assembled before the model call.
The recommended reading for the 2026 edition is to assume that this context can be discovered. Therefore, keeping information outside the interface is not enough to treat it as a secret.
For product and architecture, this has a simple consequence: credentials, keys, permissions, or information whose exposure would trigger an incident should not rely on the model to remain hidden.
It also changes the way we think about business rules. An internal instruction can guide the system's behavior, but it should not be the only barrier preventing an operation that the user is not authorized to perform. Authorization must exist in a trusted layer of the application.
Cost is also an abuse surface
Unbounded Consumption moved from tenth to sixth position.
The risk goes beyond classic unavailability. Modern applications can combine large context windows, more expensive reasoning models, multimodal inputs, repeated tool calls, and multi-step flows. This creates situations where a cheap request for those who initiate the process produces a much higher cost for those who operate the service.
A policy that only limits the number of requests may be insufficient when two requests have radically different costs.
This places computational budget within the product design. Limits per user, session or workflow; maximum number of tool calls; token budget; execution limits and mechanisms capable of interrupting abnormal cycles are no longer just financial optimizations.
They also reduce the ability for malicious input or faulty automation to consume resources indefinitely.
A wrong answer can turn into a wrong action
Misinformation also rose, from ninth to seventh place.
While an LLM functions solely as a conversational interface, incorrect information typically reaches a person first. When the output feeds into software, agents, or automated decisions, this error can make its way through the system before anyone notices it.
The analysis of the 2026 edition draws attention to exactly this context change: incorrect output can guide tool calls, code generation and other subsequent actions.
It’s an important difference between “AI quality” and “product safety.”
A product that summarizes documents can tolerate certain types of error differently than an application that transforms model completion into a registration change, permission change or code execution. The validation requirement must accompany the consequence.
In higher-impact functions, probabilistic output should not be automatically treated as authorization to act. Human confirmation, deterministic validations, business rules and verifiable sources may be required before the next step.
RAG does not eliminate the need for access control
Vector and Embedding Weaknesses remains among the top ten risks, now in ninth position.
For products that use RAG, semantic search or vector memory, the relevant point is not to confuse technically correct retrieval with authorization.
Finding the snippet most similar to a question does not mean that that content can be shown to the person asking the question. Authorization must accompany the retrieved documents, chunks, or data before they enter the model context.
Similarly, sources added to the index need provenance and integrity controls. Content retrieved by an LLM continues to be input and can change system behavior, including in scenarios related to prompt injection. The 2026 edition expands the look at unreliable inputs consumed by the model.
The Top 10 can enter the product cycle before the pen test
The list gains more value when it stops appearing only closer to launch.
A practical way to incorporate it into your work is to go through five moments of the cycle:
- Discovery: map what data goes into the model, where it comes from and what consequences an incorrect answer can generate.
- Product definition: record tools, permissions, level of autonomy, irreversible actions and moments that require confirmation.
- Architecture: separate authorization from LLM decision, limit privileges, protect sensitive data and control outputs before they reach other systems.
- Validation: test prompt injection, information leaks, recovered or tampered inputs, tool abuse, excessive consumption and failures in integrations relevant to that application.
- Operation: track behavior, costs, errors, actions taken and changes to models, tools, data sources and permissions.
The sequence is more useful than turning the Top 10 into ten generic compliance boxes. The objective is to discover how each category manifests itself in that product and what the impact is when protection fails.
Agentic applications need a second lens
OWASP itself maintains a Top 10 specific to agentic applications. The document, originally published in December 2025 for the 2026 edition, deals with systems capable of planning, acting and making decisions in complex workflows.
This separation helps avoid a false sense of coverage.
The Top 10 for LLMs remains relevant when the model is a component of the application. When persistent memory, multi-step planning, tools and autonomous actions appear, the analysis must be complemented by the agentic perspective. The documentation and analyzes of the 2026 edition present these two references as complementary.
In practice, a product can start as an assistant and cross this boundary during its evolution. Adding a writing tool, shared memory or authorization to perform an action changes the threat model even if the interface remains practically the same.
That's why an AI safety review shouldn't just happen when the model changes. A new tool, data source, permission, or workflow can also materially change the risk.
The best criterion is the impact radius of the failure
The 2026 edition points to an idea that can guide product decisions even without memorizing all the categories: assume that the model can make mistakes or be manipulated and examine what happens next.
If the ultimate consequence is an inappropriate suggestion that will be reviewed before taking any action, there is a type of exposure. If the same failure can reveal private data, expend unlimited resources, alter a system, or perform an irreversible operation, the design needs additional barriers.
This reasoning brings security closer to concepts that the product already uses: permissions, states, confirmation, reversibility, observability and recovery.
The most useful step for teams that already have AI applications is to review the PRD and threat model with the 2026 edition alongside. For each resource, it is worth identifying where unreliable data comes in, what information reaches the context, what tools are available and what is the biggest impact that a wrong answer can have.
If the system also acts autonomously, the review should incorporate the OWASP Top 10 for Agentic Applications. The 2026 change is precisely to make it clearer that building a “difficult to fool” model is not enough: it is the product around it that needs to limit the consequences when something goes wrong.
