The OWASP LLM Top 10

Welcome to Security & Red-Teaming — the section where you stop trusting your AI system and start trying to break it. And it begins where all good security begins: knowing your enemy.

The OWASP Top 10 for LLM Applications is the field's canonical answer to "what are the ways an AI app actually gets attacked?" OWASP (the Open Worldwide Application Security Project) has maintained the famous Web Application Top 10 for two decades; in 2023 they created an LLM-specific list, and the 2025 edition is the current industry standard. It's not academic — it's the checklist security teams, auditors, and red-teamers actually use to threat-model AI systems.

This lesson is the map of the whole territory. We'll walk all ten — what each is, a concrete example, and its primary defense — and you'll learn them the way professionals do: by triaging real incidents into them. The worst of them then get their own deep dives in the rest of this section: prompt injection in depth, data exfiltration & tool abuse, securing agents & MCP, and red-teaming your AI application.

The reassuring part — and the throughline: an LLM app is a system, and securing it is mostly classic application security applied to a new shape. You've already built many of these defenses in the guardrails section (L231–L238). This lesson connects them to the threats they answer, and names the ones still ahead.

Before the list, the mindset. The instinct for a new engineer is to see the LLM as the thing to secure. But an AI application is a pipeline of components, and every stage is an attack surface:

user input → retrieval / RAG → the model → tools / agent → output → downstream systems

• Input can be crafted to hijack the model (injection) or extract its instructions (prompt leakage).
• Retrieval can be poisoned, or leak across tenants (vector weaknesses).
• The model can disclose secrets or fabricate facts.
• Tools / agents can be abused to take real-world actions (excessive agency).
• Output is untrusted input to whatever consumes it — a browser, a database, a shell.
• And the whole supply chain (models, datasets, packages) and the whole system's capacity are at risk.

Two principles run through everything: threat-model every stage (ask "what could an attacker do here?" at each box), and defense in depth — no single control is fool-proof, so you layer them. The model is the new part, but the disciplines are old: validate input, enforce least privilege, escape output, rate-limit, and vet your dependencies. The OWASP list is just these threats, named and ranked.

Here's the full list — your reference card. Read it once now; we'll add depth in the clusters that follow.

★ = new in the 2025 edition. Now the context that makes them stick — grouped by where they live.

Four risks cluster at the edges of the model — what goes in and what comes out:

• LLM01 Prompt Injection — the #1 risk, and unique to LLMs. Crafted text overrides your instructions, either directly (the user types "ignore your rules") or indirectly (malicious instructions hidden in a web page, doc, or email the model reads). It gets its own deep dive next (Prompt Injection in Depth); your front-line defense is the input guardrail from L231 (Input Guardrails: Validation, PII & Moderation) plus least privilege.
• LLM07 System Prompt Leakage (new) — attackers extract your system prompt. The real lesson: the system prompt is not a secret store. If leaking it (with its rules, or worse, an embedded API key) is a breach, you've designed wrong — put secrets and enforcement outside the model.
• LLM02 Sensitive Information Disclosure — the model surfaces PII, credentials, or another user's data. Defended by PII redaction on the way in and out (L231 / L232) and data minimization.
• LLM05 Improper Output Handling — the sneaky one. The danger isn't the model — it's that apps trust the output and pipe it, unescaped, into a browser, database, or shell, creating classic XSS, SQL injection, or RCE. The fix is a one-liner mindset: treat model output as untrusted user input (connects to L232 — Output Guardrails: Format, Safety & Grounding).

Three risks live upstream, in what your system is built from — the part teams most often forget to threat-model:

• LLM03 Supply Chain — your app depends on third-party models, datasets, packages, and adapters, any of which can be vulnerable or malicious: a backdoored model on a hub, a typosquatted pip package that steals your keys, a compromised LoRA. Classic appsec answers apply — vet and pin dependencies, prefer signed/verified models, keep an SBOM, and track model provenance (the model cards of L237 — Model Cards, Audit Logs & Incident Response).
• LLM04 Data & Model Poisoning — an attacker tampers with training, fine-tuning, or embedding data to plant a backdoor (a trigger phrase that flips off safety) or to bias behavior. Defended by data provenance, vetting, and anomaly detection on what you train and embed.
• LLM08 Vector & Embedding Weaknesses (new — and a direct consequence of RAG going mainstream) — your retrieval layer is an attack surface: a poisoned knowledge base steers answers, and a vector store without access control leaks across tenants or lets one user retrieve another's documents. Defend with permission-aware retrieval, tenant isolation, and validation of ingested content.

The pattern: the moment your system ingests something from outside — a model, a dataset, a document, a package — you've trusted it. Threat-model that trust.

The last three are about what the system does, says, and costs:

• LLM06 Excessive Agency — as we give models tools and autonomy, a model mistake becomes a real-world action: an agent with broad permissions deletes data, sends money, or emails the wrong people. The defense is the agent-UX discipline from L230 (Agent UX: Showing Reasoning, Progress & Approvals) — least-privilege tools, narrow scopes, and human approval gates before consequential actions. (Deep dive: Data Exfiltration & Tool Abuse and Securing Agents & MCP, next.)
• LLM09 Misinformation — confident fabrications users over-rely on (the category that absorbed "overreliance"). The real-world bite is the lawyer who filed a hallucinated case. Defended by the whole L233 (Hallucination Mitigation Strategies) playbook — grounding, citations, and calibrated abstention.
• LLM10 Unbounded Consumption (new — expanded from "Model DoS") — uncontrolled query/resource use that causes denial of service, runaway cost (a metered API is a metered bill), and model extraction via mass querying. Defended with rate limits, quotas, timeouts (L234 — Fallbacks, Retries & Circuit Breakers), input/output caps, and cost monitoring & alerts.

