OWASP Top 10 for LLM Applications

The list first appeared in August 2023, was revised as version 1.1 that October, and was substantially rewritten for the 2025 edition released in November 2024 — the edition people mean when they cite it now. The ten entries are LLM01 prompt injection, LLM02 sensitive information disclosure, LLM03 supply chain, LLM04 data and model poisoning, LLM05 improper output handling, LLM06 excessive agency, LLM07 system prompt leakage, LLM08 vector and embedding weaknesses, LLM09 misinformation, and LLM10 unbounded consumption.

What changed between the editions is more informative than the list itself, because each change records something the field learned. Training data poisoning widened into data and model poisoning once fine-tuning and adapter supply chains became ordinary. Model denial of service widened into unbounded consumption, because the failure teams actually meet is a runaway cost and quota failure rather than an availability one. Insecure plugin design and model theft disappeared as standalone entries and were folded into supply chain, excessive agency and unbounded consumption. Overreliance became misinformation, moving the emphasis off the user’s psychology and onto the output. Three entries are new — system prompt leakage, vector and embedding weaknesses, and misinformation — and all three arrived because retrieval-augmented architecture became the default between the two editions.

How to read it matters. It is a risk register, not a control set: each entry describes a class of failure and suggests mitigations, and none of them is a requirement you can pass or fail. Two of the ten sit outside anything a runtime control can reach — LLM04 happens inside a training pipeline, and LLM08 presupposes a retrieval layer — which is why a vendor mapping with something in all ten rows should be read sceptically rather than favourably. The list’s real value is that it is the register a security reviewer already has open, which makes it the fastest shared vocabulary for describing the shape of a control’s coverage, on the condition that the empty rows are published beside the full ones.

Three entries behave differently from their web-application analogues and are worth understanding individually. LLM01 has no complete fix: detection is heuristic, an attacker gets unlimited attempts against a fixed set of patterns, and novel phrasing and non-English payloads evade pattern scoring — so the layer that carries the weight is not the detector but what a successful injection can reach, which means deny-by-default grants, approvals bound to the exact payload, and egress controls that hold whether or not the scanner fired. LLM06 is an authorisation problem in AI costume: the unit that matters is the action rather than the system, and an agent granted a whole API has been granted every endpoint in it. LLM02 is a data-loss problem whose novel half is the response channel, because a model can emit an identifier nobody ever sent it, so scanning only the request misses the case that is hardest to explain afterwards.

The same project publishes siblings that are frequently confused with it. There is an agentic list, the Top 10 for Agentic Applications, using ASI-prefixed identifiers for goal hijack, tool misuse and privilege compromise, agentic supply chain including tool poisoning and rug pulls, memory and context poisoning, cascading failures, insufficient oversight and rogue agents, together with a threat-and-mitigation taxonomy that adds repudiation and the overwhelmed human reviewer. There is also a governance checklist and a set of security guides. And it is an entirely different project from the OWASP Top 10 for web applications, with a different method: the web list is derived from contributed, CWE-tagged testing data across hundreds of thousands of applications, while the LLM list is expert-voted. That is a defensible choice for a field with no comparable corpus, and it is also a real limit on how much the ordering should be taken to mean.