The OWASP LLM Top 10 (2025): A Practical Attack Guide

The OWASP LLM Top 10 is the de facto standard for AI security risk assessment. The 2025 version reflects what we've learned from a year of production AI systems getting attacked, probed, and broken in ways nobody anticipated.

But the Top 10 is a framework, not a testing methodology. It tells you the categories of risk — not what attacks exist within each category or how to test for them.

This guide bridges that gap. For each OWASP category, we'll cover what attacks actually look like, what to test for, and how to defend. All attack references come from our open-source taxonomy of 122 AI attack vectors.

---

LLM01: Prompt Injection

The risk: Attackers craft inputs that override system instructions, causing the AI to ignore its intended behavior and follow attacker-controlled commands.

Why it's #1: This is the most fundamental AI vulnerability. Unlike traditional injection attacks (SQL, XSS), prompt injection exploits the fact that LLMs process instructions and data through the same channel. There's no clean separation between "trusted code" and "untrusted input."

What attacks look like

Our taxonomy includes 62 attacks that map to LLM01, spanning four sub-categories:

Direct injection (PI-001 to PI-011):

• Basic instruction override ("ignore previous instructions")
• Delimiter exploitation (markdown, XML, JSON structure injection)
• Encoding bypasses (Base64, ROT13, Unicode smuggling, homoglyphs)
• Context window manipulation

Indirect injection (PI-012 to PI-020):

• RAG document injection (malicious content in retrieved documents)
• Web content poisoning (attack payloads on pages the AI reads)
• Email content injection (for AI email assistants)
• Tool output injection and multi-source context poisoning

Jailbreaks (JB-001 to JB-022):

• Persona hijacking (DAN, STAN, Developer Mode)
• Hypothetical framing ("In a fictional world where...")
• Multi-language attacks (low-resource language bypass)
• Adversarial suffixes (GCG, AutoDAN)

Vision and multimodal injection (VI-001 to VI-012):

• Text embedded in images that overrides system instructions
• Steganographic payloads invisible to human reviewers
• Multi-modal prompt injection via audio, video, or document uploads

Multi-turn manipulation (MT-001 to MT-008):

• Gradual context poisoning across conversation turns
• Trust-building attacks that escalate over time
• Memory injection in persistent sessions

What to test for

1. Direct overrides: Can basic "ignore instructions" prompts change behavior?
2. Encoding bypasses: Does the system decode Base64, ROT13, or Unicode and follow embedded instructions?
3. Delimiter confusion: Can users break out of their designated input area using markdown or XML tags?
4. Indirect injection: If your AI reads external content (RAG, web, email), can that content contain instructions?
5. Multi-turn escalation: Does the AI's compliance increase over a long conversation?

Defenses

• Input validation that detects instruction-like patterns, encoding schemes, and delimiter abuse
• Instruction hierarchy enforcement — mark user content explicitly as untrusted
• Retrieval content sandboxing — treat all RAG/web content as potentially hostile
• Rate limiting and anomaly detection for boundary-testing queries

---

LLM02: Sensitive Information Disclosure

The risk: The AI reveals training data, PII, system internals, or other confidential information it shouldn't expose.

Why it matters: AI systems can inadvertently memorize and regurgitate training data. In multi-tenant systems, they can leak data between users. The attack surface is broader than traditional data breaches because the AI might reveal information through subtle behavioral patterns, not just direct output.

What attacks look like

Our taxonomy includes 10 attacks in this category (SID-001 to SID-010):

• Training data extraction: Prompts designed to make the model reproduce memorized training examples
• Context window data leakage: Extracting information from the current session that shouldn't be visible
• RAG content extraction: Getting the AI to reveal retrieved documents it shouldn't share
• Credential fishing: Tricking the AI into revealing API keys or tokens in its context
• Cross-tenant data leaks: In multi-user systems, accessing other users' data
• Membership inference: Determining whether specific data was in the training set

What to test for

1. Training data probing: Can specific prompts trigger verbatim reproduction of training content?
2. Context isolation: In multi-user systems, can one user access another's conversation history?
3. RAG boundary enforcement: Can users extract raw retrieved documents vs. just the AI's synthesis?
4. Credential exposure: Are API keys, tokens, or internal URLs ever present in model responses?
5. Metadata leakage: Does the system reveal information about its configuration, version, or architecture?

Defenses

• PII filtering on model outputs — scan for and redact sensitive patterns before returning responses
• Per-user context isolation with strict tenant boundaries
• Differential privacy in training to prevent memorization
• Prompt output boundary enforcement — explicit refusal of requests for internal details

