OWASP LLM Top 10 Explained: Risks and Fixes

The OWASP Top 10 for LLM Applications is the industry-standard checklist for securing generative AI systems. It ranks the ten most critical risks, from prompt injection to unbounded consumption, and pairs each with concrete architecture, testing, and monitoring controls that teams can apply before shipping an LLM feature.

OWASP LLM Risk	Primary Failure Mode	Buying Criteria: What to Look For in Tooling
LLM01: Prompt Injection	Attacker text overrides system instructions	Input/output filtering, instruction-data separation, spotlighting
LLM02: Sensitive Information Disclosure	Model leaks secrets, PII, or training data	PII redaction, output scanning, context minimization
LLM03: Supply Chain	Compromised model, dataset, or plugin dependency	Model provenance, SBOM for AI, signed artifacts
LLM04: Data and Model Poisoning	Training or fine-tuning data manipulated	Data lineage tracking, anomaly detection on training sets
LLM05: Improper Output Handling	Unvalidated output triggers downstream execution	Output sandboxing, schema validation, encoding controls
LLM06: Excessive Agency	Agent takes unintended, over-scoped actions	Least-privilege tool grants, human approval gates
LLM07: System Prompt Leakage	Confidential instructions extracted by users	Secrets kept out of prompts, leakage testing
LLM08: Vector and Embedding Weaknesses	RAG retrieval poisoned or cross-tenant leakage	Access-controlled vector stores, embedding integrity checks
LLM09: Misinformation	Confident, plausible, false output (overreliance)	Grounding/citation enforcement, confidence signaling
LLM10: Unbounded Consumption	Resource exhaustion or denial of service via cost/compute	Rate limiting, token budgeting, circuit breakers

Why the OWASP Top 10 for LLMs Matters for Buyers and Builders

Every enterprise that ships a chatbot, copilot, or autonomous agent is now, whether it acknowledges it or not, running a piece of internet-facing infrastructure with a fundamentally different threat model than a traditional web application. Large language models accept unstructured natural language as their primary input, blend instructions and data in the same channel, and increasingly hold the keys to real tools: email, databases, code execution, payment systems. The Open Worldwide Application Security Project (OWASP) responded to this shift by convening security researchers, machine learning engineers, and red teamers into the OWASP Top 10 for LLM Applications project, a living document that catalogs the most consequential risks in production LLM systems and, crucially, tells practitioners what to actually do about them.

This guide is written as a buying and build checklist. If you are evaluating a vendor’s AI security posture, briefing a board on generative AI risk, or deciding which guardrail product to purchase, the ten categories below are the criteria that matter. Each one includes the underlying mechanism, a realistic scenario, and the practical control that should show up in a vendor’s architecture diagram or your own design review.

The Ten Risks, With Practical Guidance for Each

LLM01: Prompt Injection

Prompt injection remains the number one risk for a second consecutive edition of the list, and for good reason: it is the root cause behind most other LLM incidents you read about. Because a model cannot cryptographically distinguish between “trusted developer instructions” and “untrusted user or document content,” an attacker who can influence any text that lands in the context window can potentially redirect the model’s behavior. This includes the classic case of a user typing “ignore previous instructions” directly into a chat box (direct injection), and the more insidious case of malicious instructions hidden inside a web page, PDF, or email that an agent later reads (indirect injection). A well-documented example is CVE-2023-29374, a prompt-injection flaw in LangChain’s LLMMathChain that allowed attacker-controlled input to reach Python’s eval function and achieve code execution.

What to look for: instruction-data separation (spotlighting or delimiter-based tagging so the model can tell developer text from retrieved text), continuous adversarial testing, and a policy that treats every external document, tool result, or plugin output as untrusted input by default. For the deepest treatment of this category, see our dedicated explainer on prompt injection and its direct, indirect, and multi-agent variants.

LLM02: Sensitive Information Disclosure

LLMs can leak information in three ways: by regurgitating memorized training data verbatim, by inferring and stating sensitive facts about a user from contextual clues, or by exposing internal system details (API keys, internal file paths, other users’ conversation history) that ended up in the context window by mistake. This risk is amplified in retrieval-augmented generation (RAG) systems, where a poorly scoped retriever can surface a document the requesting user was never authorized to see.

What to look for: PII detection and redaction on both ingestion and output, strict access-control lists enforced at the retrieval layer (not just at the UI layer), and a default posture of “the model should not see data it does not need for this specific task.”

LLM03: Supply Chain Vulnerabilities

