OWASP Top 10 for LLM Applications: The 2025 List Explained

The OWASP Top 10 for LLM Applications is the reference list security teams use to scope risk in any product built on large language models, and the 2025 edition reshuffled it meaningfully from the first 2023 release. Two new categories arrived, several entries were renamed or merged, and the ordering shifted to reflect what teams actually saw in production over the prior year. This is a category-by-category walkthrough of the current list, what each risk means in practice, and the controls that address it.

The list is maintained by the OWASP Gen AI Security Project, a community effort distinct from the long-running OWASP Top 10 for web applications. It targets the LLM-specific attack surface: the model, its prompts, its training and retrieval data, and the agentic plumbing wired around it.

The 2025 list, item by item

LLM01:2025 Prompt Injection. Untrusted input that overrides the model’s instructions, either directly through user text or indirectly through content the model retrieves (a web page, a document, an email). It holds the top spot for the second edition running. Direct and indirect injection are the dominant initial-access technique against LLM apps, and the offensive mechanics are covered in depth on aisec.blog. Mitigations are imperfect: input and output filtering, privilege separation between the model and downstream tools, and treating all model output as untrusted.

LLM02:2025 Sensitive Information Disclosure. The model leaks PII, secrets, proprietary data, or other content it should not surface. This jumped from sixth in 2023 to second, reflecting how often training data, system context, and retrieved documents bleed into responses. Controls include data minimization in training and retrieval corpora, output scrubbing, and strict access control on what the model can read.

LLM03:2025 Supply Chain. Compromise of third-party models, datasets, plugins, or libraries. Pulling a poisoned model off a public hub, or depending on a tampered fine-tuning dataset, falls here. Model provenance, signature verification, and software bills of materials for the ML stack are the relevant defenses.

LLM04:2025 Data and Model Poisoning. Manipulation of training, fine-tuning, or embedding data to introduce backdoors, biases, or degraded behavior. Poisoning can be triggered at pre-training, fine-tuning, or through the retrieval corpus. Provenance tracking, anomaly detection on training data, and robust evaluation against held-out sets reduce exposure.

LLM05:2025 Improper Output Handling. Insufficient validation of model output before it flows into downstream systems. If a model’s response is passed unsanitized into a shell, a SQL query, a browser, or a templating engine, you inherit classic injection vulnerabilities (XSS, SSRF, command injection) with the LLM as the conduit. Treat output as you would any untrusted user input: encode, parameterize, and validate.

LLM06:2025 Excessive Agency. An LLM granted too much functionality, permission, or autonomy, so that a manipulated model can take damaging actions. As agentic systems with tool-calling proliferate, this risk grows. The fix is least privilege: scope each tool tightly, require human approval for high-impact actions, and avoid open-ended capabilities.

LLM07:2025 System Prompt Leakage. A new entry for 2025. It addresses the assumption that system prompts are secret and the harm when they leak — exposed instructions, embedded credentials, or filtering logic that an attacker can then evade. The lesson is to never place secrets or sole authorization controls in the system prompt.

LLM08:2025 Vector and Embedding Weaknesses. Another reflection of the RAG era. Risks in how embeddings are generated, stored, and retrieved: data leakage across tenants in a shared vector store, embedding inversion, and poisoned retrieval results. Access control on the vector database and validation of retrieved context are the core controls. Monitoring drift and integrity of retrieval pipelines is an MLOps concern covered at sentryml.com.

LLM09:2025 Misinformation. Misinformation absorbed the former “Overreliance” category. It covers false or misleading output, compounded by users trusting it without verification — confident hallucination that causes real harm in legal, medical, and financial contexts. Retrieval grounding, citation requirements, factual-accuracy evaluation, and human review for high-stakes outputs are the recommended mitigations.

LLM10:2025 Unbounded Consumption. Unbounded Consumption broadened the old “Model Denial of Service” entry. It now spans denial-of-service through expensive prompts, denial-of-wallet via runaway API costs, and model extraction through high-volume querying. Rate limiting, per-user quotas, input size caps, and cost monitoring keep it in check.

What changed from 2023

Three shifts matter most. First, the list moved decisively toward agentic and retrieval architectures: System Prompt Leakage and Vector and Embedding Weaknesses are both new, and Excessive Agency climbed in prominence. Second, several 2023 entries were renamed or merged to remove overlap — “Overreliance” folded into Misinformation, and “Model Denial of Service” expanded into Unbounded Consumption. Third, Sensitive Information Disclosure rose sharply, acknowledging how frequently data leakage shows up once an LLM is wired into real systems.

The reordering is not arbitrary. The project bases it on community feedback and observed incidents, so the rank is a rough proxy for how often and how severely each category bites teams in production.

Prioritizing the list for a real deployment

The list is ranked by the project’s read of community feedback and observed incidents, which is a reasonable global prior and a poor substitute for your own context. For the common case — a production application on a commercial model API, no fine-tuning of your own, retrieval in the mix — a defensible working order looks like this:

1. Prompt Injection (LLM01). Immediate. Documented operational exploitation, no complete defense, and it is the entry point for most of the others.
2. Sensitive Information Disclosure (LLM02). Immediate if any PII or proprietary data sits in system prompts or retrieval context. Data minimization in the corpus does more here than output scrubbing.
3. Improper Output Handling (LLM05). Weight it by what your downstream systems actually do with the output. A response rendered as plain text is a different problem from one that reaches a shell, a SQL layer, or a templating engine.
4. Supply Chain (LLM03) and Data and Model Poisoning (LLM04). Medium for pure API consumers, high the moment you run open-weight models or fine-tune on third-party data. Pin and hash ML dependencies, verify model checksums, and audit fine-tuning dataset provenance.
5. Excessive Agency (LLM06). High priority the moment you build agents, and close to irrelevant before that. This is the risk that scales directly with the capability you grant.
6. Unbounded Consumption (LLM10). Rate limiting, per-user quotas, and query-pattern monitoring cover both the cost-exhaustion and the model-extraction halves of the category, and neither control is consistently implemented in practice.

Two categories are routinely underweighted. Misinformation (LLM09) is as much product design as security: uncertainty communicated in the interface, citations on factual claims, and honest calibration of where the model is reliable do more than any filter. And Vector and Embedding Weaknesses (LLM08) is easy to skip right up until the retrieval corpus turns out to be writable by more parties than anyone enumerated.

Putting the list to work

The Top 10 is a scoping tool, not a checklist that guarantees security. It is most useful as a framework for structuring a conversation about risk coverage, and most misleading when treated as a deployment checklist that can be signed off. A practical way to apply it: map each category to your architecture, mark which are in scope (a RAG chatbot with no tool-calling can largely deprioritize Excessive Agency but must take Vector and Embedding Weaknesses seriously), then assign a concrete control and an owner to each in-scope item.

Several categories map directly to a defensive guardrail layer — input and output filtering for prompt injection, content validation for improper output handling, and policy enforcement for excessive agency. Tooling for that layer is surveyed at guardml.io. The remainder, particularly supply chain and poisoning, are governance and pipeline-integrity problems that sit with the MLOps and platform teams rather than the application layer.

None of the ten have a single silver-bullet fix. Prompt injection in particular remains an open research problem with no complete defense. The value of the framework is that it forces a structured review of the full LLM attack surface rather than the one or two risks that happen to be top of mind.

The list also composes with the other two references worth having open. MITRE ATLAS supplies the adversary technique catalog, the OWASP Top 10 supplies the application risk checklist, and a governance framework wraps both in a structure auditors recognize. That division of labour — including where ISO/IEC 42001 and the EU AI Act sit relative to both — is set out side by side in AI security frameworks compared. To keep these categories in front of you week to week, the personalized AI-Sec digest builder filters our tagged coverage down to the OWASP LLM categories you actually deploy against.