OWASP Top 10 for LLM Applications

Definition

The OWASP Top 10 for LLM Applications is a community-maintained list of the most critical vulnerability classes in applications built on large language models, published by the OWASP GenAI Security Project and revised periodically as the ecosystem changes.

Scope

Any application built on a large language model — chat interfaces, retrieval systems, agents and the tools they call. It is voluntary, non-certifiable and deliberately descriptive: it classifies risks, it does not prescribe controls or grant compliance.

Key requirements

• Prompt injection has led the list since the first edition, and remains the class with no clean fix — only layered containment.
• The 2025 edition covers prompt injection, sensitive information disclosure, supply chain, data and model poisoning, improper output handling, excessive agency, system prompt leakage, vector and embedding weaknesses, misinformation, and unbounded consumption. The list is revised periodically, so check the current edition rather than trusting a cached one.
• Several entries are agent-specific in effect: excessive agency and improper output handling only become severe once the model can act.
• It is a taxonomy, not a control set. Mapping a finding to LLM06 tells you what kind of problem it is, not what to build.
• It is the lingua franca of the field: security reviews, vendor questionnaires and bug reports all reference it, which is most of why it is worth knowing by number.
• Coverage of the list is not a security posture. Every entry needs a control in your architecture, and an entry with no control is an accepted risk whether or not anyone wrote that down.

Controls

Map the list onto your own architecture

Walk each entry against your actual inputs, tools, data stores and outputs. The exercise is worth more than the list, because it surfaces the entries that do not apply and the surfaces the list does not name.

Assign an owner and a control per entry

Each applicable class needs a named component that bounds it and a person who maintains that component. An entry mapped to nothing is a gap with a reference number.

Treat prompt injection as containment, not prevention

LLM01 has no reliable fix at the model layer. The controls that matter are least-privilege tooling, egress restriction, output handling and approval gates for high-impact actions.

Constrain agency explicitly

For LLM06, write down what the agent may do, with which credentials, against which targets — and enforce it below the model rather than in the prompt.

Handle model output as untrusted input

For LLM05, anything the model emits that reaches a renderer, a shell, a query or another system needs the same encoding and validation you would apply to input from a stranger.

Bound consumption

For LLM10, rate limits, quotas and timeouts turn an availability and cost attack into a logged refusal. This is the entry teams most often skip because it does not look like security until the invoice arrives.

Re-run the mapping when the list or the system changes

The list is revised and your tool catalogue grows. A mapping done once is a document about a system that no longer exists.

Checklist

• 01Read the current edition rather than a summary — including this one.
• 02Produce a mapping table: entry → applies? → control → owner.
• 03For every applicable entry with no control, record it as an accepted risk with a reason and a compensating detection.
• 04Write a test for each control, and see the test fail before trusting it.
• 05Check the entries that only bite with tools: excessive agency, improper output handling, supply chain.
• 06Confirm rate limits and quotas exist and return correct signals to well-behaved clients.
• 07Re-run the mapping whenever a tool, a data source or an autonomy level changes.
• 08Use the list's numbering in findings so reviewers and vendors are discussing the same class.

Common pitfalls

• Treating the list as a compliance target: covering ten headings while the actual architecture stays unexamined.
• Assuming a model vendor's safety work covers LLM01. It reduces attempts; the consequences remain entirely yours.
• Mapping to a cached edition. The list is revised, and an old mapping quietly stops covering current classes.
• Skipping LLM10 because unbounded consumption looks like an operations problem rather than a security one.
• Confusing naming a class with controlling it. A tidy mapping table with no enforcement is documentation of risk, not reduction of it.

Examples

• An agent that summarises customer emails maps to LLM01 (the email body is untrusted instruction input), LLM02 (the summary can repeat data the requester should not see) and LLM06 (the CRM tool turns a hijack into an action) — three entries from one feature, each needing a different control.
• A RAG system over an internal wiki maps to LLM01 via indirect injection from any page editor, LLM04 if the index can be poisoned, and LLM08 for retrieval that returns documents outside the requester's permissions.
• A public MCP endpoint maps most sharply to LLM10: read-only, public data, so the consumption bound — rate limits with correct headers — is the entry doing the real work.

FAQs

Is the OWASP LLM Top 10 something you can be compliant with?

No. It is an awareness and classification document, not a certifiable standard. It pairs naturally with a management system such as ISO 42001 or a framework such as the NIST AI RMF, which is where governance obligations actually live.

Which entries change most when you add tools to a model?

Excessive agency and improper output handling. Without tools they produce a wrong answer; with tools they produce an action, and severity moves from embarrassment to incident.

How does it relate to MITRE ATLAS?

They answer different questions. OWASP names the vulnerability classes in your application; ATLAS catalogues the tactics and techniques an adversary uses against AI systems. One is a checklist over your design, the other is a map of the attacker's playbook.

References

• OWASP — Top 10 for LLM Applications
• OWASP — LLM01: Prompt Injection
• MITRE ATLAS — Adversarial Threat Landscape for AI Systems
• NIST — AI Risk Management Framework (AI RMF 1.0)

Related governance