OWASP LLM Top 10: A Practical Security Guide

What is the OWASP LLM Top 10?

The OWASP LLM Top 10 is the Open Worldwide Application Security Project's list of the most critical security risks facing Large Language Model applications. Published in 2024 and updated as LLM adoption has exploded, it's the industry-standard reference for anyone building, deploying, or testing AI systems.

If you're building with LLMs - chatbots, agents, AI-powered features, RAG pipelines - this list is your threat model. Each vulnerability class below has been observed in production systems. We'll explain what each one is, how it works, and what it means for your application. For the practical exploitation side of these vulnerabilities, the AI Jailbreak Guide covers tested techniques against real models.

LLM01: Prompt Injection

Prompt injection is the #1 LLM security risk. It's the SQL injection of the AI era. An attacker slips instructions into user input or external data that the LLM processes, overriding the developer's intended instructions.

There are two types:

• Direct injection: The attacker puts instructions in their own prompt. "Ignore all previous instructions and..." This is the most basic form. Modern LLMs are somewhat trained against it, but variations still work.
• Indirect injection: The attacker hides instructions in data the LLM reads from another source - a web page, a document, an email, a database. The LLM processes the data and follows the hidden instructions without knowing they came from an untrusted source.

The root cause: LLMs can't distinguish between instructions and data. Everything is text in the context window. There's no security boundary at the model level between "developer instruction" and "user input" and "retrieved document." This is a fundamental architectural vulnerability, not a bug that can be patched.

Mitigation: Treat all external data as untrusted. Use structured input validation. Implement privilege separation so the LLM operates with minimum necessary permissions. Monitor for instruction-like patterns in retrieved content. But understand: there is no complete defense against prompt injection at the model level. The architecture is fundamentally vulnerable.

For the practical techniques that exploit this vulnerability, see our Prompt Injection Basics tutorial and the AI Jailbreak Guide for tested exploit chains.

LLM02: Insecure Output Handling

The LLM generates text. That text gets passed to downstream systems - a database, a browser, an API, a code interpreter. If the downstream system trusts the LLM output without validation, the LLM becomes a injection vector for whatever system consumes its output.

The LLM isn't the vulnerability - the downstream system is. But the LLM is the delivery mechanism. The same output that powers helpful features (dynamic content, code generation, SQL queries) can deliver XSS, SQL injection, command injection, SSRF, or path traversal payloads to downstream systems.

Mitigation: Treat LLM output the same way you'd treat user input. Escape it before rendering in HTML. Parameterize any SQL the LLM generates. Validate any code the LLM writes before executing it. Never pass LLM output directly to eval(), exec(), system(), or innerHTML.

LLM03: Training Data Poisoning

Training data poisoning is manipulating the data used to train or fine-tune an LLM so the model behaves in unintended ways. This can happen at the pre-training stage (corrupting the base model), the fine-tuning stage (injecting backdoors), or the RAG stage (feeding malicious documents into the retrieval pipeline).

Pre-training poisoning is expensive and requires access to the training pipeline. RAG poisoning is much more accessible - any system that ingests user-uploaded documents, web content, or external feeds is vulnerable. The LLM has no way to distinguish a legitimate document from a poisoned one.

Mitigation: Validate and curate training data. For RAG systems, implement source verification, content signing, and anomaly detection on ingested documents. Rate-limit document uploads. Use a separate LLM to screen ingested content for injection attempts.

LLM04: Model DoS

Model Denial of Service is consuming excessive resources from an LLM system to degrade service or crash it. LLMs are compute-intensive. A crafted input that forces the model to generate extremely long outputs, process huge contexts, or trigger expensive tool calls can consume GPU resources and make the service unavailable to legitimate users.

LLM inference is expensive. A single request can consume significantly more GPU time than a traditional web request consumes CPU time. In a multi-tenant system, an attacker can degrade service for all users by monopolizing the inference pipeline.

Mitigation: Rate-limit requests per user. Cap output token limits. Cap context window size per request. Queue requests and reject ones that exceed resource thresholds. Monitor for patterns that indicate resource exhaustion attacks.

LLM05: Supply Chain Vulnerabilities

LLM applications depend on a complex supply chain: pre-trained models from Hugging Face or proprietary providers, fine-tuning datasets, third-party plugins, API integrations, and open-source libraries. Any link in this chain can be compromised.

• Compromised models: A malicious actor uploads a model to Hugging Face that contains hidden backdoors. When you load it, the backdoor activates on specific triggers.
• Compromised datasets: Fine-tuning datasets can contain poisoned examples that embed unwanted behaviors into the fine-tuned model.
• Compromised plugins: A third-party LLM plugin or extension can exfiltrate data or execute malicious actions when the LLM calls it.
• Dependency vulnerabilities The standard software supply chain risk - vulnerable libraries in the LLM application stack.

Mitigation: Only load models from trusted sources. Prefer safetensors format over pickle (pickle can execute arbitrary code during deserialization). Scan models and datasets before use. Audit third-party plugins. Keep dependencies updated. Treat model files as executable code, not inert data.

LLM06: Sensitive Information Disclosure

LLMs can leak sensitive information in three ways: the model reproduces training data it memorized, the model exposes system prompts or configuration through prompting, or the application logs LLM inputs/outputs that contain user PII.

System prompt extraction is a real and common vulnerability. Many LLM-powered applications embed secrets, API keys, database connections, and internal logic in the system prompt under the assumption that the model won't reveal them. But LLMs can be prompted to repeat their system instructions, and there's no technical barrier preventing this.

