AI security
OWASP Top 10 for LLM applications, explained with examples
The OWASP Top 10 LLM list, officially the OWASP Top 10 for LLM Applications, names the ten most critical security risks in software built on a large language model (LLM), such as chatbots and AI agents. The 2026 edition keeps prompt injection first and moves excessive agency up to third place. This guide explains each risk in plain words, with an example from a business AI system and the first controls to put in place.
By the KDS security engineering teamPublished 11 min read
Key takeaways
- OWASP released the 2026 edition on August 3, 2026. Prompt injection stays at LLM01 and excessive agency rises to LLM03.
- System prompt leakage became hidden context exposure, which also covers tool lists, policy text and other instructions users do not see.
- For the first time, OWASP checked the practitioner vote against a record of real incidents when it set the order.
- Most first controls sit outside the model: narrow permissions, checks in code, human approval, spending caps and monitoring.
- The list treats the model as a component. For AI agents that act on their own, add the OWASP agentic list.
On this page
What the OWASP Top 10 for LLM applications is
The list comes from the OWASP GenAI Security Project, an open community of security practitioners, developers and researchers. Version 1.0 appeared in August 2023, the 2025 edition in November 2024 and the 2026 edition (opens in a new tab) on August 3, 2026. Each entry describes one risk and gives examples, attack scenarios and ways to prevent it or limit the damage.
The list treats the model as a component inside your application. The 2026 edition draws a clear line: once the model becomes an actor, with tools it can call, memory it keeps between sessions and actions with real consequences, the OWASP Top 10 for Agentic Applications (opens in a new tab) applies as well. Our guide to the OWASP agentic top 10 covers that second list.
What changed in the 2026 edition
Earlier editions were based on a vote among practitioners. For 2026, the project also collected 7,714 real incidents from public vulnerability databases and an AI harm database and compared that record with the vote. The vote carries three-quarters of the weight and the incident data one quarter. The main changes:
- Excessive agency rose from sixth to third, because the vote and the incident record both point to AI agents as the place where harm occurs.
- Unbounded consumption rose from tenth to sixth and misinformation from ninth to seventh.
- Improper output handling fell from fifth to tenth, the largest drop on the list.
- System prompt leakage (LLM07:2025) became hidden context exposure (LLM08:2026), with a wider scope.
- Three entries moved down one place each: supply chain (now LLM04), data and model poisoning (LLM05) and vector and embedding weaknesses (LLM09).
The OWASP Top 10 LLM list for 2026 at a glance
| Risk | What goes wrong | First controls |
|---|---|---|
| LLM01 Prompt injection | Hidden instructions in content the model reads change its behavior | Untrusted input handling, least privilege, approval for risky actions |
| LLM02 Sensitive information disclosure | Private data leaks through answers, logs or retrieved documents | Access checks before retrieval, minimal context, no secrets in prompts |
| LLM03 Excessive agency | Tools, rights or autonomy exceed the task and enable harmful actions | Fewer and narrower tools, user-level permissions, human approval |
| LLM04 Supply chain | A third-party model, dataset or package is tampered with | Inventory, pinned and verified components, supplier review |
| LLM05 Data and model poisoning | Manipulated data plants errors, bias or hidden triggers | Known data sources, validation, limited write access |
| LLM06 Unbounded consumption | Floods and loops cause outages or high AI usage costs | Token and cost limits, hard spending caps |
| LLM07 Misinformation | A confident but wrong answer drives a decision or action | Current sources, checks before action, approval for high impact |
| LLM08 Hidden context exposure | Prompts, tool lists or rules are extracted and used against you | No credentials in context, limits enforced in code |
| LLM09 Vector and embedding weaknesses | Similarity search leaks data or returns planted content | Access control inside the index query, separate indexes |
| LLM10 Improper output handling | Model output runs as code, SQL or HTML elsewhere | Output treated as untrusted, encoding, parameterized queries |
LLM01: Prompt injection
Prompt injection means tricking the model with instructions hidden in what it reads: a chat message, a web page, an email, a document, a tool result or even an image or audio file. Models do not reliably separate instructions from data, and OWASP states that no reliable prevention exists today. The defense is to limit what a fooled model can do. Our prompt injection guide covers the attacks in depth.
Example: a support chatbot summarizes PDFs that customers upload. One file contains white-on-white text telling the bot to add another customer's delivery address to its reply.
First controls:
- Treat every outside source as untrusted, including tool results and uploaded files.
- Keep credentials and actions in application code, with the least access the task needs.
- Require human approval for actions that send data out or change records.
LLM02: Sensitive information disclosure
The system exposes personal, confidential or regulated data to someone who should not see it. The answer on screen is only one channel. OWASP also lists tool-call arguments, reasoning traces, retrieved passages, logs and monitoring tools. A common cause is a knowledge base that contains files the user could not open directly.
Example: an internal HR assistant searches a shared drive with old, broad permissions. An employee asks about pay ranges and receives passages from a confidential salary review.
First controls:
- Check access rights inside the search query, before anything reaches the model.
- Send the model only the fields its task needs, and keep secrets out of system prompts.
- Remove personal data from logs and traces, and limit queries per user on sensitive data.
LLM03: Excessive agency
The model can trigger damaging actions because it has more functions, permissions or autonomy than its task requires. The trigger does not have to be an attack: a hallucination or a compromised tool can cause the same harm as an injected instruction. Our guide to AI agent permissions shows how to set these limits.
Example: a sales agent only needs to add notes to leads in your CRM, but it connects with an administrator account. A manipulated conversation leads it to export the full contact list.
First controls:
- Remove tools and functions the task does not use, and prefer narrow tools over open-ended ones such as a shell.
- Run each action with the permissions of the user it serves, and enforce authorization in code.
- Let reversible, low-impact actions run automatically and send irreversible ones, such as an outside payment, to a person.
LLM04: Supply chain
Your application depends on parts you did not build: pre-trained models, fine-tuning adapters, datasets, software packages and conversion tools. Any of them can be outdated, tampered with or published under a trusted-looking name. The 2026 entry adds a newer pattern: AI coding assistants invent package names, and attackers register those names in advance.
Example: a developer asks a coding assistant for a library to read invoice PDFs. The assistant invents a package name, an attacker has already registered it with malicious code and the build installs it.
First controls:
- Keep an inventory of models, datasets and packages, often called a software bill of materials (SBOM).
- Use verified sources, pin exact versions, check hashes or signatures and confirm that AI-suggested packages are the intended ones.
- Review each provider's security and data use terms, including whether your data can be used for training.
LLM05: Data and model poisoning
Someone manipulates training data, fine-tuning data or model files so the model learns wrong behavior, a bias or a hidden trigger, called a backdoor. The model can pass standard tests until the trigger appears. OWASP cites a 2025 study (opens in a new tab) in which 250 poisoned documents planted a backdoor in models of every size tested. A fix can mean retraining or replacing the model.
Example: a company retrains its support chatbot every month on rated conversations. Through ordinary chats, an attacker teaches it to share a fake payment link when a certain phrase appears.
First controls:
- Record where every dataset comes from and keep versions, so you can roll back.
- Validate data before it enters fine-tuning or the knowledge base, and limit who can write to it.
- Add human review to retraining from user feedback, and test for hidden triggers after each cycle.
LLM06: Unbounded consumption
The application allows excessive or uncontrolled model requests. The results are outages, runaway AI usage costs (known as denial of wallet) or theft of the model's behavior through mass queries. The attacker pays little and you pay a lot, and reasoning models, audio input and agent tool loops widen that gap.
Example: a voice agent answers a public phone line. A script places many long calls, and each turn reprocesses the growing conversation, so costs climb while every single request stays under the rate limit.
First controls:
- Limit tokens and estimated cost per user, session and day, not only requests per second.
- Set hard spending caps that stop processing. OWASP notes that alerts alone can be too slow.
- Cap the steps, time and cost of each agent run and the length of calls and chats.
LLM07: Misinformation
The model produces false, incomplete or misleading information that looks credible, and a person, a workflow or an agent acts on it. Causes include hallucination, outdated sources and summaries that leave out key limits. When output drives a tool call, a wrong answer becomes a wrong action.
Example: a chat agent tells a customer that a product has a 2-year warranty, because an old policy page is still in its knowledge base. The customer later asks you to honor that promise.
First controls:
- Answer from approved, current sources, and remove outdated documents.
- Check facts and preconditions in code before an action runs, and require structured output with mandatory fields.
- Require approval for high-impact decisions, and test with misleading scenarios.
LLM08: Hidden context exposure
Anything the application places in the model's context without showing it to the user can be extracted or inferred: the system prompt, developer instructions, retrieved policy text and the list of tools with their parameters. This entry replaces system prompt leakage and covers more ground. OWASP advises you to assume this context can be discovered and to design so that its disclosure does little harm.
Example: a booking chatbot's system prompt holds an API key for the calendar system and a rule that partners get a larger discount. An attacker extracts the prompt, uses the key directly and claims to be a partner.
First controls:
- Keep credentials, connection strings and tokens out of prompts and other hidden context.
- Enforce authorization, discounts and other business limits in code, not in instructions.
- Test as if the attacker already knows your tool list and rules.
LLM09: Vector and embedding weaknesses
Many AI systems turn documents into numeric vectors, called embeddings, and use similarity search to choose what the model sees. This powers retrieval-augmented generation (RAG), agent memory and semantic caches. Attacks target the search layer: planted content that ranks for a chosen question, leaks between customers and stored vectors that can be turned back into text.
Example: a company treats a leaked backup of its vector database as harmless because it holds only embeddings. Inversion methods can rebuild much of the source text, so it is in fact a leak of the original documents.
First controls:
- Enforce access rights inside the index query, with separate indexes for sensitive customers or trust levels.
- Record the source of every entry, and review outside content before it enters sensitive indexes.
- Protect vector backups like the source documents, and do not show raw similarity scores to users.
LLM10: Improper output handling
Model output goes to another system, such as a browser, a database, a shell or an email template, without validation or encoding. Users can steer the output through the prompt, which can lead to cross-site scripting (XSS), SQL injection or remote code execution. The 2026 entry adds insecure code written by AI assistants and chat interfaces that load images from links in the output.
Example: a website chat widget shows the model's reply as HTML and loads any image in it. A crafted prompt adds an image link that sends the conversation to an outside server.
First controls:
- Treat the model like an untrusted user, and encode its output for each destination.
- Use parameterized queries for database access and a strict Content Security Policy on web pages.
- Load images and link previews only from approved domains, and review generated code before it goes live.
How to use the list in your AI projects
Threat modeling
For each AI system, write down what it reads, what data it can reach and what actions it can take. Then go through the ten entries and note which apply, how an attacker would reach them and what the impact would be. A chatbot without tools and a voice agent that books appointments will end up with different lists.
Test planning
Turn each entry that applies into test cases with a clear pass or fail condition. In our attack testing we label every finding with its OWASP entry, so developers, managers and auditors can see which risks were covered. Our guide to AI red teaming, a structured attack test of an AI system, explains the method.
Vendor questions
When you buy an AI product or platform, ask how it handles the entries that matter to you. For example:
- Where are access rights checked before documents reach the model? (LLM02, LLM09)
- Which actions need human approval, and who can change that setting? (LLM03)
- Which spending caps apply, and do they stop processing? (LLM06)
- Are credentials kept out of prompts? (LLM08)
- How is output encoded before it reaches browsers, databases or email? (LLM10)
Limits of the OWASP Top 10 LLM list
- It is an awareness document, not a standard or a certification, and following it is not proof of compliance.
- The order reflects a community vote and incident data, not your risk. Rank the entries by what your own system can reach and do.
- It does not replace application and infrastructure security, privacy work or a penetration test of the system around the AI.
- Editions change. Check whether a vendor or a report uses the 2025 or the 2026 numbering.
The 2026 edition maps each entry to other frameworks, including MITRE ATLAS and NIST AI 600-1, which helps when you answer customer security questionnaires. To turn the list into launch controls, use our secure AI agent checklist. For an outside view, our AI security consulting team tests chatbots and agents against both OWASP lists, reports each finding with a fix and retests after you apply it.
Sources
- 1.OWASP Top 10 for LLM Applications 2026, OWASP GenAI Security Project, 2026-08-03 (opens in a new tab)
- 2.OWASP Top 10 for LLM Applications 2025, OWASP GenAI Security Project, 2024-11-18 (opens in a new tab)
- 3.OWASP Top 10 for Agentic Applications for 2026, OWASP GenAI Security Project, 2025-12-09 (opens in a new tab)
- 4.Poisoning Attacks on LLMs Require a Near-constant Number of Poison Samples, arXiv (Souly et al.), 2025-10-08 (opens in a new tab)
