OWASP Top 10 for LLM Applications, Explained

Security teams have spent two decades building institutional muscle around the OWASP Top 10 for web applications — SQL injection, broken authentication, security misconfiguration, and the rest of the list every application security program is built around. When large language models started showing up in production applications, the same community that maintains that list did the obvious thing: they built an equivalent one for LLMs. The OWASP Top 10 for Large Language Model Applications, first published in 2023 and revised since as the threat landscape matured, is now the closest thing the industry has to a shared vocabulary for what actually goes wrong when you put a language model into a real product.

It matters for the same reason the original OWASP Top 10 mattered: it gives security teams, auditors, and vendors a common reference point instead of everyone inventing their own taxonomy. When an assessment report says a finding maps to LLM01 or LLM06, that's a specific, checkable claim — not marketing language dressed up to sound rigorous. This piece walks through what the list actually covers, category by category, with concrete examples of what each one looks like when it happens for real.

LLM01: Prompt Injection

Prompt injection sits at the top of the list for good reason — it's the most common, most structurally fundamental vulnerability class in LLM applications, and there's still no clean architectural fix for it. The category covers both direct injection (a user typing adversarial instructions straight into a chat interface) and indirect injection (adversarial instructions hidden in a document, webpage, or tool output the model processes on the user's behalf, without the user ever seeing the payload).

OWASP's guidance here is blunt: don't rely on the model's own judgment as your only defense. Real mitigations include privilege separation (the model shouldn't have more access than the specific task requires), human confirmation for high-impact actions, and treating any content the model ingests from an external source — a fetched webpage, an uploaded file, a tool's return value — as untrusted input, the same way a web application treats user-submitted form data.

LLM02: Sensitive Information Disclosure

This category covers the model leaking information it shouldn't — PII embedded in its training data, proprietary system prompts, internal business logic, or data from other users in a multi-tenant application. It happens in a few distinct ways: the model was trained or fine-tuned on data that included sensitive information and reproduces it verbatim when prompted the right way; the application passes sensitive context into the model's prompt (customer records, internal documentation) without adequate access controls on who can query that context; or an attacker uses extraction techniques to get the model to reveal its own system prompt, which often contains business logic, internal tool names, or credentials that were never meant to be user-facing.

The practical fix isn't a single control — it's layered: strip or mask sensitive data before it ever reaches the model where possible, enforce the same access-control boundaries at the application layer that you'd enforce for direct database access, and treat the system prompt as something that will eventually leak rather than something that can be reliably kept secret through prompting alone.

LLM03: Supply Chain

LLM applications inherit a much longer, less-audited supply chain than traditional software: pretrained base models from third parties, fine-tuning datasets of unknown provenance, LoRA adapters and other lightweight fine-tunes downloaded from public model hubs, and third-party plugins or tools the agent has access to. Any link in that chain can be poisoned — a backdoored fine-tune that behaves normally until a specific trigger phrase activates hidden behavior, a compromised plugin that exfiltrates data through a channel the developer never intended, or a popular open-source model checkpoint that's been subtly modified and re-uploaded under the original name.

This is a newer, less mature risk category than most of the others on this list, largely because the tooling to verify model provenance and integrity — the AI equivalent of a software bill of materials — is still immature compared to traditional software supply chain security. Treating third-party models and plugins with the same scrutiny you'd apply to a new open-source dependency, rather than assuming a popular download count implies safety, is currently the most realistic mitigation available.

LLM04: Data and Model Poisoning

Poisoning attacks target the training or fine-tuning pipeline itself rather than the deployed model's runtime behavior. An attacker who can influence training data — by contributing to a public dataset the model is trained on, by exploiting a feedback loop where user interactions get folded back into future training runs, or through insider access — can implant behavior that's invisible during normal testing but activates under specific conditions.

The defining characteristic that makes this category hard to catch is that a poisoned model can pass every normal evaluation and behave exactly as expected right up until the trigger condition is met. Real mitigations focus on data provenance and lineage tracking for training data, anomaly detection on training pipelines, and — for any system that incorporates user feedback into retraining — rate-limiting and validating that feedback loop so a small number of malicious actors can't disproportionately influence future model behavior.

LLM05: Improper Output Handling

This is one of the categories most directly borrowed from classic web security, and one of the most consistently underestimated. If an application takes an LLM's output and passes it downstream — into a database query, a shell command, a webpage rendered in a browser, an API call — without validating or sanitizing it first, the model's output becomes exactly as dangerous as unvalidated user input, because from the perspective of everything downstream, that's precisely what it is.

