The security risks for LLM applications have changed as the applications themselves have become more capable. A model may now retrieve internal data, call tools, generate code, or take actions in other systems, giving attackers more ways to influence what the application does.
The 2026 edition of the OWASP Top 10 for LLM Applications reflects how these applications are being built today and updates the risks teams need to consider when designing and developing them.
What moved since 2025
The 2026 list still covers 10 risk areas, but the ranking has changed since 2025. Several categories have been expanded, and one has been renamed, to account for newer attack patterns and how LLM applications are being built.
| 2026 rank | Risk | 2025 rank | Movement |
|---|---|---|---|
| LLM01 | Prompt Injection | 1 | No change |
| LLM02 | Sensitive Information Disclosure | 2 | No change |
| LLM03 | Excessive Agency | 6 | Up 3 |
| LLM04 | Supply Chain | 3 | Down 1 |
| LLM05 | Data and Model Poisoning | 4 | Down 1 |
| LLM06 | Unbounded Consumption | 10 | Up 4 |
| LLM07 | Misinformation | 9 | Up 2 |
| LLM08 | Hidden Context Exposure | 7 | Down 1, renamed from System Prompt Leakage |
| LLM09 | Vector and Embedding Weaknesses | 8 | Down 1 |
| LLM10 | Improper Output Handling | 5 | Down 5 |
Understanding the OWASP Top 10 for LLM Applications
1. Prompt Injection
Prompt Injection stays at number one, although the definition now extends further than it did in 2025. It occurs when an attacker crafts input that changes how an LLM behaves or causes it to disregard its intended instructions. The attack can come directly from a user, and it can also arrive through content the application retrieves, such as a document, web page, email, image, or other external data.
The 2026 edition broadens the category to include cross-modal prompt injection, as LLM applications are working more with multiple types of input. Malicious instructions can be embedded in content such as images or audio rather than plain text.
OWASP says there is no reliable way to prevent prompt injection today because models do not reliably separate instructions from data. Developers should therefore assume an injection could succeed and design the application so it cannot cause serious harm. Security controls should sit outside the model wherever possible, and authorization and access decisions should not depend on the model identifying malicious instructions.
2. Sensitive Information Disclosure
Still in second place, Sensitive Information Disclosure refers to an LLM application that leaks sensitive information through its responses or other parts of the application. It could include personal data, credentials, proprietary information, confidential business data, or information retrieved from connected systems.
Applications that use retrieval-augmented generation (RAG) create another security concern. If a user can cause the application to retrieve information they are not authorized to access, the problem may occur before the model generates a response. The model is being given data that should never have entered its context.
Keeping sensitive data away from the model in the first place and checking a user’s permissions before retrieving data are the most dependable controls.
3. Excessive Agency
Excessive Agency, which OWASP describes as the most consequential move on the list, is the risk of giving an LLM application more access or autonomy than it needs.
OWASP identifies three common causes:
-
Excessive functionality: An AI assistant that only needs to read documents but can also modify or delete them.
-
Excessive permissions: A tool that needs read access to a database but automatically receives write access.
-
Excessive autonomy: A high-impact action that the model can take without an independent authorization check or user approval.
It’s a good idea to enforce these decisions in the application instead of relying on the model to decide whether an action is allowed.
4. Supply Chain
LLM applications depend on a growing collection of external components. These can include models, datasets, libraries, plugins, tools, hosted services, and other third-party resources. A weakness or compromise somewhere in that chain can affect the security of the application that depends on it.
In the 2026 edition, the category covers additional trust failures around AI components, including cases where a model artifact is presented as a trusted model but has been modified or replaced with a malicious version.
Developers need to check where their models, datasets, and other AI components come from and make sure those components have not been modified or replaced. OWASP puts supply chain risks specific to agents, including MCP servers and tool registries, in the Top 10 for Agentic Applications.
5. Data and Model Poisoning
An AI system can be manipulated if an attacker gets malicious data into the data it uses, changing how the model behaves when it receives certain inputs.
With poisoning specifically, an attacker manages to influence data used to train, fine-tune, retrieve from, or otherwise support an AI system. The aim can be to change the model’s behavior, introduce specific responses, weaken security controls, or cause targeted behavior when particular inputs are encountered.
The 2026 edition also adds fine-tuning subversion, where an attacker manipulates the fine-tuning process to introduce a backdoor into the model.
Developers need to know where the data and models they use come from and make sure they have not been changed without their knowledge. Checking data and model changes before they reach production can help prevent malicious changes from making it into the application.
6. Unbounded Consumption
Unbounded Consumption moves up four places and is about how LLM applications can consume a lot of resources through model calls, tokens, context, retrieval operations, and other processing. An attacker who can repeatedly cause expensive or resource-intensive operations can cause service disruption or unexpected costs. The same repeated queries can also be used to copy a model’s behavior.
This category has existed since the 2025 update, but its move to sixth place in 2026 shows the growing importance of controlling how AI applications consume resources.
Developers can limit this risk by controlling how often the application can be called and how much work each request can trigger. They should also watch for expensive operations an LLM can trigger, especially when it can call tools or retrieve large amounts of data.
7. Misinformation
Misinformation moves up to seventh place. By now it’s become apparent that LLMs can produce inaccurate, misleading, or fabricated information while presenting it in a convincing way. The risk becomes a security concern when an application or its users rely on that output for decisions or when incorrect information is passed into another system.
Obvious hallucinations are only part of the issue. An application can produce plausible information that is wrong because the retrieved data is incomplete or the model interprets the available information incorrectly.
Important outputs should be checked before they are acted on. Depending on the application, that could mean checking responses against trusted data or having a person review them before they influence an important decision.
8. Hidden Context Exposure
Hidden Context Exposure replaces the 2025 category System Prompt Leakage and moves down one place to eighth.
The name changed because the risk is broader than exposing only a system prompt. An LLM application can also have other information in its context that users aren’t meant to see, such as developer instructions or details about the tools it can use.
If an attacker can get that information out of the model, they may learn more about how the application works or see information that should have stayed private.
The important point is that hidden information isn’t necessarily secret. Developers shouldn’t put credentials or other sensitive information into the model’s context, and they shouldn’t rely on hidden instructions to keep an application secure.
9. Vector and Embedding Weaknesses
This category covers security problems in the vector databases and embedding systems used by LLM applications, particularly those using RAG. These systems can affect what information the application retrieves and who can access it.
An attacker could try to influence what the application retrieves or take advantage of weaknesses that allow one user’s data to be returned to another.
Developers need to secure these systems just like other parts of the application. They should control who can add or change data and make sure users can only retrieve information they are allowed to access.
10. Improper Output Handling
Improper Output Handling drops from fifth place to tenth. This risk comes up when an application passes content generated by an LLM to another part of the application without validating or encoding it first. Because attackers can influence model output, treating it as trusted can introduce security vulnerabilities.
The 2026 edition also expands the category to cover insecure code generated by AI assistants. That matters as more developers use AI to generate code that ends up in applications.
The basic rule is that LLM output is untrusted input. Developers should check generated content and limit what it can do before passing it to a database, browser, operating system, API, or another part of the application.
Keeping controls outside the model
The practical lesson across the ten risks is that the model cannot be the only security control. Developers should design applications so that a manipulated model or incorrect output cannot cause serious harm, and checks and permissions should sit outside the model.
These controls are easier to build when developers have practiced the risks and consider security early in the design.
Applying the OWASP Top 10 with SecureFlag
Reading about and understanding these risks helps, but developers also need to practice addressing them in code. Realistic development scenarios give them a chance to identify and fix those risks.
SecureFlag provides hands-on security labs covering OWASP’s LLM and agentic AI risks, including prompt injection, sensitive information disclosure, excessive agency, insecure AI-generated code, and others. Developers can work through real-world security problems and practice applying the controls that protect AI applications during development.
Many of these risks are also easier to address during design, before the code is written. ThreatCanvas, SecureFlag’s automated threat modeling solution, includes risk templates aligned with the OWASP Top 10 for LLM Applications and agentic AI.
