OWASP LLM Top 10 Breakdown for Security Teams

Traditional application security rests on one foundational assumption: inputs and instructions are separate things. SQL injection works because a poorly designed query lets user-supplied data bleed into the structural SQL syntax. XSS works because a browser interprets user-supplied content as executable script. Every classic attack class, at its core, exploits a boundary that was supposed to hold.

LLMs don't have that boundary. Instructions and data arrive in the same channel, in the same medium, natural language, and the model has no reliable mechanism to distinguish between them. When you send an LLM a document to summarize, your instruction and the document's content travel through the same pathway. There is no equivalent of a parameterized query keeping them structurally apart. That single architectural fact cascades into everything else.

The outputs compound this in ways that take some getting used to. LLM behavior is probabilistic. The same prompt can produce meaningfully different responses across runs, not because something broke, but because that's how the system works. Security testing built on deterministic reproducibility (test this input, observe this output, verify the function behaves correctly) doesn't transfer cleanly. It needs rethinking at a fairly fundamental level.

The attack surface also extends in directions traditional web application security never had to consider. Backward into training pipelines, where data ingested months before deployment can shape behavior in production, invisibly. Forward into agent actions, where a compromised model doesn't just return bad text. It takes bad actions. A SQL injection vulnerability affects your database. An agentic LLM vulnerability can propagate through your email system, your file store, your APIs, everything the agent has permission to touch.

Standard controls were built for structured inputs. Web application firewalls pattern-match against known attack signatures. Input validation checks type, length, and format. None of this translates cleanly to free-form natural language, and some of it doesn't translate at all. That's why the 2025 LLM Top 10 sits alongside the classic OWASP Web Top 10, not inside it. It's a parallel threat model for a parallel attack domain, not an extension of the old one.

What changed from 2023 to 2025 and what the changes signal

The 2025 edition isn't a theoretical refresh. The changes track real incidents and the rapid maturation of agentic AI between those two years.

Two entries appear in 2025 that didn't exist as standalone categories before. Vector and Embedding Weaknesses (LLM08) was previously folded into prompt injection, but RAG architectures went mainstream fast enough that the community decided the defenses and the affected teams were distinct enough to warrant separation. System Prompt Leakage (LLM07) was similarly split off after real incidents demonstrated the specific downstream damage: leaked intellectual property, exposed policy logic, disclosed privilege structures that enabled targeted bypass attacks.

Several existing entries expanded in scope. Training Data Poisoning became Data and Model Poisoning (LLM04), deliberately broadened to cover fine-tuning tampering. Model Denial of Service became Unbounded Consumption (LLM10), stretching to include model theft, runaway API costs, and what the community now calls "Denial of Wallet." Two earlier entries were consolidated rather than carried forward: Insecure Plugin Design and standalone Model Theft were absorbed into Supply Chain (LLM03) and Excessive Agency (LLM06). That consolidation is itself a signal. The community decided these weren't distinct categories so much as symptoms of broader structural problems.

Reading the pattern across all of it: the 2025 edition points to where real-world risk is growing fastest. Agentic systems with broad permissions. RAG pipelines with minimal access controls. The vendor and open-source model supply chain. If you're deciding where to concentrate security investment in AI applications over the next two years, those three domains are where the list is pointing.

LLM01. Prompt Injection: the attack that has no clean fix

Prompt injection holds the top position for a reason. OWASP's own assessment is blunt about it: given the stochastic nature of LLMs, there are no foolproof prevention methods. That's not hedging. That is the actual state of the problem, and it's worth sitting with.

The mechanism: because the model processes instructions and data in the same channel, a crafted input gets interpreted as a new instruction rather than content. Direct injection is what most people encounter first, a user typing something that overrides the system prompt. Indirect injection is the variant that actually keeps security teams up at night. Malicious instructions embedded in external content (a document the model retrieves, a webpage it browses, an email it reads on an agent's behalf) get processed as legitimate model input. The model has no mechanism to distinguish the document's instructions from yours. Multimodal injection extends this further still: hidden instructions embedded in images processed alongside text.

The practical split that matters for enterprise deployments is this. Direct injection gets the most attention in demos and research papers. Indirect injection is the threat that matters most when your LLM application is ingesting documents, searching the web, or reading emails. If your deployment involves retrieval or browsing, indirect injection is the operationally relevant variant, and it deserves correspondingly more mitigation effort.

Defense has to be layered because no single control is sufficient. Input sanitization, context isolation, privilege separation, constraining model behavior through system prompts, defining expected output formats, segregating external content from instructions: none of these eliminate the risk individually. Together they reduce it. That reframe (from "find the fix" to "stack the layers") is where most teams need to arrive before they can have a productive conversation about this one.

LLM02. Sensitive Information Disclosure: why this jumped from sixth to second

The jump from sixth in 2023 to second in 2025 is the most dramatic ranking shift on the list. That kind of movement doesn't happen because of theoretical reassessment. It happens because incidents accumulated and the community recalibrated in response.

The mechanism: LLMs can memorize and reproduce fragments of their training data, including personally identifiable information, proprietary business data, confidential documents. Researchers have demonstrated techniques for extracting memorized training data through targeted queries. These extractions have actually happened, which matters for how seriously to take the risk.

The categories of exposure are concrete. PII surfacing in completions. Proprietary algorithms reproduced in response to probing queries. Confidential business logic exposed through carefully constructed prompts. System configuration details leaked through inference. Mitigations stack in layers: data sanitization before inputs reach the model, strict access controls on which agents and users can query which models, differential privacy applied during training to reduce the influence of any single data point, PII filtering at the gateway.

Here is the part that gets less attention than it should, particularly for teams deploying vendor AI products. If the vendor's model was trained or fine-tuned on data you supplied, you have limited visibility into what the model has memorized, or whose queries will surface it. The question most teams ask their vendors is "is the data encrypted in transit?" The more important question is "what can be extracted from the model after training?" Those are very different questions, and the gap between them represents real exposure.

LLM03. Supply Chain: how a compromised model on a public hub becomes your problem

Supply chain risk jumped from fifth to third and absorbed the former standalone Insecure Plugin Design entry. The expansion of scope explains the movement.

Traditional software supply chain risk concerns libraries and dependencies. You pull a package, it carries a vulnerability or a malicious payload, that payload runs in your environment. The LLM supply chain extends that logic in both directions. Pre-trained models, fine-tuning datasets, and the serialization libraries used to load those models all represent intake points. A compromised model on a widely used public hub can affect thousands of downstream applications, each inheriting whatever manipulation was introduced upstream, with no obvious indication at deployment time.

New fine-tuning methods, LoRA and PEFT among them, appear explicitly in the 2025 edition as newly relevant attack surfaces. Fine-tuning on an externally sourced dataset is, by definition, a supply chain intake event. The 2023 list didn't address this at the same granularity, because the practice wasn't as widespread then. The list moved because the world moved.

The library-level risks are concrete and familiar to anyone from traditional application security. CVE-2024-3660 in TensorFlow's Keras allowed arbitrary code injection. PyTorch's use of Pickle for model serialization introduces deserialization risks that will immediately register for anyone who has dealt with Java deserialization vulnerabilities. On-device LLM deployments add another dimension entirely: models leave the controlled cloud environment, broadening the surface in ways that are genuinely difficult to monitor.

Mitigations look like good software supply chain hygiene applied to model artifacts. Verified sources, signed artifacts, dependency scanning, runtime monitoring for unexpected model behaviors. The practices aren't novel; applying them to this class of artifact is the work.

LLM04. Data and Model Poisoning: the backdoor that waits

The scope expansion from "Training Data Poisoning" to "Data and Model Poisoning" is the most important thing to understand about this entry. Fine-tuning is now as significant a poisoning vector as pre-training datasets, and fine-tuning is what most organizations actually do with open-source models. This isn't an edge case; it's the predominant deployment pattern.

The core mechanism is an integrity attack. The attacker's goal isn't access to the model; it's corrupting what the model believes or how it behaves, in a way that persists quietly into production. A poisoned dataset shapes behavior without generating an alert, without writing to an access log, without producing anything detectable at the network layer.

The sleeper agent variant is what makes this one genuinely concerning. A backdoor can be designed to activate only when specific trigger inputs appear; without those triggers, the model behaves normally through evaluation and testing. The poisoned behavior can sit dormant for months, surviving deployment reviews and performance benchmarks, until the trigger conditions appear in production. You wouldn't know it was there from functional testing alone, which is exactly the point.

The sharpest exposure here is for organizations fine-tuning open-source models using externally sourced datasets. That's a specific description, but it maps onto a substantial fraction of real enterprise AI deployments right now. Mitigations include vetting all data sources used in training and fine-tuning, anomaly detection against training data, differential privacy during training, and adversarial testing specifically designed to probe for poisoning-style behavioral manipulation. That last item is consistently underpracticed. Most teams test for functional accuracy. Far fewer test for dormant behavioral manipulation. Those are not the same test.

LLM05. Improper Output Handling: when the model's response becomes the attack payload

This entry is where AI-specific risk and classical application security meet most directly. The vulnerability classes are familiar: XSS, SQL injection, remote code execution. What's new is the source of the untrusted input.

When an LLM-generated output is passed to a downstream system without validation, that output becomes a potential attack payload. The model can generate a SQL fragment that gets executed directly. It can generate JavaScript that gets rendered in a browser. It can generate a shell command that runs without sanitization. The attack classes are old. The trust failure that enables them is new.

The specific failure pattern: teams with strong input validation habits sometimes forget those habits apply equally when the input to their downstream system originated from their own LLM. There's an implicit assumption that internal components are trusted. An LLM is not a trusted source in the security sense. It's an inference engine whose outputs are shaped by whatever influenced its training and whatever manipulation was applied to its prompt. Treating its outputs as trusted internal data is the mistake this entry is describing.

Mitigations are straightforward for anyone with traditional application security experience. Output validation before passing anything to a downstream system. Parameterized queries even when the query originated from the model. Sandboxing for any code execution triggered by model output. Content security policies for rendered output in browser contexts. The controls aren't exotic; the discipline is applying them consistently to LLM-generated content rather than exempting it.

LLM06. Excessive Agency: what happens when an agent can do more than it should

This is one of the most significantly expanded entries in the 2025 edition, and its expansion tracks the growth of agentic deployments directly. It also absorbed the former Insecure Plugin Design entry, because plugin design failures are largely the same structural problem wearing different clothes.

OWASP identifies three root causes. Excessive functionality: agents given access to tools beyond what their task actually requires. Excessive permissions: those tools operating with broader privileges than the task demands. Excessive autonomy: high-impact actions proceeding without a human checkpoint. The scenarios that follow from these aren't hypothetical. An agent with email access, tricked through prompt injection, sends phishing messages to contacts. An agent with database write access, manipulated through an indirect injection in a retrieved document, deletes records. The agent didn't decide to do these things maliciously; it followed instructions it couldn't distinguish from legitimate ones.

That's the critical relationship between Excessive Agency and Prompt Injection. The exploit path typically runs through injection. An indirect injection attack is often what triggers the agent to misuse its permissions. These two entries aren't independent in practice; they compound each other. An agent with minimal permissions is far less dangerous when injected than an agent with broad ones.

Mitigations center on least-privilege design: limit LLM access to only the operations the task actually requires, require human-in-the-loop checkpoints for high-impact or irreversible actions, apply granular privilege controls scoped to the task rather than the agent's theoretical maximum capability, log all agent actions, build fail-safe mechanisms that can interrupt unauthorized action sequences. Anyone who has worked on service account security will recognize the architecture. The difference is that agents can be manipulated through natural language in ways service accounts cannot.

LLM07. System Prompt Leakage: why treating the system prompt as a secret is itself a vulnerability

This entry was added in 2025 after real incidents demonstrated that attackers could extract system prompts containing internal rules, filtering criteria, permission structures, and decision-making logic. Once an attacker has that, bypass attacks become substantially easier. They know exactly what the model has been instructed to refuse, allow, or prioritize.

OWASP's guidance here surprises people when they first encounter it, because it redirects the concern. The vulnerability isn't primarily that the prompt leaks. The vulnerability is that teams designed security functions into the prompt and assumed it would stay hidden.

Consider what that actually means. If your system prompt is doing privilege separation (if it is the mechanism by which user A gets different access than user B), then you've implemented a security control in natural language instructions to a probabilistic inference engine. That's not a security control; it's a description of what you'd like the security control to do. Natural language is not an enforcement mechanism. A model that has been told "only respond to users who provide code X" can be manipulated, tricked, or fine-tuned out of that behavior in ways a properly implemented authorization check cannot.

OWASP's explicit guidance: do not rely on the system prompt's secrecy for privilege separation or authorization. Design prompts so that their disclosure causes no meaningful harm. Authorization and privilege separation belong at the infrastructure level, with the system prompt serving as context, not as the control itself. Once teams genuinely internalize that principle, the leakage problem largely resolves. If the prompt contains nothing an attacker would find valuable, extracting it produces nothing useful.

LLM08. Vector and Embedding Weaknesses: the RAG pipeline's own attack surface

This entry is new to 2025, and its addition is a direct consequence of how quickly RAG architectures became the dominant deployment pattern for enterprise LLM applications. The attack vectors, the defenses, and the teams responsible are sufficiently distinct from prompt injection that a separate entry was warranted.

Three distinct vectors fall under this category. Vector database poisoning: injecting malicious content into the retrieval store so it surfaces during legitimate queries, effectively a form of indirect injection operating at the data layer rather than the prompt layer. Insufficient access controls on vector stores: sensitive data exposed across tenant boundaries when multiple users or applications share a retrieval index without per-tenant partitioning. Embedding model manipulation: tampering with the embedding model itself to produce misleading similarity results, which degrades the trustworthiness of everything the RAG system retrieves, not just specific queries.

The third vector deserves more attention than it typically gets. If the embedding model is producing corrupted similarity scores, the RAG system will confidently retrieve and surface wrong content while appearing to function normally. That degradation can be genuinely difficult to distinguish from ordinary model imprecision. It doesn't announce itself.

Mitigations center on treating ingestion as a trust boundary: controls on what content is permitted to enter the vector store, strict per-tenant access controls on retrieval, and scrutiny applied to the embedding model itself as a supply chain component. Teams that have invested in securing their RAG pipeline's retrieval logic sometimes overlook the ingestion path entirely. That's where this attack class lives, and overlooking it leaves a significant gap.