The OWASP Top 10 for LLM Applications is the industry's shared list of the ten failures that most often appear in applications built on large language models. OWASP is the foundation that has published the equivalent list for web applications since 2003, and its generative AI project issued the first LLM list in 2023, a second in 2025 and the current edition in August 2026. Its value is a shared vocabulary, and completeness has nothing to do with it, because no list of ten ever is. A product manager, an engineer and a security reviewer can name the same failure and mean the same thing by it.
The sections below say what the 2026 edition changed and how it was built, give the ten in order, explain the moves worth understanding, and end with how the list is used and where it stops.
What the 2026 edition changed
The 2026 edition was the first to be influenced by real incidents. A community vote still carried three quarters of the weight, and the remaining quarter came from analysis of more than six thousand incidents drawn from public vulnerability databases and a database of AI harms. It carries the largest reordering since the list began. That reordering is the interesting part. A category that moves three places says that the systems being built have changed shape, which is a statement about a team's roadmap as much as about its 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
Four moves carry most of the meaning.
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 it. The bill does it for them.
Improper Output Handling fell from fifth to tenth, and the fall is no 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, memory, earlier turns and identifiers nobody thought of as content.
How the list is used and where it stops
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 somebody write LLM03 in a ticket and have a security reviewer understand the risk without a meeting.
The limit is that it describes categories, and it says nothing about a particular system. It cannot say which of the team's 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 the team's own architecture, and the list only says which questions to put to it.
Practise this
The exercise needs one feature 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 the team would have written itself.
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.
What to look for. The rows the team disagrees with are the useful ones, because a disagreement means an assumption is being held that has never been written down. Most attention goes to any category the model calls reachable that had already been ruled out. In most designs that gap sits in the tool list and rarely in the prompt.
Done honestly, the exercise shows that the list is a generator of questions about a team's own architecture, and it supplies no answers about it.