The LLM supply chain is longer and less transparent than a typical software supply chain. It includes the base model weights, the fine-tuning datasets, third-party plugins, LoRA adapters downloaded from public model hubs, and the vector database libraries that power retrieval. A compromised or backdoored model checkpoint, a malicious dependency in a plugin package, or a poisoned public dataset can all introduce vulnerabilities long before a single line of application code is written.

What to look for: model and dataset provenance documentation, checksum or signature verification for downloaded weights, a software bill of materials that explicitly covers AI components, and vendor transparency about where training data originated.

LLM04: Data and Model Poisoning

Historically listed separately as training data poisoning, this category has been broadened to cover manipulation across the entire model lifecycle: pretraining data, fine-tuning data, embedding data used for RAG, and even reinforcement-learning-from-human-feedback signals. An attacker who can inject a small number of carefully crafted examples into a training or fine-tuning set can implant a backdoor trigger, degrade accuracy on specific inputs, or bias outputs in a way that is invisible during normal evaluation.

What to look for: data lineage and versioning for every dataset used in training or fine-tuning, anomaly detection over training corpora, and holdout evaluation sets specifically designed to catch backdoor triggers. Our companion piece on data poisoning attacks on training pipelines goes deeper into detection techniques.

LLM05: Improper Output Handling (Insecure Output Handling)

This is the mirror image of prompt injection: instead of attacking what goes into the model, it concerns what happens to what comes out. If an application passes LLM output directly into a shell command, a SQL query, a browser DOM (via innerHTML), or another downstream system without validation, the model effectively becomes an attacker-controlled input generator. This can enable cross-site scripting, server-side request forgery, or remote code execution, especially in agentic systems where the model’s output is a tool call rather than plain text.

What to look for: strict output schema validation, sandboxed execution environments for any code or command the model generates, context-aware output encoding, and treating model output with the same skepticism as user input.

LLM06: Excessive Agency

As LLMs gain “hands” in the form of tool calls, API access, and multi-step planning, the damage from a single hallucination or successful injection scales with how much the agent is allowed to do. Excessive agency occurs when an agent has more permissions, autonomy, or functionality than a task actually requires, so that a single bad decision cascades into a real-world action: deleting files, sending money, or emailing confidential data to an external address.

What to look for: least-privilege tool scoping (read-only where possible), human-in-the-loop approval for high-impact actions, and sandboxed execution for anything the agent can trigger. This is the category most directly addressed by agent sandboxing architectures, which isolate what an agent’s tools can actually touch.

LLM07: System Prompt Leakage

Developers often embed business logic, internal rules, or even credentials directly into the system prompt on the assumption that users cannot see it. In practice, a sufficiently motivated user can often extract the full system prompt through clever questioning, and once exposed, that logic can be reverse-engineered to bypass filters or replicate the product.

What to look for: a strict rule that secrets and access-control decisions never live only in a prompt string, dedicated leakage testing as part of red-teaming, and architecture that enforces business rules in code rather than relying on the model to “remember” and honor them.

LLM08: Vector and Embedding Weaknesses

Retrieval-augmented generation introduced a new attack surface: the vector database. Weaknesses here include embedding inversion attacks that reconstruct original text from stored vectors, poisoned documents inserted into a shared knowledge base to manipulate future retrievals, and cross-tenant data leakage when multiple customers share a single vector index without proper isolation.

What to look for: tenant-isolated or access-controlled vector stores, integrity checks on ingested documents before embedding, and monitoring for anomalous retrieval patterns that might indicate a poisoning attempt.

LLM09: Misinformation (Overreliance)

Misinformation, which absorbs what earlier guidance called overreliance, describes the risk that an LLM produces confident, well-formed, but factually incorrect output, and that users or downstream systems trust it without verification. This is especially dangerous in domains like legal research, medical triage, or financial advice, where a fabricated citation or invented statistic can look indistinguishable from a correct one.

What to look for: grounding and citation enforcement (the model must point to a verifiable source), confidence signaling in the UI, and workflows that require human verification before high-stakes output is acted upon.

LLM10: Unbounded Consumption (Model Denial of Service)

Unbounded consumption folds together what used to be called model denial of service with a broader concern about runaway resource and cost usage. Because inference is expensive and agentic loops can call tools or the model itself repeatedly, an attacker (or simply a bug) can trigger recursive loops, oversized context windows, or high-frequency requests that degrade service for other users or produce an enormous, unbudgeted bill.

What to look for: per-user and per-session rate limiting, token and cost budgeting with hard circuit breakers, and loop-detection logic in any agent capable of calling itself or other agents.

How a Single Injection Cascades Through an Unprotected LLM Stack

