OWASP Top 10 for LLM Applications Explained (2026)

Building on an LLM opens a category of security holes that classic web security checklists never anticipated. A model cannot tell your instructions apart from an attacker’s hidden ones, it will happily take an action you granted it “just in case,” and it can leak the very prompt that governs it. The OWASP Top 10 for LLM Applications is the field’s shared map of these risks - and this is a plain-English walkthrough of all ten, with how eval and guardrail tools actually help on each.

What the list is, and what it is not

The OWASP Top 10 for LLM Applications is a community-driven list, maintained by the OWASP GenAI Security Project, of the most critical security risks specific to LLM-powered software. It is not the classic OWASP Top 10 for web apps - that one covers general risks like broken access control. This one covers problems that exist only because of how language models work. You need both; this post is about the LLM-specific list, in its 2025 edition.

The ten risks in plain English

LLM01 - Prompt Injection. An attacker crafts input that overrides your instructions, either directly in the user message or indirectly through content the model later reads, like a web page or uploaded document. It is number one because the model cannot cleanly separate trusted instructions from untrusted data in one context window. This is the deepest problem on the list - we cover detection in depth in how to detect prompt injection, and the concept itself in the prompt injection glossary entry.

LLM02 - Sensitive Information Disclosure. The model reveals data it should not - PII, secrets, proprietary content - either from its training data or from context passed at runtime. Example - a support bot echoes another customer’s order details that leaked into its context.

LLM03 - Supply Chain. Risks in the components you build on - a compromised base model, a poisoned fine-tune, a malicious package, or a model pulled from an untrusted hub. You inherit the vulnerabilities of everything upstream.

LLM04 - Data and Model Poisoning. An attacker corrupts training or fine-tuning data to plant a backdoor or bias. Example - poisoned examples that make the model behave normally except on a specific trigger phrase.

LLM05 - Improper Output Handling. Treating model output as trusted before passing it downstream. If your app pipes an LLM’s text straight into a shell, SQL query or eval, the model - or an injection through it - can execute code. The fix is old-fashioned - validate and sanitize model output exactly as you would any untrusted input.

LLM06 - Excessive Agency. Giving the model too much power - tools, permissions or autonomy beyond what the task needs. An agent with delete access that only needed read access can do real damage when it misfires or is manipulated. This is why tool-call accuracy and least-privilege tool design matter for safety, not just correctness.

LLM07 - System Prompt Leakage. The model reveals its own system prompt, exposing instructions, guardrail logic or embedded secrets an attacker can then work around. The deeper lesson - never put anything you need to keep secret in the system prompt.

LLM08 - Vector and Embedding Weaknesses. Risks in the RAG layer - a poisoned document in your vector store, embedding inversion that reconstructs source text, or retrieval that pulls in data a user should not see. Your retrieval pipeline is an attack surface.

LLM09 - Misinformation. The model produces confident, plausible falsehoods - hallucinations - that users act on. Unlike the others this is often not an attacker but the model’s own tendency to make things up, which is why measuring and reducing it is a security concern, not only a quality one.

LLM10 - Unbounded Consumption. Unchecked resource use - runaway token spend, denial-of-wallet attacks, or an agent that loops forever. An attacker who can trigger expensive generations can run up your bill or take the service down.

How eval and guardrail tools map to the risks

The list is only useful if you can test against it. Two complementary defenses:

• Red-teaming (find the holes before ship). Promptfoo is the de-facto open-source eval and red-teaming CLI - it ships built-in OWASP LLM Top 10, OWASP Agentic and NIST presets with 50-plus attack plugins, is MIT-licensed with no seat cost, and runs in CI. DeepEval’s DeepTeam framework covers 50-plus vulnerabilities and 20-plus attack vectors and is Apache-2.0. Both let you turn “are we exposed to LLM01” into a test that fails the build when a regression reopens it.
• Runtime guardrails (block attacks in production). Static tests catch known attacks; guardrails catch them live. Portkey is an open-source gateway with 50-plus integrated guardrails plus budgets and rate limits - the rate limits and spend caps map directly onto LLM10, and the input and output guardrails onto LLM01 and LLM05. The broader landscape is in the best LLM guardrails tools and the guardrails glossary entry.

Risk	Primary defense
LLM01 Prompt Injection	Guardrails + red-team probes
LLM05 Improper Output Handling	Output validation before downstream use
LLM06 Excessive Agency	Least-privilege tools + tool-call evals
LLM09 Misinformation	Faithfulness / hallucination evals
LLM10 Unbounded Consumption	Rate limits + spend caps

No single tool covers all ten - the practical posture is red-team scans in CI plus runtime guardrails plus least-privilege design, layered.

Common mistakes

• Confusing it with the web OWASP Top 10. They are separate lists - you need both for an LLM app.
• Treating the system prompt as secret storage. LLM07 means assume it can leak - keep secrets out of it.
• Trusting model output blindly. LLM05 turns a helpful model into a code-execution path if you skip validation.
• Over-permissioning agents. LLM06 is a design choice - grant only the tools and scopes the task needs.

The bottom line

The OWASP Top 10 for LLM Applications names the risks that are unique to building on language models, and the working defense is layered - red-team against them in CI with Promptfoo or DeepEval, block them at runtime with guardrails in a gateway like Portkey, and design agents with least privilege. Start with the number-one risk in how to detect prompt injection, then widen out to the full list.