The OWASP Top 10 LLM Applications list ranks the ten most critical security risks in software built on large language models. The 2025 edition covers prompt injection, sensitive information disclosure, supply chain weaknesses, data and model poisoning, improper output handling, excessive agency, system prompt leakage, vector and embedding weaknesses, misinformation and unbounded consumption.Large language models now sit inside support bots, coding assistants, search tools and internal copilots. Each deployment adds an attack surface that traditional scanners were never designed to understand. The OWASP Top 10 LLM Applications list gives builders and testers a shared vocabulary for that surface and this guide walks through every item with plain language definitions, realistic attack examples and practical fixes.If you already know the webfocused ranking, think of this list as its sibling. The classic OWASP Top 10 for web applications ranks flaws such as broken access control and injection, while the LLM edition ranks risks that appear once a probabilistic model is wired to data, tools and users. For a shorter reference page, see our OWASP Top 10 for LLM Applications overview.

What Is the OWASP Top 10 for LLM Applications?

The OWASP Top 10 for LLM Applications is a ranked awareness document that describes the most serious security risks in software using large language models. It is maintained by the OWASP Gen AI Security Project, a volunteer community of practitioners, researchers and vendors. The project first published a list in 2023 under the title OWASP Top 10 for Large Language Models and then released the OWASP LLM Top 10 2025 edition after a year of incident reports and community feedback.The list is not a compliance standard and it is not a scanner checklist. Its value is that it names failure patterns clearly enough for developers, architects and testers to discuss them in the same words. Teams use it to shape design reviews, write abuse cases, build test plans and justify budgets for AI features. Because the project also publishes material under names such as OWASP Top 10 Generative AI and OWASP GenAI Security Top 10, you will see the same ten risks discussed under several labels.

What Changed Between the 2023 and 2025 Lists

Several names from the original list still appear in older tutorials and search results, so it helps to map them to the current ones. Insecure Output Handling became Improper Output Handling. Training Data Poisoning widened into Data and Model Poisoning. Model Denial of Service grew into Unbounded Consumption, which also covers runaway cost and model theft. Two entries are new System Prompt Leakage and Vector and Embedding Weaknesses, both driven by the rise of retrieval/augmented generation and agent frameworks. Misinformation replaced the earlier Overreliance entry.Next, convert each abuse case into a test and a control. If you want to build the habit with realistic exercises, our threat modeling practice article offers a structured way to rehearse. 

LLM01 Prompt Injection

Prompt injection occurs when crafted input changes how a model behaves. In a direct attack, a user types instructions that override the developer's intent. In an indirect attack, the instructions hide inside content the model reads later, such as a web page, an email, a PDF, or a support ticket. The model cannot reliably separate instructions from data, so no single filter solves the problem.A realistic example is an email assistant that summarizes an inbox. A message containing hidden text can steer the assistant into forwarding other messages. Strong defenses combine several layers, limit what the model can do, mark untrusted content clearly, constrain output formats, require human approval for sensitive actions and test with adversarial inputs regularly. To see the mechanics in detail, read our walkthrough of a real prompt injection attack.

LLM02 Sensitive Information Disclosure

Models can reveal personal data, credentials, proprietary documents, or business logic. The leak may come from training data, from the context window, or from tools the model can call. A common failure is a support assistant that summarizes a ticket belonging to a different customer because the retrieval layer ignored tenant boundaries.Defenses start with data minimization and do not give the model data it does not need. Sanitize data before training or finetuning, enforce access control outside the model rather than trusting instructions inside the prompt, apply output filtering for obvious patterns such as keys and identifiers and isolate tenants at every layer. Treat the model as an untrusted component that can repeat anything it has seen.

LLM03 Supply Chain

An LLM application depends on pretrained models, adapters, datasets, embedding services, plugins and ordinary software packages. Any of them can be tampered with. Some model formats rely on serialization that can execute code when loaded, which makes this risk a close cousin of insecure deserialization in conventional software.

Verify the provenance of every model and dataset, check hashes, prefer safe file formats, pin versions and scan artifacts before use. Maintain an inventory of models, datasets and plugins in the same way you track software dependencies, so you can respond quickly when a component is reported as compromised. Licensing and data usage terms belong in this review too.

LLM04 Data and Model Poisoning

Poisoning means manipulating pretraining data, fine tuning data, or embeddings to plant backdoors, bias, or degraded behavior. An attacker who can influence a public dataset, a feedback loop, or a shared document store may change how the model responds to a specific trigger phrase while it behaves normally everywhere else.Track data lineage so you know where each sample came from, validate sources and use anomaly detection on training sets. Run fine tuning in a controlled environment, keep a heldout evaluation set that attackers cannot influence and red team the tuned model for unexpected behavior before release. For retrieval systems, remember that every ingested document is effectively training data for the answer.

LLM05 Improper Output Handling

Improper output handling happens when downstream code trusts what the model produces. If output is rendered in a browser, passed to a shell, or concatenated into a database query, the model becomes a path for crosssite scripting, command execution and other classic flaws. This is the older Insecure Output Handling category under a more precise name.

The rule is simple: treat model output exactly like untrusted user input. Encode it for its context, validate it against a strict schema and use parameterized queries and safe APIs. If you want to see how stringbuilt queries go wrong, our guide to injection attacks explains the defenses and you can practice the underlying skill in a handson SQL injection lab.

LLM06 Excessive Agency