A malicious instruction hidden in a retrieved web page (LLM01) reaches a model with no data/instruction separation, which then calls a tool with excessive permissions (LLM06), passes unvalidated output into a downstream API (LLM05), and exfiltrates data the model should never have seen (LLM02) — four OWASP categories failing in a single chain of events.

Building an OWASP-Aligned Procurement Checklist

Security and product teams evaluating an LLM vendor, a guardrail platform, or an internal build often ask the same question: which of these ten categories should we prioritize first? The honest answer is that priority depends on what the application does, but a few patterns hold consistently across deployments.

Any application that accepts free-text input from an external party must treat LLM01 (prompt injection) and LLM02 (sensitive information disclosure) as day-one requirements, not later hardening.
Any application where model output is executed, rendered as HTML, or passed to another system must elevate LLM05 (improper output handling) to the same priority tier.
Any application where the model can call tools, especially tools with write access, must treat LLM06 (excessive agency) as a design constraint from the first architecture diagram, not a patch applied after an incident.
Any application built on RAG must budget engineering time for LLM08 (vector and embedding weaknesses), since access control at the retrieval layer is frequently overlooked in favor of access control at the UI layer.

Deployment Pattern	Highest-Priority OWASP Categories	Minimum Viable Control
Customer-facing support chatbot	LLM01, LLM02, LLM07	Input/output filtering, system prompt hardening, PII redaction
Internal RAG knowledge assistant	LLM02, LLM08, LLM09	ACL-aware retrieval, citation enforcement, embedding access control
Autonomous multi-tool agent	LLM01, LLM05, LLM06, LLM10	Sandboxed tools, least privilege, human approval, rate limiting
Fine-tuned domain model	LLM03, LLM04	Data lineage, provenance checks, backdoor evaluation sets

From Checklist to Architecture: Defense in Depth

No single control neutralizes any one of these ten risks completely, which is why the OWASP guidance and most mature security teams converge on a defense-in-depth model. Layering matters more than any individual tool: input filtering catches the obvious attacks, instruction-data separation reduces the odds that a filtered attack still succeeds, output validation catches what slips through, least-privilege tool scoping limits the blast radius of anything that does succeed, and monitoring/logging ensures that when something does go wrong, you can reconstruct exactly what happened. Teams that rely on a single guardrail product as their entire security strategy consistently find gaps during red-team exercises; teams that layer controls across the request lifecycle catch far more.

This is also why red-teaming AI systems before launch has become a standard line item in enterprise AI budgets rather than an optional extra. A static checklist tells you what controls should exist; adversarial testing tells you whether they actually work under pressure.

Frequently Overlooked Controls

Instruction-data separationMost teams filter obvious attack phrases but never structurally separate trusted instructions from untrusted retrieved content, leaving the door open to novel injection phrasing.
Retrieval-layer access controlAccess control enforced only at the chat UI does nothing to stop a RAG pipeline from retrieving documents the user was never cleared to see.
Tool permission auditsAgent tool grants are set once during development and rarely revisited as the agent’s responsibilities expand over time.
Cost-based denial of serviceTeams monitor for downtime but overlook the financial denial-of-service risk of an agent stuck in a recursive tool-calling loop.
Machine identity for agentsAgents are frequently issued a single shared service credential instead of individually scoped, auditable identities, which is a growing focus of machine identity at scale programs.
Model version pinningSilent provider-side model updates can shift refusal behavior and guardrail effectiveness overnight, and this is the last item on the frequently overlooked list.

Common mistake

Treating the OWASP Top 10 for LLMs as a one-time compliance checklist rather than a continuous testing program. Teams complete a single review before launch, check the box, and never re-run adversarial tests as the model, prompts, or connected tools change. Because model providers routinely update underlying weights and because attackers continuously develop new injection phrasing, a control that passed testing in January can silently fail by June. The categories in this list should map to a recurring red-team and monitoring cadence, not a launch-day audit.

What worked

Organizations that saw the fastest reduction in incident volume did not start by buying a single “AI security” product. They started by mapping their own architecture against all ten categories, identifying which risks applied to their specific deployment pattern (a support chatbot has a different risk profile than an autonomous coding agent), and then layering targeted controls: instruction-data separation for injection, schema validation for output handling, and least-privilege tool scoping for agency. The checklist became a design document, not an afterthought.

Glossary