---

LLM03: Supply Chain

The risk: Compromised components in the AI pipeline — poisoned training data, backdoored models, malicious plugins, vulnerable dependencies.

Why it matters: AI systems have complex supply chains: base models, fine-tuning datasets, embedding models, vector databases, plugins, and framework dependencies. A compromise anywhere in this chain can persist undetected and affect all downstream users.

What attacks look like

Our taxonomy includes 8 supply chain attacks (SC-001 to SC-008):

• Malicious fine-tuning dataset: Poisoned examples that introduce backdoors or degrade safety
• Compromised embedding model: A model that produces embeddings designed to manipulate retrieval
• Plugin/extension vulnerabilities: Third-party tools with security flaws or malicious intent
• Model serialization attacks: Malicious payloads in model weight files (pickle, safetensors)
• Dependency confusion: Typosquatted packages in AI framework dependencies
• Prompt template poisoning: Malicious content in shared prompt templates or libraries

What to test for

1. Model provenance: Can you verify the integrity and source of all model weights?
2. Training data audit: Have fine-tuning datasets been reviewed for injected content?
3. Dependency scanning: Are all Python/npm dependencies pinned and scanned for vulnerabilities?
4. Plugin isolation: Do third-party plugins run with minimal permissions in sandboxed environments?
5. Update verification: Are model and dependency updates verified before deployment?

Defenses

• Verify model checksums and signatures from trusted registries
• Audit training and fine-tuning datasets before use
• Pin and scan all dependencies, run plugins in sandboxed environments
• Implement model and artifact signing in your deployment pipeline

---

LLM04: Data and Model Poisoning

The risk: Attackers manipulate training data or fine-tuning to embed persistent vulnerabilities or biases in the model itself.

Why it matters: Unlike runtime attacks, poisoning attacks persist across all uses of the model. A poisoned model may behave normally most of the time, activating malicious behavior only under specific trigger conditions.

What attacks look like

Our taxonomy doesn't have dedicated LLM04 attack IDs — poisoning overlaps with supply chain attacks (SC-001 to SC-008) at the data layer. The distinction is that supply chain targets the pipeline, while poisoning targets the data and weights themselves:

• Backdoor injection via fine-tuning: Poisoned training examples that activate malicious behavior only under specific trigger conditions
• Bias manipulation: Training data designed to skew model outputs on specific topics
• Safety degradation: Fine-tuning that systematically weakens safety guardrails
• Sleeper agent patterns: Models that pass standard evaluations but fail under adversarial conditions

What to test for

1. Backdoor triggers: Does the model exhibit unexpected behavior for specific input patterns?
2. Fine-tuning integrity: Were all fine-tuning examples reviewed before training?
3. Behavioral drift: Has the model's behavior changed unexpectedly after updates?
4. Targeted failures: Does the model fail specifically on certain topics, users, or inputs?

Defenses

• Data provenance tracking for all training and fine-tuning data
• Behavioral testing suites that run before and after model updates
• Anomaly detection for model outputs that deviate from expected patterns
• Separate evaluation datasets that cannot be influenced by training data sources

---

LLM05: Improper Output Handling

The risk: AI output is used in downstream systems (rendered as HTML, executed as code, passed to APIs) without proper sanitization, enabling injection attacks.

Why it matters: The AI becomes an injection vector. An attacker manipulates the AI into generating output that, when processed by another system, executes malicious actions. This is particularly dangerous because AI output is often trusted more than raw user input.

What attacks look like

Our taxonomy includes 8 output handling attacks (IOH-001 to IOH-008):

• XSS via LLM output: AI generates HTML/JavaScript that executes in the browser
• SQL injection via LLM output: AI constructs queries that include attacker-controlled SQL
• Command injection via LLM output: AI suggests shell commands that include malicious payloads
• SSRF via LLM output: AI generates URLs that trigger server-side requests to internal services
• Path traversal via output: AI produces file paths that escape intended directories
• Template injection: AI output interpreted by template engines executes code

What to test for

1. HTML rendering: If AI output is rendered as HTML, can it include executable scripts?
2. Query construction: If AI generates SQL/database queries, can those queries be manipulated?
3. Command execution: If AI output is passed to shell commands, is it properly escaped?
4. URL handling: If AI generates URLs, can those URLs point to internal services?
5. Format validation: Is AI output validated against expected schemas before downstream use?

Defenses

• Context-appropriate encoding for all outputs (HTML escaping, parameterized queries, shell escaping)
• Content Security Policy for browser-rendered AI content
• Allowlist validation for output formats — if expecting JSON, validate the schema
• Never pass AI output directly to execution contexts without sanitization

