OWASP maintains a list of the ten failures that most often appear in applications built on large language models. Its value is not that it is complete, because no list of ten ever is. Its value is that a product manager, an engineer and a security reviewer can name the same failure and mean the same thing by it.
What the 2026 edition changed
The 2026 edition was built on analysis of thousands of reported incidents rather than on a survey of expert opinion, and it carries the largest reordering since the list began. That reordering is the interesting part. A category that moves three places is telling you the systems being built have changed shape, which is a statement about your roadmap as much as about your security posture.
The ten, in the 2026 order
- LLM01 Prompt Injection. Untrusted text that the model acts on as instruction.
- LLM02 Sensitive Information Disclosure. The system returning data the requester should never see.
- LLM03 Excessive Agency. A system permitted to act more widely than the feature needs.
- LLM04 Supply Chain. Compromised models, adapters, datasets or libraries brought in from elsewhere.
- LLM05 Data and Model Poisoning. Planted material in training data or in a retrieval index.
- LLM06 Unbounded Consumption. Requests that burn compute, quota or money without limit.
- LLM07 Misinformation. Confident output that is wrong, and a workflow that trusts it.
- LLM08 Hidden Context Exposure. Leakage of the instructions and material the application quietly holds.
- LLM09 Vector and Embedding Weaknesses. Attacks aimed at the retrieval layer itself.
- LLM10 Improper Output Handling. Model output passed to something that renders or executes it.
The moves worth understanding
Excessive Agency rose from sixth to third, which OWASP describes as the most consequential move in the edition. Models did not become more dangerous. Products did, because they stopped producing text for a person to read and started carrying out multi step work through tools. A wrong answer in a chat window is an annoyance and a wrong action against a payments system is an incident.
Unbounded Consumption rose from tenth to sixth. Once a single user request can fan out into a long chain of model calls, an attacker no longer has to take the service down to hurt you. The bill does it for them.
Improper Output Handling fell from fifth to tenth, and the fall is not a reprieve. It moved because teams largely learned to escape and validate what comes back before rendering or running it, which is what a category looks like once its control has become routine.
System Prompt Leakage was renamed Hidden Context Exposure, and widened at the same time. The concern was never only the system prompt. It is everything an application holds in the window around it, including retrieved documents, tool results, earlier turns and identifiers nobody thought of as content.
Using it, and its limit
Two uses justify the list. As a checklist during threat modelling it forces a team to consider ten failure modes it would not have generated on its own, which is worth an hour of any design review. As shared vocabulary it lets you write LLM03 in a ticket and have a security reviewer understand the risk without a meeting.
The limit is that it describes categories rather than your system. It cannot tell you which of your tools is irreversible, which retrieval source accepts content from outside the company, or which action runs without a person seeing it. Those answers come from your own architecture, and the list is only what tells you which questions to put to it.
Practise this
You need one feature of your own that calls a model, and an ordinary chat client.
Describe the feature in four lines, ask a model to walk it against the list, then compare the answer with the mapping you would have written yourself.
Here is a feature I built. Assess it against the 2026 OWASP Top 10 for
LLM Applications.
Input: where the text comes from, and who controls that source
Context: what my application adds, including any retrieved documents
Tools: every call the model can make, and what each one can change
Output: where the answer goes next, and what consumes it
For each of the ten categories, say whether it is reachable in this
design and name the exact step that makes it reachable or not. Where a
category does not apply, say why in one line. Do not soften anything,
and do not suggest fixes yet.
```text
**What to look for.** The rows you disagree with are the useful ones, because a
disagreement means you are holding an assumption you have never written down.
Pay most attention to any category the model calls reachable that you had
already ruled out. In most designs that gap sits in the tool list rather than
in the prompt.
Done honestly, the exercise shows that the list is a generator of questions
about your own architecture rather than a set of answers about it.