The OWASP Top 10 for LLM Applications

CAP, ACID vs BASE, latency numbers, back-of-envelope estimation, single points of failure — the vocabulary every system designer thinks in.

Core Philosophy: When the AI security field was new, every team faced LLM risks alone, with no shared vocabulary. Just as the classic OWASP Top 10 (2.3) gave web security a common map, the security community has produced an OWASP Top 10 for LLM Applications — a shared, prioritized map of the risks specific to LLM-based systems. Learn it the way you learned the original: as the field’s common language and as the index to everything that follows.

Part 1: The Problem

Page 6.1 established that AI systems break differently and that the model adds new attack surfaces. But “the model is an attack surface” is too vague to act on. To secure LLM applications systematically, you need a structured, named, shared list of what actually goes wrong — the LLM equivalent of what the classic OWASP Top 10 (2.3) gave you for web applications.

That list exists: the OWASP Top 10 for Large Language Model Applications. The same OWASP community behind the classic Top 10 produced it, for the same reasons — to give the field a shared vocabulary, a prioritized map of the most important risks, and a common reference that teams, tools, and standards can all point to.

This page is that map. It is deliberately an index page: it surveys all the major LLM risk categories at a plain-English level, and the next four pages (6.3–6.6) go deep on the most important ones. Learn this page the way you learned 2.3 — as the organizing structure for everything in Phase 6A.

Part 2: The Concept — Why a “Top 10 for LLMs” Exists

The reasoning mirrors 2.3 exactly. Recall why the classic OWASP Top 10 mattered: it took a sprawling, intimidating space of web vulnerabilities and turned it into a prioritized, named, shared list — so the whole field could talk about the same risks, focus on what matters most, and have a common reference.

LLM applications created the same need, freshly:

• A new domain needed a shared map. LLM-specific risks were being discovered and discussed in scattered ways, with no common vocabulary. A team could not easily ask “have we covered the main LLM risks?” because there was no agreed list of what they were.
• Prioritization. Of all the things that can go wrong with an LLM application, which matter most? A Top 10 answers that — it is a prioritized list, focusing attention.
• A common language. “Prompt injection,” “insecure output handling,” “excessive agency” — named categories let practitioners, tools, vendors, and standards all refer to the same risks unambiguously.
• A teaching and checklist structure. It gives newcomers a learnable map and gives teams a checklist to assess their LLM applications against.

A few honest framings, exactly as with 2.3:

• It is a map of risk categories, not an exhaustive list of every possible AI flaw. It is the most important and common LLM application risks — the starting structure, not the whole universe.
• It is recent and it evolves. The LLM Top 10 is a young document in a fast-moving field; it gets revised as understanding matures. The categories and their underlying ideas are what you internalize — and you should expect specifics and even the list itself to update over time (the stay-current point from 6.1).
• It is for LLM applications. It is specifically about the risks of systems built using LLMs — which is what most practitioners work with. It complements, rather than replaces, broader AI/ML security (the training-time and model attacks of 6.4 sit alongside it).

Because this list evolves, when you act on this page in practice, look up the current version of the OWASP Top 10 for LLM Applications. The categories below are the stable, important concepts; treat the live document as the authoritative current detail.

Part 3: The Concept — The Major Risk Categories (Part 1)

Here is a plain-English survey of the major LLM application risk categories. This is the core of the index page. (The categories are grouped here for teaching; consult the current OWASP document for its exact list and ordering.)

Prompt injection. The headline LLM risk. Untrusted input — supplied directly by a user, or indirectly through content the LLM processes — manipulates the model into ignoring its intended instructions and doing what the attacker wants instead. It is the AI-era cousin of classic injection (2.4). Page 6.3 covers this in depth.

Insecure output handling. The application trusts the LLM’s output too much. LLM output is treated as safe and passed directly into other systems — displayed in a web page, used in a query, executed, fed to another component — without validation. If the output contains something harmful (because the model was manipulated, or simply produced bad output), that harm propagates. The fix is to treat model output as untrusted input to the next system — covered in 6.5.

Excessive agency. An LLM application is given too much capability — too many tools, too much access, too much autonomy — relative to what it actually needs, and relative to how much it can be trusted. When the LLM can take real actions (call APIs, modify data, trigger operations) and has more power than necessary, a manipulated model causes proportionally more damage. This is the least-privilege principle (0.2, 4.3), violated in an AI context. Central to 6.5.

Sensitive information disclosure. An LLM application reveals information it should not — sensitive data from its training, confidential data from its context or retrieved documents, system instructions, or other users’ data. Covered in 6.6.

