OWASP Top 10 for LLM applications in a real product
OWASP's 2026 Top 10 for LLM applications in plain English: where each risk shows up in a real product, the first control to add, and the order to fix them.
Asghar Ali · Chief Technology Officer, Kakushin.io LTD
The OWASP Top 10 for LLM applications is the OWASP GenAI Security Project's ranked list of the ten biggest security risks in software built on large language models. The current edition is the 2026 one, published on 3 August 2026, and it runs from LLM01 Prompt Injection to LLM10 Improper Output Handling (OWASP GenAI LLM Top 10 2026, as of 27 October 2026). Each entry is a category of failure, not a single bug, and each comes with OWASP's own list of mitigations.
This essay is for the person building or commissioning an AI feature in a small SaaS: a chat assistant, a document summariser, search over your own data, or an agent that takes actions. For each of the ten risks it gives the plain-English version, the product feature where it usually shows up, and the first control I would add. The main table is in the order I would fix things in a small product with little time, not in list order, and I explain below why prompt injection, first on OWASP's list, sits seventh in mine.
What is the OWASP Top 10 for LLM applications?
It is an open, consensus list of the risk categories specific to applications built around a language model. The 2026 document's revision history shows version 1.0 on 1 August 2023, 1.1 on 16 October 2023 and the 2025 version on 18 November 2024, before this one (as of 27 October 2026).
The 2026 edition changed how the order was decided. The project leads' letter says the team classified 6,639 of 7,714 public incidents and checked the practitioner vote against them, with the vote carrying three-quarters of the weight. Two results stand out. Ranked by raw incident count, prompt injection falls out of the top ten; the leads read that as teams defending hard, and kept it first. Misinformation went the other way: low in the vote, high in the incidents.
The list also draws a boundary. It covers the model as a component inside your application. Once the model becomes an actor, with tools, memory between sessions and actions downstream, OWASP points you to its separate Top 10 for Agentic Applications, announced on 9 December 2025 (as of 27 October 2026).
What changed between the 2025 and 2026 lists?
The numbers moved and one entry was renamed. If a report or a customer questionnaire still uses the 2025 numbers, map them through this table.
| 2026 ID | Risk | 2025 ID |
|---|---|---|
| LLM01 | Prompt Injection | LLM01 |
| LLM02 | Sensitive Information Disclosure | LLM02 |
| LLM03 | Excessive Agency | LLM06 |
| LLM04 | Supply Chain | LLM03 |
| LLM05 | Data and Model Poisoning | LLM04 |
| LLM06 | Unbounded Consumption | LLM10 |
| LLM07 | Misinformation | LLM09 |
| LLM08 | Hidden Context Exposure | LLM07 (System Prompt Leakage) |
| LLM09 | Vector and Embedding Weaknesses | LLM08 |
| LLM10 | Improper Output Handling | LLM05 |
Sources: the 2025 list and the 2026 document, both read on 27 October 2026. The document calls Excessive Agency's climb to third the most consequential move.
The ten risks in the order I would fix them
The order below is a judgement for a small SaaS that calls a hosted model API, holds customers' data and has one or two engineers. It puts first the cheap controls that stop the worst outcomes: a runaway bill, one customer seeing another's data, and the model doing something nobody approved.
| Fix | Risk (2026 ID) | In plain English | Where it shows up | First control to add |
|---|---|---|---|---|
| 1 | Unbounded Consumption (LLM06) | Anyone who can reach the feature can spend your money or take it down. | A public "try it" box, a free tier, uploads with no size limit, large output budgets. | A hard spending cap that stops inference, plus per-user token and input size limits. |
| 2 | Hidden Context Exposure (LLM08) | Assume users can read your system prompt and anything else you put in the model's context. | A support bot whose prompt holds discount rules, internal notes, an API key or access logic. | Take credentials and security rules out of the prompt, and enforce them in code. |
| 3 | Sensitive Information Disclosure (LLM02) | The answer, the logs or the retrieved text hand data to someone who should not see it. | "Ask your workspace" search, a CRM-aware assistant, prompts and traces copied into a monitoring tool. | Check permissions before retrieval, send only the fields the task needs, scrub logs and traces. |
| 4 | Vector and Embedding Weaknesses (LLM09) | The search index behind the AI is a second database, often with weaker access rules. | Retrieval over a multi-tenant help centre or document store; a semantic cache shared across customers. | Apply the tenant and permission filter inside the index query, on the server, not after retrieval. |
| 5 | Excessive Agency (LLM03) | The model can do more than the feature needs, so a wrong or steered answer becomes a wrong action. | An assistant that sends email, issues refunds, edits records, fetches URLs or runs commands. | Remove tools the feature does not need, make the rest read-only where possible, run them with the user's permissions, and ask a human before anything irreversible. |
| 6 | Improper Output Handling (LLM10) | Model output goes into a browser, a query or a shell as if it were trusted. | Chat that renders Markdown or HTML, "ask your data" features that write SQL, generated code. | Treat output as untrusted input: encode it for where it lands, use parameterised queries, set a strict Content Security Policy. |
| 7 | Prompt Injection (LLM01) | Text the model reads can change what it does, whoever wrote that text. | Summarise this email, page, PDF or ticket; any tool output or memory the model reads. | List every place untrusted text reaches the model, and check that no such path can both reach private data and send data out. |
| 8 | Misinformation (LLM07) | Confident, wrong output is believed and acted on. | Answers about pricing, policy or account state; an agent that decides an invoice is paid. | Check the claim against the system of record before acting on it, and show users the source. |
| 9 | Supply Chain (LLM04) | The models, adapters, datasets and packages you depend on may change or not be what they claim. | An unpinned model version, open-weights models or adapters from a public hub, a package an assistant suggested. | Pin model versions, keep an inventory of models, adapters and datasets, and check suggested packages are real and intended. |
| 10 | Data and Model Poisoning (LLM05) | Bad data in the index or the fine-tune makes the system wrong in ways that look normal. | An index that ingests user uploads or web pages; a fine-tune on customer feedback. | Record the source and ingest time of everything indexed or trained on, so a bad batch can be found and rolled back. |
The risk names and the controls are condensed from each entry's mitigation section in the 2026 document (read 27 October 2026). The order and the product examples are mine.
Why start with the bill and the system prompt?
Both are cheap to fix and both fail badly. The 2026 Unbounded Consumption entry asks for spending caps that halt inference, not alerts a fast workload can outrun. On a reference app I built AI spend controls with a per-IP ledger and abuse heuristics; that ceiling is the first thing I would put in front of any public model endpoint. More on this in the security risks nobody checks in vibe-coded apps.
The Hidden Context Exposure entry tells developers to assume hidden context is discoverable and that nothing in it is a secret. Keys belong on the server, behind code the model cannot talk its way around. The principle predates AI: on the customer apps of a European national electricity utility I introduced a relay-proxy architecture that removed every client API key from the shipped binaries. A harmless check to add today: put a unique canary string in the system prompt and alert if it ever appears in a response log. It does not stop extraction, but it tells you it happened.
Why is prompt injection seventh, not first?
OWASP keeps it first, and rightly: the surface is everywhere a model reads text someone else wrote. But the 2026 entry itself says no reliable prevention mechanism exists today, and that defence is architectural rather than interceptive. So the controls that matter most for prompt injection are rows 3 to 6: what the model can read, reach and do once it has been steered.
The entry also cites Simon Willison's "lethal trifecta" as a pre-deployment check: a system that can read private data, take in untrusted content and communicate externally has the conditions for a serious incident, and removing any one leg removes them. That is row 7. Input filters still help, but the entry notes they can be evaded by rephrasing or encoding: a speed bump, not a wall.
Where does NIST AI 600-1 fit?
NIST AI 600-1, the Generative AI Profile of the AI Risk Management Framework (July 2024, as of 27 October 2026), lists 12 risks that generative AI creates or makes worse. Four overlap with this table: Information Security, which names prompt injection and data poisoning; Data Privacy; Confabulation, NIST's term for confidently stated but false output; and Value Chain and Component Integration. The 2026 OWASP document has an appendix mapping each entry to NIST AI 600-1: start there when an enterprise customer asks how your controls line up.
A worked example (illustrative)
This example is invented to show the method; it is not a client case. A ten-person company sells helpdesk software and adds an assistant that answers customers from the help centre, summarises incoming tickets and lets support agents issue refunds up to a set amount. Two engineers have one sprint. Walking the table:
- Cost. A monthly cap at the provider and in the app, a per-account token limit and a maximum upload size.
- The prompt. It holds the refund thresholds and a token for the billing service. The token moves into a server-side refund tool, and the refund limit is enforced in the billing code, not in the prompt.
- Retrieval. Every customer's private help articles sit in one index, filtered after retrieval. The tenant filter moves into the query.
- Tools. Ticket text is written by anyone on the internet, so the summariser gets no tools at all. The refund tool exists only in the agent-facing assistant, runs with the agent's own permissions, and needs a human click to confirm.
- Output. Answers render as plain text or sanitised Markdown, under a Content Security Policy.
- Claims. Before a refund, the tool checks order status in the billing system instead of trusting the model's summary of it.
- Provenance. The model version is pinned, and every document in the index carries its source and ingest time.
Most of this is permissions and limits the stack already has, applied to one more caller.
What this cannot tell you
- The list is not a test plan or a pass mark. Ticking ten rows does not mean a feature is free of these risks.
- It does not know your product. A feature with no tools and no private data has a very different top three from an agent with access to email and payments.
- Agents need more. Tools, memory and multi-agent hand-offs are covered more fully by the Agentic list.
- My order is a judgement. A team that fine-tunes its own models should move rows 9 and 10 up.
- It sits on top of the basics. Authorisation, secrets and patching still come first; I listed those in application security best practices. If your stack includes PHP, the PHP2Shell checker is a quick look at whether a site announces a vulnerable version.
FAQ
What is the OWASP Top 10 for LLM applications?
It is the OWASP GenAI Security Project's ranked list of the ten main security risks in applications built on large language models. The current edition, 2026, was published on 3 August 2026, with mitigations for each entry.
What changed in the 2026 version?
Excessive Agency rose to third, Unbounded Consumption rose four places, Improper Output Handling fell from fifth to tenth, and System Prompt Leakage became Hidden Context Exposure. The ranking now blends the practitioner vote with real incident data.
Which risk should a small team fix first?
Start where the damage is fastest and the fix cheapest: a hard spending cap and per-user limits, then credentials and access rules out of the system prompt, then permission checks before retrieval. Then limit what the model's tools can do.
Can prompt injection be fully prevented?
Not today, according to the 2026 OWASP entry, because models do not separate instructions from data. Design for the day it succeeds: limit what the model can read and do, keep credentials in code, and make sure no single path lets untrusted text reach private data and send it out.
Does the LLM Top 10 cover AI agents?
Partly. It covers the model as a component of your application, including Excessive Agency. When the model acts on its own with tools and memory, OWASP says to pair it with its Top 10 for Agentic Applications, announced on 9 December 2025.
If you want this checked
I review AI features against this list: prompt-injection, tool-permission and data-leak tests on LLM features, a source review, and a written fix list in the order above. The scope is on my hire page. If you would rather start with the code than the feature, a source code audit covers the wider application, and what a human still has to check when a model writes the code covers the review side.