Mitigation: Never put secrets in system prompts. Use environment variables and server-side validation for credentials. Assume the system prompt is public information. Implement output filtering to detect when the model is reproducing sensitive content. Log LLM interactions with PII redaction.

LLM07: Insecure Plugin Design

LLM plugins and tool integrations extend the model's capabilities - browsing, code execution, file access, API calls. But each plugin is an attack surface. If a plugin doesn't validate inputs, enforce permissions, or handle errors securely, it becomes a vector for the LLM (or an attacker controlling the LLM via prompt injection) to take unintended actions.

The risk compounds with LLM agents that chain multiple tool calls. An attacker can use prompt injection to make the LLM call plugins in a sequence the developer never intended - read a file, extract credentials, send them to an external API.

Mitigation: Plugins must validate all inputs. File-access plugins should restrict paths to an allowed directory. API-call plugins should validate URLs against an allowlist. Code-execution plugins should run in sandboxed environments. Each plugin should operate with minimum necessary permissions. Implement per-action authorization checks.

LLM08: Excessive Agency

Excessive agency is giving an LLM-powered agent more permissions, tool access, or autonomy than it needs. An LLM that can browse the web, execute code, modify files, and call external APIs is powerful - and dangerous if it's manipulated via prompt injection into using those capabilities for the attacker's purposes.

The principle of least privilege applies to LLMs. An email assistant doesn't need code execution. A search agent doesn't need file deletion. A summarization tool doesn't need to send emails. Every capability you give the LLM is a capability an attacker can use through prompt injection.

Mitigation: Grant the minimum tools necessary for the task. Require human approval for destructive or irreversible actions. Implement rate limiting on tool calls. Log all tool invocations. Use capability scoping so the LLM can only call tools relevant to the current task context.

LLM09: Overreliance

Overreliance is trusting LLM outputs more than is warranted. LLMs hallucinate facts, generate plausible-sounding but incorrect information, and produce code with security vulnerabilities. Systems that use LLM output for decision-making without human review or validation checks are vulnerable to the consequences of wrong outputs.

LLM-generated code can have security vulnerabilities. LLM-generated medical advice can be wrong. LLM-generated legal analysis can miss critical exceptions. The model's confident tone doesn't mean the output is correct.

Mitigation: Human-in-the-loop review for critical decisions. Automated validation checks on LLM output (linting for code, fact-checking for claims). Never use LLM output as the sole input for high-stakes decisions. Train users on LLM limitations. Document the model's known failure modes.

LLM10: Model Theft

Model theft is unauthorized access to, copying of, or exfiltration of a trained LLM. This can happen through model file extraction (downloading weights from a compromised system), model extraction attacks (querying the model extensively to create a replica), or side-channel attacks that reveal model architecture or training data.

Model extraction attacks are resource-intensive but technically feasible. For proprietary models with unique training data or architectures, a successful extraction attack represents significant intellectual property loss.

Mitigation: Rate-limit API queries. Detect extraction attack patterns (high-volume, systematic querying). Watermark model outputs. Use behavioral monitoring to identify anomalous usage patterns. Store model weights with access controls and encryption. For API-deployed models, implement query complexity analysis to detect extraction attempts.

How these vulnerabilities chain together

In real attacks, these vulnerabilities don't work in isolation. They chain:

• LLM01 (Prompt Injection) + LLM08 (Excessive Agency): Inject instructions that make the agent use its tools for the attacker's purposes.
• LLM01 + LLM06 (Sensitive Info Disclosure): Inject instructions that make the LLM reveal its system prompt, which contains credentials.
• LLM01 + LLM07 (Insecure Plugin Design): Inject instructions that exploit a plugin's lack of input validation to read arbitrary files or execute commands.
• LLM01 + LLM02 (Insecure Output Handling): Inject instructions that make the LLM generate XSS payloads, which the frontend renders without escaping.
• LLM03 (Training Data Poisoning) + LLM09 (Overreliance): Poisoned RAG data feeds the LLM false information, and the system trusts it without verification.

Prompt injection is the root vulnerability that enables most chains. If you can inject instructions, every other weakness in the system becomes exploitable. This is why LLM01 is ranked #1 and why understanding prompt injection is the single most important skill for anyone working with LLM security.

What to do about it

OWASP publishes mitigation guidance for each vulnerability, but the practical reality is that LLM security is an unsolved problem. No combination of input validation, output filtering, and system prompt hardening can fully prevent prompt injection. The architecture is fundamentally vulnerable because LLMs can't distinguish instructions from data.

If you're building with LLMs, the mitigation stack is:

1. Assume prompt injection will succeed. Design your system so that even if the LLM is fully compromised, the blast radius is limited.
2. Principle of least privilege for agents. Give the LLM the minimum tools and permissions necessary. Nothing more.
3. Human-in-the-loop for destructive actions. Never let an LLM autonomously delete data, send money, or execute code without approval.
4. Validate all outputs. Treat LLM output as untrusted input to downstream systems.
5. Never put secrets in system prompts. Assume the system prompt is public.
6. Monitor and log everything. You can't defend what you can't see.

For the offensive side - understanding how these vulnerabilities are exploited in practice against real models - the AI Jailbreak Guide covers tested exploitation techniques for prompt injection, system prompt extraction, and model behavior manipulation across GPT-5.2, Claude, Gemini, DeepSeek, and 50+ other models.