These four — prompt injection, insecure output handling, excessive agency, sensitive information disclosure — are arguably the most important for someone building or securing LLM applications, because they are the ones most directly under the application team’s control. Note how each one is a familiar security principle in new clothing: injection, trusting untrusted data, least privilege, data leakage.

Part 4: The Concept — The Major Risk Categories (Part 2)

Continuing the survey — the categories that touch the model, the data, and the surrounding ecosystem:

Training data poisoning. The data a model is trained (or fine-tuned) on is corrupted — deliberately or through contaminated sources — so the resulting model behaves in flawed or attacker-influenced ways. An attack on the model’s formation. Covered in 6.4.

Supply chain vulnerabilities. LLM applications depend on things from third parties — the model itself (often a third-party model), AI frameworks and libraries, datasets, plugins. Any of these can be vulnerable, compromised, or untrustworthy — the supply-chain risk of 2.10, in the AI domain. Covered in 6.6.

Model denial of service / unbounded consumption. An attacker drives an LLM application to consume excessive resources — degrading availability (the ‘A’ of the CIA triad, 1.1) and, because LLM usage often costs money per request, potentially inflicting large costs. An availability-and-cost attack specific to how LLM systems operate.

Insecure plugin / tool design. When an LLM application uses plugins or tools (extensions that give the model capabilities), those plugins themselves can be insecurely designed — accepting unsafe input, lacking proper access control, doing dangerous things. A poorly-designed tool is a weak point the model’s capabilities flow through. Closely related to excessive agency, and revisited in 6.5.

Overreliance. People — users, or the developers building on the model — trust LLM output too much. LLMs can produce output that is wrong, fabricated, biased, or subtly flawed while sounding completely confident and authoritative. Overreliance is the human-and-organizational risk of acting on that output without appropriate verification. (Note: this is the human counterpart to “insecure output handling” — that category is about systems over-trusting output; overreliance is about people doing so. This theme returns forcefully in Part B, 6.7–6.8, about using AI for security work.)

Model theft. The model itself — a valuable asset — is stolen or extracted. Covered in 6.4.

Together, Parts 3 and 4 are the field’s shared map of LLM application risk. You do not need every detail memorized today — you need to recognize the categories, understand each in plain English, and know which deep-dive page covers it.

Part 5: The Concept — One Root, Many Faces (Again)

A powerful pattern, exactly mirroring what you saw with the classic OWASP Top 10 in 2.3: these LLM risks look like ten separate things, but they trace back to a small number of underlying causes — and those causes are largely security principles you already know.

   THE LLM RISKS TRACE BACK TO FAMILIAR ROOTS:

   ROOT: untrusted input mixing with instructions
     → prompt injection
       (the injection principle of 2.4, in an LLM)

   ROOT: trusting data that shouldn't be trusted
     → insecure output handling (trusting model output)
     → overreliance (humans trusting model output)
       (the trust-boundary principle of 1.2 / 4.3)

   ROOT: too much privilege / capability
     → excessive agency
     → insecure plugin/tool design
       (the least-privilege principle of 0.2 / 4.3)

   ROOT: data — its confidentiality and its integrity
     → sensitive information disclosure (confidentiality)
     → training data poisoning (integrity)
       (the CIA triad of 1.1)

   ROOT: depending on things you don't control
     → supply chain vulnerabilities
       (the supply-chain principle of 2.10)

   ROOT: availability under attack
     → model denial of service / unbounded consumption
       (the 'A' of CIA — 1.1)

This is the reassuring, and important, truth of Phase 6: the LLM Top 10 is mostly your existing security principles, expressing themselves in a new domain. Untrusted input, trust boundaries, least privilege, the CIA triad, supply chain — you learned every one of these in Phases 1–5. The manifestations are new and require new defensive techniques (which 6.3–6.6 teach). But the thinking is the security mindset you already have. You are not starting over; you are transferring.

This also tells you how to use the LLM Top 10: as a structured checklist for assessing and threat-modeling LLM applications (the 5B.4 threat-modeling skill, with this list as the “what can go wrong” guide), and as the organizing map for learning the deep material.

Part 6: The Concept — How the Top 10 Indexes the Rest of Phase 6A

This page is the index; here is the map of what it indexes. Phase 6A’s remaining pages take the most important categories and go deep:

   THIS PAGE (6.2) — the OWASP LLM Top 10: the shared map
        │
        ├─► 6.3  Prompt Injection & Jailbreaking
        │        → prompt injection (the headline risk)
        │
        ├─► 6.4  Data Poisoning, Model Theft & Training-Time Attacks
        │        → training data poisoning, model theft,
        │          and related attacks on the data and model
        │
        ├─► 6.5  Securing LLM Applications & AI Agents
        │        → the DEFENSES for insecure output handling,
        │          excessive agency, insecure plugin/tool design
        │          — the defensive core of the phase
        │
        └─► 6.6  Sensitive Data, Privacy & the AI Supply Chain
                 → sensitive information disclosure,
                   supply chain vulnerabilities

