The OWASP Top 10 for LLM Applications, Explained

The OWASP Top 10 for LLM Applications is the reference list of security risks specific to systems built on large language models, published by the OWASP Gen AI Security Project. The current version is the 2025 list, and it covers the failure modes that conventional application security testing does not reach: 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. If your company has shipped anything with an LLM in it, a chatbot, a RAG pipeline, an agent, this list is the starting scope for securing it. What follows is each risk in plain terms, and how the ten fit together into a testable attack surface.

The list, and what each risk means

The 2025 list, in OWASP's order:

• LLM01 Prompt Injection. Attacker-controlled text changes the model's behavior. Direct injection comes through the user's own input; indirect injection hides instructions in content the model reads, a web page, a document, an email. This has been the top risk in every version of the list, because no reliable general defense exists.
• LLM02 Sensitive Information Disclosure. The model reveals data it should not: PII from training or context, credentials, proprietary prompts, other users' data pulled through a shared retrieval layer.
• LLM03 Supply Chain. Compromise arrives through what you build on: poisoned base models and adapters from public hubs, malicious packages, and untrusted plugins or MCP servers granted real permissions.
• LLM04 Data and Model Poisoning. An attacker corrupts training, fine-tuning, or embedding data so the model misbehaves on cue, including backdoors that activate on specific triggers.
• LLM05 Improper Output Handling. Downstream code trusts model output. LLM-generated text that flows unvalidated into a SQL query, a shell command, or rendered HTML turns the model into an injection vector for classic exploits.
• LLM06 Excessive Agency. The model has more tools, permissions, or autonomy than its task needs, so a manipulated model can take real actions: sending mail, moving money, changing records.
• LLM07 System Prompt Leakage. The instructions and secrets embedded in the system prompt get extracted, exposing logic an attacker can then work around, and any credentials someone unwisely put there.
• LLM08 Vector and Embedding Weaknesses. The RAG layer is attacked directly: poisoned documents in the corpus, embedding inversion that recovers source text, and retrieval that ignores per-user access controls.
• LLM09 Misinformation. The system asserts false things convincingly, hallucinated facts, fabricated citations, unsafe code suggestions, and users act on them.
• LLM10 Unbounded Consumption. Nothing limits how much the system will do: denial-of-wallet through expensive queries, resource exhaustion, and model extraction through high-volume querying.

How the ten fit together

The list reads better as a map of trust boundaries than as ten separate problems. Everything the model reads is one boundary: user input, retrieved documents, tool results, and web content are all instruction channels, which is why prompt injection and system prompt leakage travel together, and why our deep dive on prompt injection treats every input as potentially adversarial. Everything the model knows is a second boundary: training data, fine-tuning sets, and the vector store, which is where poisoning and embedding weaknesses live. Retrieval pipelines concentrate this risk enough that we cover RAG security separately. Everything the model can do is the third boundary: output handling and excessive agency are both failures to constrain the blast radius of a model that has been successfully manipulated, and they matter most in agentic systems, covered in our guide to securing AI agents.

Framed that way, the practical question for any LLM application is three questions. What can reach the model's context, and does anything untrusted reach it? What did the model learn from, and who could have written to those sources? What happens when the model is wrong or hostile, and what is the worst action it can complete before a human or a control intervenes?

Why traditional testing misses these

A conventional web application pentest exercises the application around the model: authentication, session handling, APIs, infrastructure. All of that still applies to LLM applications and still needs testing. What it does not exercise is the model as an attack surface. Prompt injection has no CVE and no signature; it is a property of how the system composes untrusted text into context, and it changes every time the prompt, the tools, or the retrieval corpus changes. Scanner-based approaches fare worse, because the vulnerable behavior is probabilistic: the same payload can fail nine times and land on the tenth.

Testing LLM applications means adversarial exercises against the model boundaries themselves: injection payloads through every input channel including retrieved documents, extraction attempts against the system prompt and the vector store, tool-abuse chains that test whether excessive agency exists in practice, and consumption attacks against rate and budget limits. It also means re-testing on a cadence, because model version bumps and prompt changes silently reopen closed findings. The OWASP list functions well as the scoping document for that work, which is exactly how we use it.

Controls that pay for themselves

Across the ten risks, a handful of architectural decisions do most of the defensive work. Least privilege for the model: tools scoped to the task, credentials scoped to the user on whose behalf the model acts, and no permission the workflow does not require. Treat model output as untrusted input everywhere it lands, with the same encoding and parameterization discipline any user input gets. Enforce access controls at retrieval time, per requesting user, instead of trusting the corpus. Pin and verify everything in the model supply chain. Put budgets and rate limits on inference. And for consequential actions, keep a human approval step in the loop, because it converts a full compromise into a logged request.

Detection deserves its own line item, because prevention against these risks is probabilistic and something will eventually get through. Log the full prompt and response for any interaction that triggers a consequential action, so incidents can be reconstructed. Alert on anomalies that map to the list: token consumption spikes for unbounded consumption, repeated near-identical queries for extraction attempts, and tool-call patterns that deviate from the workflow's normal shape for agency abuse. Most teams that suffer an LLM incident discover they cannot answer the first investigative question, which is what exactly the model was told.

None of this is exotic. It is the standard security playbook, applied to a component that reads instructions out of data and acts on them. The teams that struggle are the ones that treat the model as either fully trusted, which loses to the first injection, or as a black box outside their threat model, which loses to everything else.

Where the list fits in a compliance program

The Top 10 is a technical risk taxonomy, and it slots cleanly into the governance frameworks companies are now being asked about. ISO 42001 requires an AI risk assessment and treatment plan; the ten risks are a defensible starting register for any LLM system in scope. The NIST AI Risk Management Framework's Measure and Manage functions expect exactly the kind of adversarial testing described above, and buyers running AI vendor reviews increasingly ask for evidence of it by name. Security questionnaires have begun citing the OWASP LLM list the way they have cited the web application Top 10 for two decades. Teams that map their controls to it once, and keep the test results, answer those questionnaires from a document instead of from scratch each time. The list also gives engineering and compliance a shared vocabulary, which is worth more than it sounds: an auditor's "AI risk" and an engineer's "indirect injection through the retrieval corpus" finally point at the same finding.

Where to start

Inventory your LLM applications, including the ones embedded in vendor products, and map each against the three boundaries above. Prioritize the systems where untrusted input meets real permissions, because that intersection is where excessive agency and injection combine into actual incidents. Then test adversarially and fix in order of blast radius. BD Emerson's agentic AI security practice runs exactly this work, from threat modeling LLM architectures through hands-on adversarial testing mapped to the OWASP Top 10, and the findings consistently justify the exercise: most production LLM applications we test have at least one path where untrusted content can trigger an action nobody intended. The list gives you the vocabulary and the scope. The security comes from testing against it before someone else does.