OWASP Guide
OWASP LLM Top 10: Complete Guide to LLM Security Testing (2026)
The OWASP LLM Top 10 is the clearest framework we have for defending modern LLM apps. This pillar guide explains every category, shows how prompt injection and jailbreaks map to real-world risks, and gives you a practical testing plan for LLM security testing without relying on ambiguous buzzwords.
Table of Contents
- What is the OWASP LLM Top 10?
- OWASP LLM Top 10 vs Traditional OWASP Top 10
- LLM01: Prompt Injection
- LLM02: Insecure Output Handling
- LLM03: Training Data Poisoning
- LLM04: Model Denial of Service
- LLM05: Supply Chain Vulnerabilities
- LLM06: Sensitive Information Disclosure
- LLM07: Insecure Plugin Design
- LLM08: Excessive Agency
- LLM09: Overreliance
- LLM10: Model Theft
- How to Test Your LLM for OWASP Compliance
- Expert Perspectives
- Frequently Asked Questions
- Start Testing the OWASP LLM Top 10
What is the OWASP LLM Top 10?
The OWASP LLM Top 10 is a security risk framework built by the Open Worldwide Application Security Project (OWASP) and its community. It documents the ten most significant vulnerability categories for applications built on large language models, including prompt injection, insecure output handling, and system prompt leakage. The project is maintained as an evolving reference, which means it grows as the field learns more about adversarial prompting, indirect injection in RAG pipelines, and real-world LLM abuse.
You can find the official project at OWASP LLM Top 10. The list is not just for security teams. It is written to give developers and product engineers a shared vocabulary for the threats that show up once a model is connected to user input, retrieval systems, and tool APIs. If you are shipping an LLM chat interface, an agentic workflow, or a RAG search assistant, mapping your system to the LLM Top 10 is the quickest way to find blind spots.
This guide walks through each category and focuses on what you can test today. You will see how a prompt injection attack differs from a jailbreak, why a system prompt leak is an OWASP LLM06 disclosure issue, and where manual review is still required.
OWASP LLM Top 10 vs Traditional OWASP Top 10
Traditional web application risks still matter, but LLM systems create new attack surfaces. The table below shows how the LLM Top 10 overlaps with the classic OWASP Top 10 while introducing model-specific issues like prompt injection and excessive agency.
| LLM Top 10 category | Closest traditional OWASP risk | Why it differs for LLMs |
|---|---|---|
| LLM01: Prompt Injection | Injection (A03) | Attacker input manipulates model instructions, not just a query string or command. |
| LLM02: Insecure Output Handling | Injection / XSS (A03) | Model output is probabilistic and must be treated as untrusted input downstream. |
| LLM03: Training Data Poisoning | Software and Data Integrity Failures (A08) | Risks originate in data pipelines, model fine-tuning, or retrieval corpora. |
| LLM04: Model Denial of Service | Security Misconfiguration (A05) | Expensive prompts or tool loops can exhaust tokens, cost, or latency budgets. |
| LLM05: Supply Chain Vulnerabilities | Vulnerable Components (A06) | Model providers, embeddings, and plugins introduce new dependencies outside your codebase. |
| LLM06: Sensitive Information Disclosure | Cryptographic Failures (A02) | Models can leak secrets via memorization, prompt leakage, or unsafe retrieval. |
| LLM07: Insecure Plugin Design | Broken Access Control (A01) | Tool calls are often agent-driven and need strict allowlists and permissions. |
| LLM08: Excessive Agency | Insecure Design (A04) | LLMs can take actions without sufficient guardrails or human approval. |
| LLM09: Overreliance | Insecure Design (A04) | Teams trust probabilistic model outputs without validation or review. |
| LLM10: Model Theft | Broken Access Control (A01) | Attackers can extract model behavior or training data via repeated probing. |
LLM01: Prompt Injection
Prompt injection is the most well-known LLM risk because it can directly override your system prompt. Attackers craft inputs that tell the model to ignore its instructions, reveal hidden context, or call tools in unsafe ways. Direct injection comes from the user; indirect injection hides in external content, such as documents, web pages, or retrieval results.
In production, prompt injection often shows up as role confusion, policy bypasses, or hidden instructions embedded inside context. Multi-turn conversations make the problem harder because an attacker can set up the model over multiple exchanges before triggering the exploit. If your agent uses function calling, prompt injection can also influence what tools are called and with what parameters.
LLM security testing for LLM01 focuses on adversarial prompt sets, system prompt leak probes, and indirect injection payloads. BastionLLM scans for direct and indirect injection patterns, plus jailbreak variants that overlap with LLM01. You can start with the Prompt Injection Scanner or run a full scan from the homepage.
LLM02: Insecure Output Handling
LLM output is untrusted input. When you render it in a browser, pipe it into a database, or feed it into a downstream API, you can accidentally create a secondary injection vector. This is how LLM02 appears: the model behaves as expected, but its output is used in an unsafe context.
Examples include HTML output that triggers script execution, Markdown that injects unwanted links, or generated SQL statements that are executed without sanitization. The fix is classic: treat model output as untrusted, apply escaping, and validate structure before downstream use.
Testing LLM02 involves reviewing every place the model output is consumed. Automated scans can detect risky output patterns, but the most reliable control is strict output schemas, content filtering, and safe rendering layers.
LLM03: Training Data Poisoning
Training data poisoning occurs when attackers influence the data used to train or fine-tune a model. In LLM applications, this often happens through user-generated content pipelines, public data sources, or retrieval corpora that are ingested without adequate vetting.
Poisoned data can insert backdoors, biased behavior, or subtle instruction overrides that only activate when a trigger phrase appears. For RAG systems, poisoning can happen at the retrieval layer, where a malicious document becomes part of the context that shapes output.
This category is less about automated scanning and more about data lineage, content moderation, and model governance. Track where training data comes from, implement review workflows for new corpora, and monitor for anomalous model behavior after updates.
LLM04: Model Denial of Service
Model Denial of Service focuses on availability risks unique to LLMs. Attackers can send prompts that force long output generation, trigger expensive tool calls, or cause recursion in agent workflows. Even without malicious intent, users can overload systems with massive prompts or complex tasks.
The impact is not just latency. It can drive up inference costs, saturate queue workers, or create cascading failures in downstream systems. Without strict limits, a single request can consume a disproportionate share of resources.
Mitigations include token caps, rate limits, concurrency guards, timeouts, and tool-call budgets. LLM security testing should include long-context payloads and stress prompts to validate that safeguards trigger as expected.
LLM05: Supply Chain Vulnerabilities
LLM stacks are built on external dependencies: model providers, vector databases, embedding APIs, and plugin ecosystems. Each dependency is a supply chain risk, especially when it can influence model output or access sensitive data.
A compromised model update, a malicious plugin, or an insecure third-party integration can undermine your controls even if your own code is solid. This risk is amplified when tool-use workflows involve multiple SaaS systems or unvetted open-source components.
The best defense is dependency governance: version pinning, vendor risk review, plugin allowlists, and monitoring for behavior changes after updates. Track model provenance and document which providers have access to sensitive data.
LLM06: Sensitive Information Disclosure
LLMs can disclose sensitive information in multiple ways: reproducing training data, leaking internal system prompts, or exposing hidden configuration details. This category is especially relevant for systems that embed proprietary data, customer records, or internal runbooks in the context window.
System prompt leaks are a common example. If an attacker can coax the model into revealing its instructions, they gain insight into business logic, moderation rules, and internal API endpoints. In RAG systems, data leakage can occur when retrieval boundaries are weak or access control is enforced only in the UI layer.
Automated LLM security testing can probe for leakage using system prompt extraction and sensitive data probes. BastionLLM includes system prompt leak detection alongside prompt injection testing, giving you pass or fail evidence for LLM06 controls.
LLM07: Insecure Plugin Design
Plugins and tools extend LLM capabilities by letting the model execute actions, call APIs, and operate on external systems. Insecure plugin design appears when those tools accept unvalidated input, have overly broad permissions, or bypass authentication.
An attacker who can influence the model output can steer tool calls. That can lead to unauthorized data access, unintended state changes, or unsafe side effects. Function calling systems are particularly sensitive because the model chooses the tool and arguments on the fly.
To mitigate LLM07, apply the same security rules you would for any privileged API: strict authentication, least privilege scopes, input validation, and output monitoring. Automated testing should include tool call abuse cases to verify controls.
LLM08: Excessive Agency
Excessive agency means giving an LLM more autonomy than necessary. The model can take actions without sufficient guardrails, leading to destructive or high-impact changes. This is common in agentic workflows that can trigger purchases, modify records, or send messages.
The risk is not always malicious input. The model can make mistakes, misinterpret user intent, or execute tools in the wrong order. Without approval checkpoints, these errors become security incidents.
Limit agency by introducing explicit approvals, human-in-the-loop steps, and hard policy boundaries. Test these controls by simulating requests that attempt to escalate scope or bypass approvals.
LLM09: Overreliance
Overreliance is a risk created by humans, not attackers. Teams trust the model output as correct without verification. In security contexts, this can mean accepting generated code, configuration, or decisions without validation.
LLMs are probabilistic and can be confidently wrong. If your workflow does not require review or validation, an error can propagate into production systems or security policies. Overreliance is one of the least technical but most damaging failure modes.
Mitigate LLM09 by designing workflows with validation steps: use structured outputs, run automated checks, and require human approval for high-impact actions. Document the review process as part of your OWASP LLM compliance evidence.
LLM10: Model Theft
Model theft covers attempts to extract proprietary model behavior, training data, or fine-tuning advantages through repeated querying. Attackers can probe an endpoint to reconstruct sensitive data or approximate model weights.
This is especially important when your model contains proprietary fine-tuning data or represents a significant competitive asset. Model extraction attacks can also reveal protected data if the model memorized it during training.
Mitigate LLM10 with rate limiting, output monitoring, anomaly detection, and legal protections in usage terms. Logging query patterns is essential to detect systematic extraction attempts.
How to Test Your LLM for OWASP Compliance
The OWASP LLM Top 10 is most effective when it becomes a living checklist. Use the steps below to build a repeatable LLM security testing workflow that maps to the Top 10.
Step 1: Map the attack surface. Inventory where prompts come from, what data is retrieved, which tools are callable, and what outputs are consumed downstream. This gives you the LLM01, LLM02, and LLM07 scope.
Step 2: Classify by OWASP category. For each system component, assign the relevant LLM Top 10 risks. RAG pipelines map to LLM01 and LLM06, agent workflows map to LLM07 and LLM08, and data pipelines map to LLM03.
Step 3: Define success criteria. Decide what counts as a failure: system prompt leakage, policy bypass, unsafe tool use, or leakage of sensitive data. Formalize those criteria before testing.
Step 4: Run automated attack simulations. Use BastionLLM to scan for prompt injection attacks, LLM jailbreaks, and system prompt leaks. Automated tests give consistent evidence for LLM01 and LLM06.
Step 5: Review non-testable categories. For LLM03, LLM05, LLM08, and LLM09, document governance controls such as data vetting, dependency reviews, approval workflows, and human-in-the-loop checks.
Step 6: Schedule recurring scans. Model behavior changes with new prompts, model versions, or tool integrations. Weekly or continuous scans catch regressions before they reach production users.
If you need a starting point, run a free scan from the homepage or try the prompt injection scanner. You can expand from there into a full OWASP-aligned testing cadence.
Expert Perspectives
Experienced LLM security practitioners tend to emphasize the same themes when discussing the OWASP LLM Top 10. The notes below capture those recurring patterns without tying them to a single source or quote.
- Prompt injection is a full-stack issue. You have to secure prompts, tools, retrieval, and output handling together.
- Indirect injection in RAG systems is a primary risk. Any untrusted document can become a control plane if you do not isolate it.
- System prompt leaks are practical, not theoretical. If it is in the prompt, assume an attacker will try to extract it.
- Automation wins for repeatability, but governance still matters for supply chain and data integrity risks.
- The best evidence of security is continuous testing with clear pass or fail results.
Frequently Asked Questions
What is the OWASP LLM Top 10?
The OWASP LLM Top 10 is a community-maintained list of the ten most significant security risks affecting LLM-powered applications. It gives developers a shared vocabulary for threats like prompt injection, sensitive data disclosure, and insecure tool use, and it helps teams structure their testing and governance practices.
Is prompt injection the same as a jailbreak?
Prompt injection focuses on overriding or manipulating the system prompt or tool instructions, while jailbreaks focus on bypassing safety guardrails to make the model produce restricted output. Both are common attack patterns and often overlap in real-world tests.
How does the OWASP LLM Top 10 apply to RAG systems?
RAG systems expand the attack surface because retrieved documents can contain indirect prompt injection payloads. That puts LLM01 at the center of RAG security, alongside LLM06 for data leakage and LLM07 for tool-use risk if the model can call plugins.
Which LLM risks can be tested automatically?
Prompt injection, jailbreak attempts, and system prompt leak detection are the most automatable. Other categories, such as training data poisoning and supply chain weaknesses, usually require process controls and manual review.
How often should I test against the OWASP LLM Top 10?
Test whenever you change prompts, models, tool integrations, or retrieval sources. Continuous or scheduled scans help detect regressions caused by model updates and new attack patterns.
What evidence do security teams expect for OWASP LLM compliance?
Teams typically keep a record of automated scan results, manual review notes for non-testable categories, and a clear mapping between each OWASP LLM category and the controls you have in place.
Start Testing the OWASP LLM Top 10
Knowing the OWASP LLM Top 10 is the first step. Verifying that your system holds up against real prompt injection attacks, jailbreaks, and system prompt leak attempts is the step that reduces risk.
Run a free LLM security scan and get clear pass or fail results.