A model that generates HTML which gets rendered directly in a user's browser without escaping creates a stored XSS vulnerability where the LLM is the delivery mechanism. A model whose output gets passed into a system shell or a SQL query without parameterization recreates command injection and SQL injection, except now the attacker doesn't need to craft the malicious payload directly — they just need to convince the model to generate it on their behalf through prompt injection. The fix is the one web developers already know: never trust generated content any more than you'd trust user-submitted content, and apply the same output encoding and validation you'd apply anywhere else in the application.

LLM06: Excessive Agency

Excessive agency is what happens when an LLM-based agent has more autonomy, more permissions, or more unsupervised reach than the task actually requires — and it's the category that becomes exponentially more dangerous as agentic AI systems get deployed with real tool access rather than just generating text. A support agent that can only draft a refund for human approval is a nuisance if compromised. The same agent given the ability to autonomously issue refunds is a direct financial liability.

OWASP breaks this down into three contributing factors worth testing independently: excessive functionality (the agent has access to tools or capabilities it doesn't need for its actual job), excessive permissions (the tools it does need are scoped more broadly than necessary — a database tool with write access when only read access is required), and excessive autonomy (the agent can execute consequential actions without any human checkpoint). Reducing any one of the three reduces the blast radius of a successful prompt injection; a well-designed system minimizes all three by default rather than granting broad access and hoping the model's judgment holds under adversarial pressure.

LLM07: System Prompt Leakage

System prompts routinely contain more than generic persona instructions — they often include business logic, internal tool names and their descriptions, formatting rules that reveal backend architecture, and sometimes credentials or internal URLs that were added carelessly during development. OWASP calls this out as its own category because system prompt extraction is both extremely common (a huge fraction of deployed LLM applications leak their system prompt with only modest effort) and because the consequences scale with what's actually in the prompt.

The core guidance is uncomfortable but important: never put anything in a system prompt that would be a real problem if it became public, because with enough attempts it likely eventually will. Treat the system prompt as a UX and behavior-steering tool, not a security boundary, and enforce any actual security-relevant logic — authorization checks, access control, credential handling — in code the model never sees and can't be talked out of following.

LLM08: Vector and Embedding Weaknesses

As retrieval-augmented generation (RAG) has become the default way to give LLMs access to private or current data, the vector databases and embedding pipelines behind that retrieval have become their own attack surface. This category covers a cluster of related risks: an attacker injecting malicious documents into a vector store so they get retrieved and treated as trusted context for unrelated queries (a form of indirect prompt injection specific to RAG architectures), embedding inversion attacks that attempt to reconstruct the original sensitive text from stored vector representations, and access-control gaps where a multi-tenant RAG system doesn't properly scope which documents a given user's queries are allowed to retrieve from.

Because RAG is often bolted onto an LLM application as a way to reduce hallucination and add proprietary knowledge, the vector store frequently gets far less security scrutiny than the model or the application layer around it — despite being a direct, often unauthenticated pathway for injecting content the model will treat as ground truth.

LLM09: Misinformation

This category covers the model confidently generating false information — hallucination in the colloquial sense — when that output is trusted and acted on without verification. It's listed separately from a pure reliability concern because of how it gets weaponized: an attacker who understands a model's tendency to hallucinate plausible-sounding but nonexistent package names, API endpoints, or citations can pre-register those fabricated names and use them as an attack vector, a technique that's come to be called slopsquatting when it targets software package names a coding assistant hallucinates.

The mitigation isn't "make the model never hallucinate" — that's not currently achievable for any general-purpose model. It's building the application around the assumption that it will: grounding high-stakes outputs in retrieved, verifiable sources rather than the model's parametric memory, surfacing confidence signals and citations to end users, and never wiring a model's unverified output directly into an automated action with real-world consequences.

LLM10: Unbounded Consumption

The final category covers resource exhaustion — an attacker crafting inputs designed to maximize the model's computational cost per request, whether through deliberately long, complex prompts, requests engineered to trigger excessive tool-calling loops in an agentic system, or simple high-volume abuse of an unmetered endpoint. Because LLM inference is meaningfully more expensive per request than a typical web API call, this category has a direct financial dimension that most traditional denial-of-service concerns don't: a sustained abuse campaign against an unprotected LLM endpoint doesn't just degrade availability, it runs up a real, sometimes very large bill, which is why this pattern gets specifically called out as a denial-of-wallet attack rather than just a denial-of-service one.

Rate limiting, per-user quotas, request complexity limits, and hard caps on agentic loop iterations (so a confused or manipulated agent can't call the same expensive tool in an unbounded retry loop) are the standard mitigations, and they're worth implementing even for applications that don't consider themselves a likely target — cost-based attacks don't require any sophistication beyond volume.

How it relates to the original web application Top 10

It's worth being explicit about which categories are genuinely new and which are old vulnerability classes wearing a new costume, because the distinction changes how a security team should staff and scope testing for them. Improper output handling (LLM05) is, almost exactly, the classic injection family — XSS, SQL injection, command injection — with the LLM sitting in the role previously occupied by unvalidated user input. A team with strong existing web application security skills can pick this category up quickly, because the underlying defense (never trust generated content, validate and encode before it reaches a sensitive sink) is a direct transfer of knowledge they likely already have.

Supply chain risk (LLM03) is similarly a direct extension of software supply chain security, just applied to models, datasets, and fine-tunes instead of npm packages and container images — the mental model of verifying provenance and treating third-party components with proportionate suspicion transfers directly, even though the specific tooling to do that verification for AI artifacts is much less mature than the equivalent tooling for traditional software dependencies.

Prompt injection (LLM01), excessive agency (LLM06), and system prompt leakage (LLM07), by contrast, have no clean precedent in the original list. They exist specifically because LLMs process instructions and data through the same channel, and because agentic systems grant models real-world capabilities that a traditional web form field never had. These are the categories where a team with only traditional web application security experience is most likely to have a genuine, non-obvious gap — not because they lack general security instinct, but because the underlying architecture they're used to reasoning about simply doesn't have an equivalent attack surface to build intuition from.

How the list actually gets used in a real assessment

In practice, a mature AI security assessment doesn't just check off ten boxes — it uses the ten categories as an organizing structure for a much larger set of specific test cases, then maps each finding back to the relevant category for reporting purposes. A single engagement might run dozens of distinct prompt injection variants (direct, indirect, encoded, multi-turn) all reporting under LLM01, while a single excessive-agency finding might require mapping out the actual tool permissions granted to an agent and testing each one independently for whether it's scoped more broadly than the task requires.

This is also where the categories interact rather than staying neatly separate. A successful prompt injection (LLM01) that reaches an agent with excessive agency (LLM06) and no output validation (LLM05) doesn't produce three separate low-severity findings — it produces one critical-severity finding that happens to touch three categories simultaneously, and a report that just lists three separate line items without connecting them misses the actual risk story. Understanding how these categories compound against each other, not just testing each one in isolation, is what separates a checklist exercise from a real adversarial assessment.

Why this list is a floor, not a ceiling

The OWASP Top 10 for LLM Applications is deliberately the ten most common, highest-impact categories — not an exhaustive taxonomy of every way an AI system can be compromised. MITRE ATLAS, by comparison, catalogs roughly 170 distinct techniques at a much finer granularity, and new technique classes get published in academic research on a rolling basis. Treating OWASP's list as complete coverage is the same mistake as treating the original web application Top 10 as a complete penetration test scope — it's the minimum bar, not the whole assessment.

What the list is genuinely good for is structuring a conversation: when evaluating a vendor's AI security assessment, or scoping your own internal red-team exercise, walking through each of these ten categories and asking "did we actually test this, and how" surfaces gaps that a vaguer, less structured review would miss. It won't catch everything on its own. It will catch the most common ways real AI applications actually get compromised in production, which is exactly what it was built to do.

How often the list actually changes, and why that matters

Unlike the original web application Top 10, which has revised on a roughly three-to-four-year cadence reflecting how slowly the underlying web platform itself changes, the LLM-focused list has already seen meaningfully faster revision, reflecting how quickly the underlying technology and its failure modes are still evolving. Categories have been renamed, split, and reprioritized between versions as the community's collective understanding of what actually causes real-world incidents has matured — early versions weighted some categories differently than current guidance does, based on which risks turned out to matter most once organizations had more production deployment experience to draw on.

That pace of change is itself useful information for anyone relying on the list to scope an assessment: treating a specific version of this taxonomy as a permanent, unchanging reference point is a mistake the field's own revision history argues against. A credible AI security practice checks which version of the list a given assessment or report is referencing, and stays current with revisions the same way a mature application security program stays current with the standard web application Top 10 rather than testing against a decade-old version out of habit.