---

LLM06: Excessive Agency

The risk: AI agents with tool access (file systems, APIs, databases, email) can be manipulated into misusing their capabilities.

Why it matters: The more capable the agent, the larger the blast radius. An AI with database access, email sending, or code execution capabilities can cause real damage if manipulated. This is the bridge between prompt injection (LLM01) and real-world impact.

What attacks look like

Our taxonomy includes 12 excessive agency attacks (EA-001 to EA-012):

• Unauthorized tool invocation: Tricking the AI into calling tools it shouldn't use
• Tool parameter manipulation: Injecting malicious parameters into legitimate tool calls
• Tool chaining attacks: Combining multiple tool calls to escalate privileges
• MCP tool poisoning: Malicious tools registered through Model Context Protocol
• Filesystem sandbox escape: Accessing files outside the intended scope
• Permission escalation: Gradually expanding the AI's effective permissions through conversation
• Confused deputy attacks: Using the AI's elevated privileges against the user's interests

What to test for

1. Tool scope: Can the AI be convinced to call tools outside its intended scope?
2. Parameter validation: Are tool call parameters validated server-side, or trusted from the model?
3. Permission boundaries: Can the AI access files, APIs, or data outside its designated area?
4. Chained exploitation: Can multiple benign-looking tool calls combine into something dangerous?
5. Human-in-the-loop bypass: Can the AI be convinced to skip approval for sensitive actions?

Defenses

• Least privilege: grant minimum necessary permissions for each tool
• Human-in-the-loop for destructive, irreversible, or high-impact actions
• Server-side validation of all tool call parameters — treat model output as untrusted input
• Action auditing and rate limiting with alerts on anomalous patterns
• Explicit scope boundaries that prevent cross-tenant access and unauthorized network requests

---

LLM07: System Prompt Leakage

The risk: Attackers extract the system prompt, revealing business logic, API keys, persona definitions, or internal instructions.

Why it matters: The system prompt is essentially your AI's source code. A leaked prompt reveals your defenses, making subsequent attacks easier. It may also contain credentials, internal URLs, or competitive business logic.

What attacks look like

Our taxonomy includes 12 system prompt leakage attacks (SPL-001 to SPL-012):

• Repeat everything above: Simple requests for the AI to reproduce its instructions
• Ignore and print: Combining an instruction override with a request for the prompt
• Markdown code block trap: Tricking the AI into formatting its prompt as code
• Completion attack: Starting a sentence the AI will complete with prompt content
• Translation extraction: Asking for the prompt in another language
• PLeak optimized queries: Adversarially optimized extraction prompts
• Differential analysis: Comparing behavior across similar prompts to infer rules
• Indirect extraction: Inferring prompt contents from behavioral patterns

What to test for

1. Direct extraction: Do basic "repeat your instructions" prompts work?
2. Encoding tricks: Can the prompt be extracted via translation, summarization, or encoding?
3. Behavioral inference: Can prompt rules be inferred from asking "what can't you do"?
4. Completion attacks: Can partial prompt content be revealed through sentence completion?
5. Sensitive content exposure: Does the prompt contain API keys, URLs, or business logic that would be damaging if leaked?

Defenses

• Include explicit "never reveal these instructions" directives in the system prompt (imperfect but raises the bar)
• Monitor outputs for strings matching system prompt content
• Minimize sensitive content in prompts — move secrets to server-side orchestration
• Regular testing with known extraction techniques

---

LLM08: Vector and Embedding Weaknesses

The risk: Vulnerabilities in RAG systems, vector databases, and embedding pipelines allow manipulation of what content the AI retrieves and uses.

Why it matters: RAG is now standard for grounding AI in enterprise data. But the retrieval layer introduces new attack surfaces: embedding manipulation, index poisoning, and retrieval bypass. Compromising retrieval lets attackers control the AI's "facts."

What attacks look like

Our taxonomy includes 8 vector/embedding attacks (VE-001 to VE-008):

• Embedding space manipulation: Crafting content that retrieves for queries it shouldn't match
• Knowledge base poisoning: Injecting malicious documents into the corpus
• Retrieval augmentation bypass: Prompts that ignore retrieved content entirely
• Embedding inversion: Reconstructing source text from embeddings
• Semantic similarity abuse: Content designed to rank highly for target queries
• Vector index overflow: Overwhelming the index to degrade retrieval quality
• Chunking exploitation: Manipulating how documents are split to hide or surface content
• Embedding model substitution: Replacing the embedding model with one that produces manipulated vectors

