The OWASP LLM Top 10, in plain language

OWASP publishes a ranked Top 10 of risks for LLM applications. It is written for security teams, in security vocabulary, and it is the list an auditor or a client questionnaire will reference. This page translates each entry into plain language and points at where this site already covers it in depth.

One dating note first, because precision about editions is the point of a page like this. The entries below are the 2025 list, which is what OWASP's site publishes as its live, per-entry taxonomy. A 2026 edition exists as a downloadable report; its contents are behind a download and are not restated here from second-hand summaries. If your auditor cites the 2026 edition, read their copy rather than anyone's blog post about it. For agent-specific risks, the companion page maps the OWASP agentic threats.

The ten, translated

LLM01: Prompt Injection

Instructions hidden in content the model reads get treated like your instructions, because the architecture gives everything one channel. Top of the list every edition so far, and the page this site opens its security track with.

LLM02: Sensitive Information Disclosure

The model reveals something it should not — from its training, its context, or what another user's session fed it. Our angle: what never goes in, because you control the input side completely.

LLM03: Supply Chain

The models, data and components you build on carry their own compromises. For most readers here this arrives as skills, plugins and marketplaces and MCP servers.

LLM04: Data and Model Poisoning

Training or fine-tuning data manipulated so the model misbehaves later. Mostly a builder's risk; if you fine-tune, the data pipeline is part of your attack surface.

LLM05: Improper Output Handling

Treating model output as safe to execute, render or pass downstream without checking. The model writes SQL, your code runs it — the injection is now yours.

LLM06: Excessive Agency

The system can do more than its task needs, so a failure anywhere becomes an action everywhere. This is blast radius by another name, and permissions are the control.

LLM07: System Prompt Leakage

Secrets or logic parked in the system prompt and assumed hidden. Assume anything in the prompt can come out of the model; secrets belong outside the context entirely.

LLM08: Vector and Embedding Weaknesses

RAG's storage layer as an attack surface — poisoned documents, leaky embeddings, retrieval that can be steered. If you run retrieval over documents others can write to, this is LLM01's delivery mechanism.

LLM09: Misinformation

The model states false things fluently and your application repeats them. The mechanism is documented and structural; the control is verification, not hope.

LLM10: Unbounded Consumption

Nothing caps how much the system can spend — tokens, money, compute — so an attacker or an accident runs the meter. Quota discipline and cost control are the everyday versions.

How to actually use the list

Not as reading. As a checklist against a specific deployment, one entry at a time, asking "where does this apply to us and what bounds it".

Three entries usually dominate for the readers of this site: LLM01 because agents read untrusted content, LLM06 because grants accumulate, and LLM05 because output that becomes action is the whole point of an agent. If your review only has budget for three, those three.

Note also what the list is not: it is about applications using LLMs, and a separate OWASP Top 10 exists for agentic systems. An agent deployment should be checked against both.

What goes wrong

Reading it as a compliance artefact. Ticking ten boxes in a document protects nothing. Each entry is a question about your specific system.

Citing an edition you have not read. The editions differ, the ranking moves, and an auditor will notice a summary of a summary.

Treating the exotic entries as the important ones. Embedding attacks are interesting; an over-permissioned agent reading customer email is your actual risk profile.

Assuming a chatbot-era review covers an agent. Agency changes the failure modes, which is why the separate agentic list exists.

How to check it worked

Take one deployment and write one sentence per entry: where this applies to us, or why it does not. Entries where the sentence comes hard are the findings. That document is also, not incidentally, most of the answer to the next security questionnaire a client sends.