Prompt injection: An attack that manipulates an LLM’s behavior by embedding malicious instructions in the input it processes, whether typed directly by a user or hidden in retrieved content.
Guardrails: Programmatic input and output filters, classifiers, or rules layered around an LLM to constrain its behavior beyond what the model’s own training provides.
Retrieval-augmented generation (RAG): An architecture pattern where a model retrieves relevant documents from an external knowledge base before generating a response, used to ground answers in current or proprietary data.
Excessive agency: A risk condition in which an AI agent holds more permissions, autonomy, or available tools than its task actually requires, increasing the potential impact of any single error.
Least privilege: A security principle requiring that any user, service, or agent be granted only the minimum access needed to complete a specific task, and nothing more.
Model denial of service: An attack or fault condition where excessive resource consumption, whether from malicious requests or runaway loops, degrades availability or generates uncontrolled cost.

Key Takeaways

The OWASP Top 10 for LLM Applications is the standard reference for prioritizing generative AI security investment, covering risks from prompt injection through unbounded consumption.
Prompt injection (LLM01) remains the root cause behind most real-world LLM incidents and should be treated as a day-one requirement, not a later hardening step.
Improper output handling (LLM05) becomes critical the moment model output is executed, rendered, or passed to another system without validation.
Excessive agency (LLM06) scales the impact of every other failure, which is why least-privilege tool scoping and human approval gates matter most in agentic deployments.
RAG-based systems introduce a distinct attack surface around vector and embedding weaknesses (LLM08) that access control at the UI layer alone does not address.
No single guardrail product covers all ten categories; defense in depth across input filtering, instruction-data separation, output validation, and monitoring consistently outperforms single-tool strategies.
The list should drive a recurring red-team and monitoring cadence, since both model behavior and attacker techniques change continuously after launch.

FAQs

What is the OWASP Top 10 for LLM Applications?

It is a community-maintained ranking of the ten most critical security risks in large language model applications, published by the Open Worldwide Application Security Project. It covers risks like prompt injection, sensitive information disclosure, and excessive agency, pairing each with practical mitigation guidance for developers and security teams.

Is prompt injection still the top risk in the current OWASP LLM list?

Yes, prompt injection (LLM01) has held the top spot across revisions of the list because it is the entry point for many other failures, including data disclosure and unauthorized tool actions. It remains difficult to fully solve because LLMs process instructions and data through the same channel.

How is the current OWASP LLM Top 10 different from the original 2023 list?

The list has been reworked and consolidated. Categories like insecure plugin design were folded into excessive agency, model denial of service was broadened into unbounded consumption, and new categories such as system prompt leakage and vector and embedding weaknesses were added to reflect agentic and RAG-based architectures.

What is the difference between direct and indirect prompt injection?

Direct prompt injection happens when an attacker types malicious instructions straight into a chat interface. Indirect prompt injection happens when those instructions are hidden inside content the model later processes, such as a web page, email, or document, exploiting the fact that agents often treat retrieved content as trustworthy.

How does excessive agency differ from prompt injection?

Prompt injection is about how an attacker’s instructions reach the model. Excessive agency is about how much damage the model can do once compromised or simply mistaken, because it holds more permissions or autonomous capability than the task requires. The two often combine: an injection triggers an action that excessive agency then allows to succeed.

What controls should a RAG-based application prioritize from the OWASP list?

RAG applications should prioritize sensitive information disclosure, vector and embedding weaknesses, and misinformation. Access control needs to be enforced at the retrieval layer so the model cannot surface documents a user is not authorized to see, and citation enforcement helps catch fabricated answers.

Can the OWASP Top 10 for LLMs fully prevent AI security incidents?

No single checklist eliminates risk entirely. The list identifies the categories that matter most and the controls that reduce likelihood and impact, but it requires continuous adversarial testing and monitoring because model behavior and attacker techniques evolve after deployment.

Who should use the OWASP Top 10 for LLM Applications?

Security engineers, AI product teams, procurement teams evaluating vendors, and compliance officers all use the list. It functions as a shared vocabulary between technical teams building LLM features and non-technical stakeholders assessing organizational risk.

References

OWASP Foundation, “OWASP Top 10 for LLM Applications 2025,” genai.owasp.org
Security Boulevard, “The OWASP Top 10 for LLM Applications (2025): Explained Simply”
SOCFortress, “OWASP Top 10 for LLM Applications (2025),” Medium
Kodem Security, “OWASP Top 10 for LLM Applications (2025)”
Indusface, “OWASP Top 10 For LLM Applications 2025”
Gravitee, “OWASP Top 10 for LLM Applications 2025: A Practical Guide”
MITRE, CVE-2023-29374 (LangChain LLMMathChain prompt-injection code execution)

For readers building out a broader AI security program, related deep dives on this site cover model theft and extraction and defensive testing practices worth reviewing alongside this checklist.