Notice how many of these you've already defended — agency (L230), misinformation (L233), consumption (L234). The Top 10 isn't a list of unsolved problems; it's the map that tells you which defenses matter and where the gaps are.

You won't remember a list you only read. Learn it the way a security engineer does — by classifying real attacks. Read each incident, name the OWASP category, and check your reasoning against the why + the fix:

Notice how often a real attack spans categories — the agent that emailed your database out was indirect prompt injection (LLM01) exploiting excessive agency (LLM06). Real incidents are rarely one box; the Top 10 gives you the vocabulary to decompose them — and the defense-in-depth instinct to close every box an attacker could use.

The 2025 edition was reorganized around how LLM apps are really built and attacked — which is why the three new entries matter:

• LLM07 System Prompt Leakage — because teams kept hiding secrets and logic in prompts.
• LLM08 Vector & Embedding Weaknesses — because RAG went mainstream, making the retrieval layer a first-class attack surface.
• LLM10 Unbounded Consumption — broadened from "Model DoS" to include runaway cost and model extraction, not just downtime.

(Two old entries — Insecure Plugin Design and Model Theft — were folded into Supply Chain and Excessive Agency / Unbounded Consumption, and Overreliance became part of Misinformation.)

How to use it — it's a process, not a poster:

1. Inventory your app's stages (input, retrieval, model, tools, output) — the attack surface.
2. Walk the Top 10 against each stage — which of these ten could strike here? That's a threat model.
3. Map each live risk to a control and find the gaps (this is exactly the guardrail layer you built in L238 — Hands-On: Build a Guardrail Layer, plus the governance of L236).
4. Prioritize by likelihood × impact, and re-run it as the app changes.

It pairs naturally with the broader OWASP Web Top 10 (an LLM app is still a web app) and the governance frameworks from L236 (AI Governance & Compliance — EU AI Act, NIST AI RMF) — the NIST GenAI Profile's risk areas overlap heavily with this list.

Use the Triage widget and what you've learned:

1. Run all ten scenarios. Which categories did you misclassify — and what cue would catch them next time?
2. For the hidden-instruction-in-a-web-page incident: which category, and why is it indirect rather than direct injection?
3. The <script>-tag-in-a-reply incident is LLM05, not LLM01. Why is the problem the app, not the prompt?
4. Pick your own AI project (or one you use). Walk its stages (input → retrieval → model → tools → output) and name one Top-10 risk at each. That's a threat model.
5. Which three entries are new in 2025, and what trend does each reflect?

→ (2) LLM01 Prompt Injection, indirect variant — the malicious instruction lived in content the model ingested (the web page), not in the user's own message; the user was innocent, the data was poisoned. (3) Because the model just produced text; the vulnerability is that the app rendered that text as HTML without escaping it — improper output handling. Treat model output as untrusted input to the browser/DB/shell and the bug disappears. (5) LLM07 System Prompt Leakage (secrets-in-prompts), LLM08 Vector & Embedding Weaknesses (RAG went mainstream), and LLM10 Unbounded Consumption (runaway cost & model extraction, beyond mere DoS) — together they track the rise of RAG, agents, and metered APIs.

• “Securing an LLM = securing the model.” No — an LLM app is a system; every stage (input, retrieval, tools, output, supply chain) is an attack surface.
• “The OWASP LLM Top 10 is a compliance checkbox.” It's a threat-modeling tool — walk it against your app's stages to find and prioritize real gaps.
• “Improper Output Handling is the model's fault.” It's the app's fault for trusting output — model output is untrusted input to the browser/DB/shell. Escape it.
• “The system prompt keeps my rules safe.” Assume the system prompt leaks (LLM07) — put secrets and enforcement outside the model, never inside the prompt.
• “Prompt injection only comes from the user.” Indirect injection hides in retrieved content — the user can be innocent and the data hostile.
• “RAG is just a feature.” Your retrieval layer is an attack surface (LLM08) — poisoned indexes and cross-tenant leakage are real; use permission-aware retrieval.
• “Unbounded Consumption is just downtime.” It's also runaway cost (a metered bill) and model extraction — rate-limit, quota, and monitor cost.

• The OWASP LLM Top 10 (2025) is the industry-standard threat map — know it, and use it to threat-model every stage of your app (input · retrieval · model · tools · output · supply chain).
• The ten: LLM01 Prompt Injection · LLM02 Sensitive Info Disclosure · LLM03 Supply Chain · LLM04 Data & Model Poisoning · LLM05 Improper Output Handling · LLM06 Excessive Agency · LLM07 System Prompt Leakage ★ · LLM08 Vector & Embedding Weaknesses ★ · LLM09 Misinformation · LLM10 Unbounded Consumption ★.
• New surface, old discipline: the model is new, but the defenses are classic appsec — validate input, least privilege, escape output, rate-limit, vet the supply chain — layered as defense in depth.
• Treat model output as untrusted input (LLM05) and assume the system prompt leaks (LLM07) — two mindset shifts that prevent whole bug classes.
• You've built much of the defense — guardrails (L231/L232), agent approvals (L230), hallucination mitigation (L233), limits (L234), governance & provenance (L236/L237). The rest of this section goes deep on the worst: prompt injection, data exfiltration & tool abuse, securing agents & MCP, and red-teaming.