OWASP Top 10 for LLM Applications
The OWASP Top 10 for LLM Applications names the failure modes that break AI in production, from prompt injection to excessive agency and unbounded consumption.
The OWASP Top 10 for LLM Applications names the ten failure modes most likely to break an AI application in production — prompt injection, sensitive information disclosure, supply chain compromise, data and model poisoning, improper output handling, excessive agency, system prompt leakage, vector and embedding weaknesses, misinformation, and unbounded consumption. It is the most practical of the AI frameworks because it names concrete engineering defects rather than governance obligations.
The current list is the 2025 edition, version 2.0, published on 18 November 2024 by the OWASP GenAI Security Project.
The OWASP Top 10 for LLM Applications
- LLM01 Prompt Injection — Crafted input overrides intended instructions, directly or through content the model reads.
- LLM02 Sensitive Information Disclosure — The model reveals training data, secrets or other users’ information.
- LLM03 Supply Chain Vulnerabilities — Compromised third-party models, datasets, adapters or plugins.
- LLM04 Data and Model Poisoning — Corrupted training or fine-tuning data changes model behaviour.
- LLM05 Improper Output Handling — Model output is passed to another system without validation, enabling injection downstream.
- LLM06 Excessive Agency — The model holds more permissions or autonomy than the task requires.
- LLM07 System Prompt Leakage — The system prompt is extracted, exposing logic or credentials placed in it.
- LLM08 Vector and Embedding Weaknesses — Flaws in RAG pipelines, embeddings and vector stores, including retrieval poisoning.
- LLM09 Misinformation — Confident, wrong output that users act on. Absorbs the former Overreliance category.
- LLM10 Unbounded Consumption — Uncontrolled resource use, from denial of service to runaway inference cost.
How the 2025 edition differs from the first list
The revision reflects the shift from chat-only applications to agentic, retrieval-augmented systems. Three categories are new: System Prompt Leakage, Vector and Embedding Weaknesses, and Unbounded Consumption, the last expanded from the narrower Model Denial of Service entry. Misinformation absorbed the former Overreliance category. Insecure Plugin Design and Model Theft are no longer standalone entries, with their concerns distributed into Supply Chain and Excessive Agency. The direction of travel is clear: the risks that matter now come from what the model is connected to, not just what it says.
The AI Security and Privacy Guide
The Top 10 is the best known output, but OWASP also publishes the AI Security and Privacy Guide, which is broader and aimed at the program rather than the application. It covers designing, building, testing and procuring AI systems, and makes a point most AI security material skips: much of the work is ordinary application security applied to a new development activity, not a separate discipline.
Its security half addresses data security, model attacks, code maintainability and supply chain complexity, and argues for folding data scientists and their pipelines into the existing security program rather than treating them as an exception. Its privacy half works through use limitation, data minimisation, fairness, transparency, consent, data accuracy and privacy rights as they apply to model training and inference — the questions that decide whether a system can lawfully use the data it was built on.
How OWASP fits with the other frameworks
OWASP tells engineers what to build and what to test. It does not tell you how to run a risk program, which is NIST AI RMF, or how to structure an auditable management system, which is ISO/IEC 42001. It pairs naturally with MITRE ATLAS: ATLAS describes what attackers do, OWASP describes what to do about it. Several entries map directly onto documented incidents, including the Slack AI exfiltration attack, which combines LLM01, LLM02 and LLM08.
Our take
We are long-standing supporters of OWASP and have used the original Top 10 to test and secure systems for years. It remains a key reference in our AI security library, and it is the framework we reach for first when the question is engineering rather than governance.
Related frameworks
OWASP AI covers build-time practice. For the attacker behaviour it defends against, see MITRE ATLAS. For the management system that governs the wider program, see ISO/IEC 42001. For how all five frameworks relate, see the AI security framework comparison. For the attack classes in context, see AI attacks.
Frequently asked questions
What is prompt injection?
Prompt injection is LLM01, the top entry on the list. Crafted input causes a model to follow instructions other than the ones its developer intended. Direct injection comes from the user; indirect injection is hidden in content the model reads — a web page, a document, a message in a channel — which makes it far harder to defend, because the attacker never touches your application.
Is the OWASP Top 10 for LLM Applications a compliance standard?
No. It is community-produced guidance, not a standard, and there is nothing to certify against. Its value is engineering: it gives teams a shared vocabulary for AI failure modes and a test checklist. For auditable structure, ISO/IEC 42001 is the standard; for regulatory obligation, the EU AI Act is the law.
How is the OWASP Top 10 for LLM different from the original OWASP Top 10?
They are separate lists. The original OWASP Top 10 covers web application risks such as broken access control and injection. The LLM list covers failure modes specific to language model applications. A team shipping an AI feature needs both, since an LLM application is still a web application underneath.
How does OWASP differ from MITRE ATLAS?
ATLAS catalogues attacker tactics and techniques observed against AI systems — it is a threat model. OWASP catalogues the weaknesses that let those attacks succeed and what to do about them — it is a defence checklist. Used together, ATLAS tells you what you are defending against and OWASP tells you what to fix.
Related references
What is AI security?
AI security protects models, training data and AI pipelines from attack. It covers adversarial inputs, data poisoning, model theft and prompt injection.
Choosing an AI security assessment framework
Compare AI security assessment frameworks: NIST AI RMF, ISO/IEC 42001, MITRE ATLAS and OWASP each answer a different question. Pick by what you need.
EU AI Act
The EU AI Act has applied in general since 2 August 2026, and the Digital Omnibus pushed high-risk duties to December 2027. Here is what binds now.