Excessive agency appears when a model driven system has more functionality, permissions, or autonomy than its task requires. An email assistant that only needs to draft replies but also has permission to delete messages is a textbook case. When prompt injection or a plain model error occurs, the extra power turns a nuisance into an incident.Apply least privilege to every tool. Expose narrow functions rather than open ended ones, run actions with the permissions of the requesting user rather than a shared service account and require explicit confirmation for irreversible steps. Shared service accounts also recreate the pattern described in our article on insecure direct object references, where a caller reaches records it never should have seen.

LLM07 System Prompt Leakage

System prompts often contain business rules, tone guidance and sometimes API keys or internal URLs. Attackers can coax a model into repeating them. The leak matters less when the prompt holds harmless style instructions and a great deal more when it holds secrets or the only copy of a security rule.Never store credentials in a prompt. Enforce authorization, rate limits and content policy in application code that the model cannot override. Assume the prompt will eventually be read and designed so that reading it gives an attacker nothing useful. Monitoring for extraction attempts is helpful, but removing the sensitive content is better.

LLM08 Vector and Embedding Weaknesses

Retrieval augmented generation relies on vector databases and embedding pipelines. Weak access control at retrieval time can expose documents to users who should not see them. Poisoned documents can steer answers and embeddings themselves can sometimes leak information about the text they represent.

Apply document level permissions when you query, not only when you ingest. Partition data by tenant, validate and review content before it enters the index and log what was retrieved for each answer. The infrastructure around the vector store deserves the same attention as any data service, so follow established cloud security best practices for networking, secrets and encryption.

LLM09 Misinformation

Models produce fluent text whether or not it is true. Fabricated citations, invented legal references and confident but wrong technical advice can cause real harm when users or downstream systems accept them without checking. In software work, models may even suggest packages that do not exist, which attackers can then register and weaponize.Ground answers in verified sources, show citations users can check and design workflows so that highstakes outputs get human review. When assistants write code, build a habit of reviewing it carefully; our guide on how to review AI generated code shows what to look for. Communicate limitations plainly in the product itself.

LLM10 Unbounded Consumption

Large models are expensive to run. Without limits, attackers can send oversized prompts, trigger long generations, or loop agents until budgets or capacity run out. This is the successor to Model Denial of Service and it includes denial of wallet, where the goal is a huge bill rather than an outage. Repeated queries can also be used to approximate and copy a model.Set rate limits per user, cap input and output tokens, enforce timeouts and monitor spend with alerts. Restrict how deep agents may recurse and how many tool calls a single request can trigger. Authentication and quotas matter as much here as they do for any public API.

Common Misconceptions About the LLM Top 10

Several myths slow down real progress. The first is that the list only matters for companies training their own models. In practice, most risks apply to anyone who integrates a hosted model, because prompt injection, output handling, excessive agency and data exposure all occur in the application layer around the model. The second myth is that a provider's safety filters make the application safe. Provider safeguards address harmful content in general, while your application has specific data, users and tools that only you can protect.

A third misconception is that the ten items are independent. They interact constantly. A poisoned document in a vector store enables indirect prompt injection, which abuses excessive agency, which produces improper output handling downstream. Reading the list as a chain of linked failures leads to better designs than treating each entry as a separate checkbox. Finally, ranking does not equal priority for your system. A low ranked item may be your biggest exposure if your product depends on it, so let your architecture decide the order of work.

How to Use the List in Your Security Program

A list is only useful when it changes behavior. Start by drawing the data flow of your LLM feature where input enters, what the model can read, which tools it can call and where output goes. Then walk the ten categories against that picture. This is the heart of threat modeling and it turns an abstract ranking into a concrete list of abuse cases for your own system.Finally, revisit the exercise whenever the system gains a new tool, data source, or model version. LLM applications change quickly and a review that was accurate last quarter may be wrong after one new integration.

Conclusion

The OWASP Top 10 LLM Applications list is best read as a map of where trust breaks down when a language model is connected to real data and real actions. Most items share a theme; the model is not a security boundary, so authorization, validation and limits must live in code around it. Learn the ten categories, apply them to your own architecture and revisit them as your system grows. Secure design today is far cheaper than incident response later.Teams that want guided, handson learning across web and AI security can explore the training labs on AppSecMaster.

Frequently Asked Questions (FAQs)

What is the OWASP Top 10 for LLM Applications?

It is a community maintained ranking of the ten most critical security risks in applications that use large language models. It names each risk, explains how attacks work and lists mitigation ideas so developers and security teams can discuss AI risk using shared terms.

What are the OWASP Top 10 LLM vulnerabilities in 2025?

The 2025 list covers prompt injection, sensitive information disclosure, supply chain, data and model poisoning, improper output handling, excessive agency, system prompt leakage, vector and embedding weaknesses, misinformation and unbounded consumption.

How is the LLM list different from the web application Top 10?

The web list focuses on flaws in conventional code, such as broken access control and injection. The LLM list focuses on risks created by model behavior, retrieval pipelines and autonomous tools. Both matter, because an LLM feature still runs inside a normal web stack.

Is prompt injection the same as jailbreaking?

No. Jailbreaking tries to make a model ignore its safety training, usually in a direct chat. Prompt injection manipulates an application by placing instructions in user input or in external content the model reads, with the goal of changing application behavior or reaching data and tools.

Where should a team start when securing an LLM application?

Start with a data flow diagram and a short threat model, then reduce the model's privileges, treat its output as untrusted, enforce access control outside the model and add rate limits. After those basics, build repeatable adversarial tests for each category.