OWASP released the Top 10 for LLM Applications 2026 on August 3, 2026. It is more than a renamed version of the previous list. The ordering changed, several risks were broadened, and the methodology now combines practitioner judgement with incident evidence.
The most useful way to read the list is not as ten isolated vulnerabilities. An LLM application is a system: it receives instructions and data, retrieves context, calls models, may invoke tools, and sends model output into other components. A weakness at one boundary can amplify a weakness at another.
That systems view also leads to a better security question. Instead of asking, “Can I make the model impossible to fool?”, ask: if the model is fooled, what can the surrounding application still prevent?
This article explains all ten 2026 risks, shows how they connect, and turns the list into practical design decisions.
What changed in the 2026 edition?
The official 2026 guide lists the risks in this order:
| Rank | OWASP 2026 risk | Practical question |
|---|---|---|
| 1 | Prompt Injection | Can untrusted content change the model’s intended behaviour? |
| 2 | Sensitive Information Disclosure | Can the system expose data that should remain private? |
| 3 | Excessive Agency | Can model output cause actions with more power than necessary? |
| 4 | Supply Chain | Can a compromised model, dependency, tool or artifact enter the system? |
| 5 | Data and Model Poisoning | Can manipulated data alter model behaviour or integrity? |
| 6 | Unbounded Consumption | Can inputs or workflows exhaust compute, tokens, money or service capacity? |
| 7 | Misinformation | Can incorrect model output drive a harmful decision or action? |
| 8 | Hidden Context Exposure | Can internal context that should not be trusted as secret become exposed or abused? |
| 9 | Vector and Embedding Weaknesses | Can retrieval or embedding boundaries expose or mix data incorrectly? |
| 10 | Improper Output Handling | Can unsafe model output become an attack input to another component? |
The ranking matters, but it should not become a checklist where rank 10 receives less engineering attention simply because it is last. The impact depends on the application.
OWASP’s 2026 methodology is notable because the project says it combined community voting with an incident corpus. The guide reports 7,714 incidents in the collected corpus, with 6,639 carrying enough detail for classification. Practitioner voting carried three quarters of the final weighting and incident evidence one quarter. That explains why Prompt Injection remains first even though its public incident count did not rank first in the evidence set.
The guide also draws a clearer boundary between LLM applications, where the model is a component, and agentic applications, where a model acts with tools, memory and downstream consequences. For the latter, OWASP recommends using this list together with its separate Top 10 for Agentic Applications 2026.
1. LLM01:2026 Prompt Injection
Prompt injection occurs when input changes model behaviour in a way the application developer did not intend. The input might be a direct user prompt, but it can also arrive through a retrieved webpage, email, document, image, tool result, RAG passage or persistent memory.
That second case is particularly important. Imagine an internal assistant that reads support tickets. A customer cannot access the company’s private knowledge base directly, but can place text in a ticket. If the assistant later reads that text while operating with broader privileges, the ticket has crossed a trust boundary through the model.
This is why prompt injection is not solved by adding a sentence such as “ignore malicious instructions” to the system prompt. OWASP’s 2026 guidance explicitly treats defence as architectural. Limit capabilities, validate outputs, mediate privileged calls in deterministic code, separate content by provenance, and require confirmation for sensitive actions.
For a deeper treatment, see Prompt Injection Explained.
2. LLM02:2026 Sensitive Information Disclosure
An LLM application may handle personal data, financial records, credentials, confidential documents, proprietary information or private retrieved context. Disclosure risk exists when information reaches a user or downstream system that is not authorised to receive it.
A useful design principle is simple: do not rely on the model to decide access control.
Suppose a RAG assistant serves employees from several departments. If retrieval fetches documents first and asks the model to “only show what this user may see”, the security boundary is already weak. Authorization should constrain retrieval before sensitive content enters the model context.
The same reasoning applies to secrets. API keys and passwords should not be embedded in prompts or system instructions. Keep credentials in a secrets-management layer and let trusted application code use them without exposing their values to the model.
This connects directly with protecting sensitive data and credentials when using AI tools.
3. LLM03:2026 Excessive Agency
Excessive Agency moved to third place in the 2026 list. The risk appears when an LLM application has more functionality, permissions or autonomy than its task requires.
Consider two email assistants. Assistant A can draft a reply and wait for approval. Assistant B can read every mailbox, send messages, delete mail and access a CRM using a highly privileged service account. A successful manipulation of Assistant B has a much larger blast radius even if both use the same model.
The strongest controls therefore live outside the prompt:
- expose only the tools required for the task;
- give each tool the minimum permissions it needs;
- authorize the user and action at execution time;
- validate tool arguments in trusted code;
- require human approval for privileged, irreversible or externally visible actions.
This is normal least-privilege engineering applied to AI.
4. LLM04:2026 Supply Chain
Modern AI applications inherit a large supply chain. It can include foundation models, fine-tuned weights, adapters, datasets, Python packages, container images, model-serving infrastructure, plugins and external tools.
A team can write secure application code and still deploy an unsafe system if a trusted artifact has been tampered with or comes from an unverified source.
Practical controls include maintaining an inventory, pinning versions, verifying signatures or hashes where supported, reviewing model and dataset provenance, scanning conventional dependencies, and controlling who can promote artifacts into production. Third-party model terms and data-handling behaviour also belong in the risk assessment because confidentiality can be affected without a traditional software exploit.
5. LLM05:2026 Data and Model Poisoning
Poisoning targets integrity. Training data, fine-tuning data, embedding corpora or model artifacts are manipulated so that the resulting system behaves incorrectly, develops a backdoor, or produces attacker-influenced results.
For a RAG system, the practical version may be easier to picture. If an attacker can add a document to the knowledge source, retrieval may repeatedly place attacker-controlled content into future prompts. The security problem is therefore not only “is the model safe?” but also “who can write to the information the model trusts?”
Protect data pipelines with provenance, write controls, review, versioning and monitoring. Treat changes to training, fine-tuning and retrieval corpora as security-relevant changes, not merely content updates.
6. LLM06:2026 Unbounded Consumption
LLM services consume finite resources: tokens, GPU or accelerator time, API quota, memory, storage and money. A system that lets one request trigger uncontrolled generation, recursive tool calls or repeated model invocations can become expensive or unavailable.
The fix is not a single rate limit. Bound the work at several levels: request size, output length, requests per identity, tool-call count, recursion depth, concurrent jobs, retrieval size, timeouts and spending thresholds.
For example, an agent should not be allowed to keep calling a search tool until it “feels finished” with no maximum step count. Give the workflow an explicit budget and define what happens when that budget is exhausted.
7. LLM07:2026 Misinformation
A fluent answer can still be wrong. Misinformation becomes a security or safety problem when users or automated systems treat model output as authoritative and act on it.
The consequence depends on context. A wrong movie recommendation is inconvenient. A fabricated security configuration, false legal statement or incorrect incident-response instruction can cause real damage.
Grounding can improve accuracy, but retrieval is not proof of truth. High-impact workflows should verify claims against authoritative sources, expose uncertainty where appropriate, and keep human judgement in decisions that cannot safely be automated.
This is also why output should be treated according to its purpose. Text for brainstorming has a different assurance requirement from a command that changes a firewall.
8. LLM08:2026 Hidden Context Exposure
The 2026 edition broadens the former “System Prompt Leakage” category into Hidden Context Exposure. That is a useful change because the real problem is larger than revealing one prompt.
System prompts, internal reasoning context, hidden instructions, retrieved metadata and implementation details may be exposed or may contain information that was incorrectly assumed to be secret.
A system prompt should never hold credentials or become the application’s authorization mechanism. If learning the prompt breaks security, the design has confused obscurity with access control.
The safer assumption is that hidden context may eventually become observable. Put actual secrets in proper secret stores and enforce permissions in application code.
9. LLM09:2026 Vector and Embedding Weaknesses
RAG applications commonly convert information into embeddings and search a vector store for semantically related content. That creates security questions that do not exist in a simple chatbot.
Can one tenant retrieve another tenant’s vectors? Are document permissions enforced before retrieval? Can untrusted content enter the corpus? Does deletion from the source also remove derived embeddings? Can metadata filters be bypassed or misconfigured?
A vector database is still a data store. Apply tenant isolation, authorization, provenance, lifecycle controls and monitoring. Do not assume semantic similarity is an access-control decision.
10. LLM10:2026 Improper Output Handling
Model output is untrusted data. Problems arise when another component treats it as safe code, markup, a database query, a shell command, a URL or trusted tool arguments without suitable validation.
Suppose an LLM generates HTML that is inserted directly into a page. The fact that the HTML came from a model does not remove normal web-security requirements. The output still needs context-appropriate encoding and sanitization.
Likewise, generated SQL should not be given unrestricted database privileges, and generated shell commands should not be executed merely because they match a natural-language request.
The general rule is familiar from secure software development: validate at the boundary where data crosses into a more trusted interpreter or component.
How the ten risks combine in a real architecture
The most serious failures often involve several categories at once. An indirect prompt injection can influence a model, excessive agency can give that influence useful permissions, sensitive context can provide valuable data, and improper output handling can create an exfiltration path.
That is why mapping one control to one OWASP item is often too simplistic.
The diagram shows a practical design principle: the LLM sits inside the security architecture. It does not replace it.
Untrusted content is labelled and constrained before reaching the model. The model can propose an action, but a deterministic policy layer checks identity, permission and arguments. Tools operate with least privilege. Outputs are validated before another component interprets them. High-impact actions can require explicit human approval.
No single box makes prompt injection disappear. The goal is to stop one model failure from becoming a system compromise.
A practical review method for your own LLM application
Rather than asking a team to “check the OWASP Top 10”, walk through the application as a data and authority flow.
Start with inputs. List every place content can enter: users, files, web retrieval, RAG, APIs, tool responses, memory and multimodal input. Mark which sources are untrusted or only partly trusted.
Then inspect data. Identify what sensitive information can enter prompts, retrieval results, logs and model outputs. Check whether authorization happens before retrieval and whether secrets are unnecessarily exposed to the model.
Next inspect authority. List every tool and downstream action the model can influence. Record the identity used, permissions granted, maximum number of actions and whether approval is required. If a model can read untrusted content and also perform high-impact writes, that deserves special attention.
Review the supply chain and knowledge pipeline. Know where models, adapters, packages and datasets came from, who can update them, and how production versions are verified.
Finally inspect outputs and resources. Decide which outputs are only text for a human and which become input to code, browsers, databases or tools. Put limits around tokens, requests, recursion, tool calls and spending.
This approach turns the Top 10 from a document into a threat-modeling exercise.
Common mistakes when applying the OWASP list
One mistake is treating a strong system prompt as a security perimeter. Prompts can guide behaviour, but authorization, secrets management and execution policy need deterministic enforcement.
Another is testing only the chat box. An application that reads webpages, tickets, repositories or documents has indirect input surfaces too. Security testing should follow every path by which attacker-controlled content can reach the model.
A third mistake is securing the model while ignoring the ordinary application around it. Authentication, access control, dependency management, output encoding, logging and rate limiting still matter. AI security extends application security rather than replacing it.
Finally, do not confuse the Top 10 with a complete risk assessment. It is a prioritization and awareness framework. Your architecture, data sensitivity, users, legal obligations and business impact determine which controls deserve the most attention.
What should developers prioritise first?
For a new LLM application, I would translate the 2026 list into five engineering priorities:
- Assume model manipulation is possible. Design for containment rather than perfect prompt obedience.
- Keep authorization outside the model. Enforce identity, access and tool permissions in trusted code.
- Minimise data and capability. Give the model only the context and actions required for the current task.
- Treat both inputs and outputs as untrusted. This includes retrieved content, tool results and generated code or markup.
- Make the system observable and bounded. Log meaningful actions and place explicit limits on resource use and autonomy.
These priorities cover several Top 10 entries at once, which is exactly what good architecture should do.
The larger lesson from OWASP 2026
The 2026 list reflects a maturing view of LLM security. The model is important, but the security outcome is increasingly determined by the architecture wrapped around it.
Prompt injection shows why instructions and data cannot be assumed to stay separate. Excessive agency shows why a model’s permissions matter as much as its behaviour. Hidden context exposure shows why prompts are poor places for secrets. Improper output handling shows that conventional secure coding remains essential.
The practical objective is therefore not to build an LLM that never makes a mistake. It is to build an application where a model mistake, manipulation or false answer encounters additional boundaries before it can become a damaging action.
For the wider picture, read What Is AI Security? and AI Agents and Cybersecurity.
Sources and further reading
- OWASP GenAI LLM Top 10 2026, released August 3, 2026.
- OWASP Top 10 for LLM Applications 2026 full guide, including the 2026 ranking, methodology, mitigations and framework mappings.
- NIST AI Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1, published July 26, 2024 and updated on the NIST site April 8, 2026.
- OWASP Top 10 for Agentic Applications 2026, for systems where models operate as agents with tools, memory and autonomous workflows.
The cover and architecture diagram in this article are original illustrations created for dulmina.com. They summarize independently verified concepts from the sources above and do not reproduce OWASP artwork.