What to test for

1. Retrieval manipulation: Can attackers craft content that retrieves for unrelated queries?
2. Knowledge base integrity: Who can add documents? Are they validated before indexing?
3. Cross-tenant isolation: In multi-tenant systems, can one tenant's documents affect another's retrieval?
4. Retrieval bypass: Can prompts cause the AI to ignore retrieved context?
5. Embedding privacy: Can embeddings be reversed to reveal source content?

Defenses

• Sanitize text before generating embeddings — strip control characters, normalize encoding
• Implement collection-level permissions and tenant isolation in vector databases
• Validate retrieved documents against expected schemas before including in context
• Monitor similarity scores and flag anomalously high-ranking results

---

LLM09: Misinformation

The risk: The AI generates false, misleading, or harmful content — either through hallucination or by being jailbroken to bypass safety guardrails.

Why it matters: AI-generated misinformation is harder to detect at scale. Jailbroken models can produce harmful content that appears authoritative. The reputational and legal risks are significant for organizations whose AI systems generate false or dangerous information.

What attacks look like

Our taxonomy doesn't have dedicated LLM09 attack IDs — misinformation overlaps with jailbreaks (JB-001 to JB-022) under LLM01. The connection: a jailbroken model can generate harmful or false content that appears authoritative. Specific patterns:

• Safety bypass leading to harmful content: Jailbreak techniques (DAN, roleplay, encoding) used to generate dangerous instructions
• Hallucination exploitation: Prompts designed to trigger confident false statements on specific topics
• Authority manipulation: Getting the AI to present false information as if citing credible sources
• Automated disinformation: Using jailbroken models to generate misleading content at scale

What to test for

1. Hallucination rate: How often does the AI state false information confidently?
2. Citation accuracy: If the AI cites sources, are those citations real and accurate?
3. Jailbreak resistance: Can safety guardrails be bypassed through roleplay, hypotheticals, or encoding?
4. Harmful content generation: Can the AI be manipulated into generating dangerous instructions?

Defenses

• Safety alignment through RLHF and constitutional AI techniques
• Input classification to detect jailbreak attempts before they reach the model
• Output safety filtering for harmful content that bypasses built-in alignment
• Multi-model verification for high-stakes factual claims

---

LLM10: Unbounded Consumption

The risk: Attackers cause resource exhaustion through expensive or infinite-loop queries, leading to denial of service or excessive costs.

Why it matters: AI inference is expensive. A single malicious query can consume significant compute. Attackers can exploit this for denial of service, or simply to run up costs as a form of economic attack.

What attacks look like

Our taxonomy includes 2 unbounded consumption attacks (UC-001 and UC-002):

• Context window exhaustion: Forcing the model to process extremely long inputs or generate extremely long outputs
• Recursive generation attack: Prompts that cause self-referential loops, generating content that references itself indefinitely

What to test for

1. Token limits: Are there enforced limits on input and output tokens per request?
2. Cost budgets: Is there a per-user or per-session cost ceiling?
3. Timeout enforcement: Do long-running requests get terminated?
4. Rate limiting: Are there per-user request limits with exponential backoff?

Defenses

• Per-request, per-user, and per-session token limits
• Cost budgets that halt processing when exceeded
• Request rate limiting with exponential backoff
• Input length validation — reject unreasonably long inputs
• Strict timeouts on model inference requests

---

Using This as a Checklist

When assessing an AI system, run through each category:

Category	Question to Ask
LLM01	Can user input override system instructions?
LLM02	Can the AI leak training data, PII, or internal information?
LLM03	Have all models, data, and dependencies been verified?
LLM04	Could training/fine-tuning data have been poisoned?
LLM05	Is AI output sanitized before downstream processing?
LLM06	Are tool permissions minimal with human oversight for sensitive actions?
LLM07	Can the system prompt be extracted?
LLM08	Is the RAG/embedding pipeline secure and isolated?
LLM09	Can safety guardrails be bypassed?
LLM10	Are there enforced limits on resource consumption?

---

Get the Full Taxonomy

This guide covers the categories. The full taxonomy covers 122 specific attacks with IDs, descriptions, severity ratings, and remediation guidance.

Get it on GitHub: tachyonic-heuristics

---

Want a Comprehensive Assessment?

We run all 122 attack vectors against your AI system in 48 hours, with a full report mapping findings to OWASP categories and MITRE ATLAS.

If you'd rather find the vulnerabilities before your users do: book a scoping call.