Last week you got the big picture: LLM applications introduce a genuinely new attack surface, and "it's just software security" undersells the problem. This week we go category by category through the OWASP Top 10 for LLM Applications (2025 edition, v2.0), published November 18, 2024 by the OWASP GenAI Security Project. This is the field's closest thing to a shared vocabulary for LLM risk, and you'll be using these ten labels constantly for the rest of the course — in threat models, in vendor conversations, and in your own capstone risk assessments. Here's the full list, in the order OWASP ranks it:
| Rank | Code | Risk | One-line description |
|---|---|---|---|
| 1 | LLM01 | Prompt Injection | Crafted input (direct or indirect) overrides the model's intended instructions |
| 2 | LLM02 | Sensitive Information Disclosure | Model reveals PII, secrets, or proprietary data it was exposed to |
| 3 | LLM03 | Supply Chain | Compromised training data, base models, plugins, or dependencies |
| 4 | LLM04 | Data and Model Poisoning | Training or fine-tuning data is manipulated to implant bad behavior |
| 5 | LLM05 | Improper Output Handling | Model output is trusted blindly downstream, enabling XSS/SSRF/SQLi/RCE |
| 6 | LLM06 | Excessive Agency | Agent has more function, permission, or autonomy than the task requires |
| 7 | LLM07 | System Prompt Leakage | Internal instructions/rules are exposed, enabling targeted bypass |
| 8 | LLM08 | Vector and Embedding Weaknesses | Flaws in how RAG systems generate, store, or retrieve embeddings |
| 9 | LLM09 | Misinformation | Confident, plausible, but false output presented as fact |
| 10 | LLM10 | Unbounded Consumption | Uncontrolled resource use — cost, denial of service, model theft |
What actually changed from the 2023 list. Prompt Injection held the #1 spot for a second edition in a row — it remains the risk every LLM application must design around from day one. The bigger story is Sensitive Information Disclosure jumping from 6th to 2nd, reflecting how much production traffic now flows through RAG pipelines and agents that legitimately touch sensitive data, multiplying the ways it can leak. Three categories are new or substantially renamed: System Prompt Leakage (LLM07), Vector and Embedding Weaknesses (LLM08), and Unbounded Consumption (LLM10) — all direct responses to how the field actually deploys LLMs now: as agents with system prompts carrying real logic, as RAG systems with embedding stores, and as metered, cost-bearing services that attackers can drain. LLM05 — Improper Output Handling deserves special attention because it inverts the direction you're used to thinking about. Prompt Injection is an attack coming in; Improper Output Handling is the same failure mode on the way out. If your application takes the model's response and passes it — unvalidated — into a browser (XSS), a backend HTTP client (SSRF), a database query (SQL injection), or a shell/eval context (RCE), you've handed the attacker a path to your systems through the model's mouth. The fix is the same discipline you already apply to any untrusted input: never trust it, always validate and encode for the context it's about to enter, whether that's HTML, SQL, or a system call. LLM06 — Excessive Agency is not about a chatty or overconfident model — it's structural. OWASP names three root causes: excessive functionality (the agent has tools it doesn't need for its job), excessive permissions (the tools it has grant more access than necessary), and excessive autonomy (the agent acts without a human checkpoint where one matters). None of these are fixed by adjusting the system prompt's tone. They're fixed by design: least-privilege tool scoping, narrowly-scoped API credentials per agent, and human-approval gates on consequential actions (sending money, deleting data, executing code). LLM07 — System Prompt Leakage is dangerous for a specific, non-obvious reason: real production system prompts are not just "be helpful and polite." They routinely embed business logic — internal filtering rules, escalation criteria, permission boundaries, even fragments of proprietary process. When a system prompt leaks, an attacker doesn't just learn that rules exist; they learn exactly what the rules are, which lets them craft a precise bypass. The mitigation is architectural: never put secrets, credentials, or the sole enforcement of a security control in the system prompt. Treat it as guidance the model receives, not as a security boundary — enforce real boundaries outside the model, in code. A table like the one above is useful, but memorizing labels isn't the goal — being able to place a real incident into the right category, and defend that placement, is. That's exactly what this week's lab and discussion push you to do. Addressing the misconceptions directly: