A customer support chatbot answers a question it was never trained to answer, using a document an attacker pasted into the chat window an hour earlier. A coding assistant executes a shell command hidden inside a code comment on GitHub. A model quietly repeats a customer’s credit card number back to a different customer in the same session.
None of these are bugs in the traditional sense. No buffer overflowed, no SQL statement got concatenated wrong. The system worked exactly as its designers built it to work, and that is the problem.
Large language model applications break in ways that do not map cleanly onto the vulnerability classes security teams have spent two decades learning to defend against. The OWASP Top 10 for LLM Applications exists because of that gap. This article is the pillar for a series that walks through the list one category at a time. It sets up the shared vocabulary; each entry below links forward to the deep dive that follows it.
WHY LLM APPLICATIONS NEED THEIR OWN THREAT LIST
Traditional web application security assumes a fairly stable boundary between code and data. SQL injection happens because user input gets treated as executable syntax instead of a string value. Cross-site scripting happens because untrusted input gets rendered as HTML instead of text. Once a team understands that boundary, most of the OWASP Web Top 10 becomes a checklist of places where the boundary got blurred.
An LLM does not have that boundary. Instructions and data both arrive as natural language, in the same channel, at the same time. The system prompt telling the model to behave like a helpful assistant, and the customer’s message asking it to summarize a document, are both just tokens.
The model has no reliable way to tell which tokens are commands it must obey and which are content it should merely process. That single structural fact is the root of most items on the OWASP LLM list.
A second difference matters just as much. Traditional software is deterministic: the same input produces the same output, which makes testing and patching tractable. LLMs are probabilistic.
The same prompt can produce different outputs on different runs. A fine-tuning update or a system prompt change can reduce a vulnerability’s frequency without eliminating it, which forces security teams accustomed to a clear patched-or-not-patched state to adjust their expectations.
THE OWASP TOP 10 FOR LLM APPLICATIONS
The OWASP Foundation, the same nonprofit behind the widely used Web Application Top 10, launched a dedicated project for large language model applications in 2023. A community of several hundred security researchers, machine learning engineers, and industry practitioners built the first version and refined it into v1.1 later that year. The list draws on real incidents, red-team findings, and academic research into how deployed LLM systems actually fail in production.
The ten categories below are the version this series follows. Each one gets its own deep-dive article later in the series, with concrete examples and layered mitigations. This entry defines the boundary of each category and explains why it earned a place on the list.
1. PROMPT INJECTION
Prompt injection is the manipulation of a model’s behavior through crafted input that overrides or subverts its original instructions. Direct injection happens when a user types the malicious instruction straight into the chat box. Indirect injection is the more dangerous variant: the instruction arrives embedded in a document, a web page, an email, or a code comment that the model processes on someone else’s behalf, with no direct interaction from the attacker at all.
Because instructions and data share one channel, this vulnerability has no complete fix, only layers of mitigation. It is consistently ranked as the top LLM risk and gets the first full deep dive in this series.
2. INSECURE OUTPUT HANDLING
Insecure output handling occurs when an application passes an LLM’s output downstream without validation or sanitization, the same mistake that causes SQL injection and XSS in traditional applications, just one hop later in the pipeline. If a model’s response gets rendered directly as HTML, passed to a system shell, or used to construct a database query, the model itself becomes an attack vector even when its input was clean.
The category matters because teams frequently trust model output more than they trust user input, despite the two having the same provenance problem from a security standpoint.
3. TRAINING DATA POISONING
Training data poisoning is the introduction of manipulated or malicious data into a model’s training, fine-tuning, or embedding pipeline, with the goal of introducing backdoors, biases, or degraded behavior that surfaces only under specific trigger conditions. Because most large models train on scraped or crowdsourced data, the attack surface for poisoning extends well beyond an organization’s own infrastructure.
A poisoned model can pass every ordinary evaluation and still behave maliciously the moment it sees a trigger phrase an attacker chose in advance.
4. MODEL DENIAL OF SERVICE
Model denial of service covers attacks that consume excessive resources relative to the input size, degrading service quality or driving up cost for the application owner. Context-window exhaustion, recursive or unbounded generation requests, and adversarial inputs engineered to maximize compute per token all fall under this heading.
Unlike classic denial-of-service attacks that saturate bandwidth, this category often looks like normal traffic. A handful of carefully crafted requests can cost as much as thousands of ordinary ones.
5. SUPPLY CHAIN VULNERABILITIES
Supply chain vulnerabilities affect the full lifecycle of components an LLM application depends on: pretrained models teams pull from public hubs, fine-tuning datasets, plugins, and the software libraries that glue everything together. A compromised model checkpoint or a poisoned open-source dataset can carry a vulnerability into an organization the same way a compromised npm package does, except the payload sits inside billions of numeric weights instead of readable source code.
This category gets its own pillar article later in the series, since the AI supply chain has grown wide enough to need dedicated treatment.
6. SENSITIVE INFORMATION DISCLOSURE
Sensitive information disclosure happens when an LLM reveals confidential data through its output: personal information memorized from training data, proprietary details from a retrieval-augmented knowledge base, or secrets leaked from another user’s session. Models trained or fine-tuned on data containing personal or proprietary information can reproduce that information verbatim under the right prompting, even when no one intended it to be retrievable.
7. INSECURE PLUGIN DESIGN
Insecure plugin design describes LLM plugins and tool integrations that accept free-form natural language input without proper validation, access control, or scoping of the actions they can perform. A plugin that lets a model send emails, run code, or query a database becomes a serious liability the moment the model itself can be tricked, through prompt injection or otherwise, into misusing that plugin.
8. EXCESSIVE AGENCY
Excessive agency refers to systems granted more autonomy, permissions, or functionality than the task actually requires. An agent connected to a file system, a payment API, or an email account with full read-write access, when read-only or scoped access would suffice, is an excessive agency problem waiting for a triggering prompt.
As autonomous agents become a standard architecture pattern rather than a research curiosity, this category has grown from a minor concern into one of the more consequential items on the list.
9. OVERRELIANCE
Overreliance is the failure mode where users or systems trust LLM output without adequate oversight, verification, or understanding of its limitations. Hallucinated citations, fabricated API calls, and confidently stated wrong answers all cause real damage only because something downstream, a human or another system, accepted the output at face value.
This category connects directly to a companion post in the learning series on this site, which covers the cognitive-offloading side of the same problem.
10. MODEL THEFT
Model theft covers unauthorized access to, copying of, or extraction of proprietary model weights and architecture. Attackers can steal a model outright through infrastructure compromise, or reconstruct a close approximation of it through systematic querying, a technique known as model extraction.
For any organization whose model is the product, this category is a direct threat to competitive advantage and not merely a data-handling concern.
WHY THE LIST KEEPS CHANGING
OWASP revised the LLM Top 10 again in 2025, merging some categories, splitting others, and adding new entries such as system prompt leakage and vector and embedding weaknesses that reflect the rise of retrieval-augmented generation and agentic architectures. This series follows the 2023 v1.1 taxonomy above because it maps cleanly onto ten distinct deep-dive articles and because most production incidents documented so far still fall neatly into these ten buckets. Later posts in the series note where the 2025 revision reclassifies or renames a given risk.
The list changing is itself informative. A field that revises its own top risks within two years is a field still discovering how its systems fail. Static top-ten lists work for slow-moving categories like memory corruption. LLM security is not yet a slow-moving category.
HOW THIS SERIES IS ORGANIZED
Each of the ten categories above becomes its own article, in most cases matched one-to-one. This series groups sensitive information disclosure, insecure plugin design, and excessive agency into a single combined post given their overlapping mitigation strategies.
Three hands-on lab posts follow, walking through a live prompt injection, a data-extraction scenario, and a hallucination test bench. The series then widens into MLSecOps, the AI supply chain, threat modeling with STRIDE, and governance frameworks including the EU AI Act and NIST’s AI Risk Management Framework.
The goal across all twenty planned entries is the same one this article states first: LLM applications fail differently than the software that came before them, and defending them starts with naming the failure modes precisely.
T.
References
- OWASP Top 10 for LLM Applications - The official OWASP project page hosting the LLM Top 10 list, versioned releases, and supporting documentation this series follows.
- OWASP Top 10 for LLM Applications v1.1 (PDF) - The full 2023 v1.1 document defining each of the ten categories covered in this article.
- OWASP GenAI Security Project - The successor initiative covering the 2025 revision of the list and broader generative AI security guidance.
- MITRE ATLAS - A knowledge base of adversary tactics and techniques against AI systems, referenced throughout this series for real-world attack case studies.
- NIST AI Risk Management Framework - The US government framework for managing risk across the AI system lifecycle, discussed in the governance article later in this series.
- On the Dangers of Stochastic Parrots (Bender et al., 2021) - Foundational research on the risks of large language models trained on uncurated data, relevant background for the training data poisoning entry.