Note the structure: 6.3 and 6.4 are largely about understanding the attacks; 6.5 is the defensive core — how to actually build LLM applications securely; 6.6 covers data/privacy/supply-chain. Together they turn this index into working knowledge. And throughout, the OWASP LLM Top 10 is the shared vocabulary that lets you name what you are dealing with.

A final connection: just as the classic OWASP Top 10 became the backbone of web application security work (and of the AppSec track, 5B), the OWASP LLM Top 10 is becoming the backbone of AI application security work. An AppSec engineer (Track B) increasingly must know it; a security professional assessing AI systems uses it as their framework. Learning it well is learning the language the field is converging on.

🔑 The deep lesson: the OWASP Top 10 for LLM Applications is the field’s shared, prioritized map of LLM-specific risks — the LLM-era counterpart of the classic OWASP Top 10. Its categories — prompt injection, insecure output handling, excessive agency, sensitive information disclosure, training data poisoning, supply chain, model DoS, insecure plugin design, overreliance, model theft — look like ten separate problems but trace back to familiar roots: untrusted input, trust boundaries, least privilege, the CIA triad, supply chain. It is the index to the rest of Phase 6A, the checklist for assessing AI systems, and the shared vocabulary of the field — learn it as the common language of AI application security.

📓 Key Terms

🧪 Hands-On Lab

This is an index page — its lab is about learning the map and applying it as a checklist.

Task 1 — Read the current OWASP LLM Top 10. Find the current official OWASP Top 10 for LLM Applications. Read it through. Note how its current categories and ordering compare to this page’s survey — and that it has evolved/will evolve.

Task 2 — Write each category in your own words. For every category, write a one- or two-sentence plain-English explanation in your own words. If you cannot, re-read until you can. This is the 2.3 discipline applied to LLMs.

Task 3 — Map each to its root. Using Part 5, write each LLM risk category beside the familiar security principle it traces back to (untrusted input, trust boundaries, least privilege, CIA, supply chain). Confirm for yourself that this is your existing knowledge in a new domain.

Task 4 — Assess an AI application against the list. Take an AI application (the one you built in the 6.1 lab, or one you can examine). Walk it against the LLM Top 10 as a checklist — for each category, ask “is this application exposed to this? how?” Practice the list as an assessment tool.

Task 5 — Threat-model an AI app with the list. Take the threat-modeling method from 5B.4 and run it on an LLM application, using the OWASP LLM Top 10 as your structured “what can go wrong” guide. See the two skills combine.

Task 6 — Build your LLM risk reference. In Notion, create an “OWASP LLM Top 10” page — each category, plain-English meaning, its underlying root, and which Phase 6 page covers it. Your reference and checklist for AI application security.

⚠️ Common Mistakes

• Treating the LLM Top 10 as exhaustive. It is the most important and common LLM application risks — a prioritized map, not every possible AI flaw. Broader AI/ML attacks (6.4) sit alongside it.
• Memorizing names without understanding. As with 2.3, the value is understanding each category in plain English and knowing its root cause — not reciting a list.
• Ignoring that it evolves. It is a young document in a fast-moving field. Learn the durable concepts; consult the current version for authoritative detail.
• Missing the familiar roots. These risks are largely your existing principles — injection, trust boundaries, least privilege, CIA, supply chain — in a new domain. Seeing that makes them learnable, not intimidating.
• Confusing insecure output handling with overreliance. One is systems trusting model output unchecked; the other is people doing so. Related, but distinct — and both matter.
• Not using it as a checklist. The list’s practical power is as an assessment and threat-modeling structure for real AI applications. Use it that way.

✅ Recap & What’s Next

• The OWASP Top 10 for LLM Applications is the field’s shared, prioritized map of LLM-specific risks — the LLM-era counterpart of the classic OWASP Top 10 (2.3).
• Its categories — prompt injection, insecure output handling, excessive agency, sensitive information disclosure, training data poisoning, supply chain, model DoS, insecure plugin design, overreliance, model theft — trace back to familiar roots you already know.
• It is the index to 6.3–6.6, a checklist for assessing AI systems, and the field’s shared vocabulary — and it is a young, evolving document, so learn the concepts and consult the current version.

Next (6.3): We go deep on the headline LLM risk — prompt injection and jailbreaking: how untrusted input hijacks a model’s instructions, why it is so hard to fully fix, and why it becomes especially dangerous when the model can take actions.