OWASP LLM Top 10 (v2025): The Baseline Threat Model for LLM-Backed Applications

LLM01: Prompt Injection

The most well-known category on the list, and still the most misunderstood. Prompt injection is the manipulation of an LLM's behaviour by adversarial input, either from a user directly (direct injection) or from content the model processes on behalf of the user (indirect injection). The direct variant is the one that dominates public discussion; the indirect variant is the one that causes most actual production incidents.

The field-level interpretation is this: any LLM that processes untrusted content (a web page, an email, a PDF, a document from a third party) can have its behaviour altered by that content, and the alteration can persist across the session. A model summarising an email that contains hidden instructions can be induced to exfiltrate data, mislead the user, or take actions it would not otherwise take. It cannot be patched away, because it follows from how LLMs process text. The correct response is architectural: treat model outputs as untrusted, put authorisation boundaries around any action the model can take, and do not give the model capabilities that a malicious prompt could misuse.

The category has held first place in every edition of the list so far (2023, 2025 and 2026). In our engagement experience, prompt injection is the most common root cause of LLM-related security incidents, and indirect injection specifically is the variant that most deployments underestimate.

LLM02: Sensitive Information Disclosure

The 2025 revision moved this category up from sixth place in 2023 to second, reflecting how consistently it appears in post-incident analysis. The threat is that LLMs can reveal sensitive information (personal data, confidential business data, credentials, proprietary algorithms, training data) through their outputs, either in direct response to adversarial queries or inadvertently as part of normal operation.

The interpretation that matters in the field: LLM outputs should be treated as having the same sensitivity classification as the highest-sensitivity data the model has ever seen, for the duration of any session in which that data was present. Training data leaks. Context-window contents leak. Retrieval results leak. Preventing the model from revealing information is not reliably achievable, so the defensive posture is to ensure the model never has access to information it is not authorised to reveal in the current context.

System prompts are the one exception to the scope of this entry: the 2025 list gives them an entry of their own, LLM07 (below), which treats the system prompt as something that will leak and places the real risk in what the prompt contains. The defensive principle is the same in both entries.

LLM03: Supply Chain

LLM applications have a dependency graph that extends well beyond the conventional software supply chain. The model itself is a dependency, often from a third party. The training data is a dependency. Fine-tuning datasets, tokenisers, embedding models, vector databases, retrieval indices, and the inference stack are all dependencies. Each introduces its own supply chain risk, and several of them (notably model weights) do not have the provenance tooling that has become standard for software packages.

This category has risen in importance as production deployments have matured past the "call a hosted API" stage into the "fine-tuned, retrieval-augmented, multi-model" architectures that are now typical. The field-level reality is that most organisations cannot currently attest to the provenance of every component in their LLM stack. Model cards are inconsistent, training data is opaque even for open-weight models, and the supply chain for specialised components (embedding models in particular) is poorly documented.

The practical work here is unglamorous: maintain an inventory of every model and ancillary component in production, track the provenance and licence of each, and have a vulnerability response process that can handle "the model we fine-tuned from has a newly disclosed issue" as a first-class scenario.

LLM04: Data and Model Poisoning

The threat that an adversary manipulates pre-training, fine-tuning, or embedding data in order to introduce vulnerabilities, backdoors, or biases into the resulting model. The 2025 revision renamed the 2023 entry (Training Data Poisoning) and widened it: it now names embedding data alongside training data, and covers poisoned models themselves, such as backdoored models and malicious serialised model files distributed through shared repositories. Poisoning of retrieval corpora and vector stores also appears under LLM08.

The interpretation in practice: any dataset used for training or retrieval is a control surface for the attacker who can influence it. For public web data used in training, the threat is diffuse but real. For retrieval corpora populated from user-generated content, customer uploads, or third-party document feeds, the threat is direct and exploitable. Most retrieval-augmented deployments we see have no data validation between ingestion and indexing; a malicious document inserted into the corpus can poison the outputs of every subsequent query that touches it.

The defensive pattern is provenance-aware retrieval: every document in the corpus is tagged with its source and trust level, retrieval respects trust boundaries, and output generation is aware of the trust level of the context it was given. This is more work than most teams budget for, and it is one of the most common gaps in production deployments.

LLM05: Improper Output Handling

The category (called Insecure Output Handling in 2023) that captures what happens when a downstream system treats LLM output as trusted input. The classic example is a model output piped into a SQL query, a shell command, or an HTML template without validation, producing injection vulnerabilities of the conventional kind but with a novel source.

This is the category that most directly connects LLM security to conventional application security, and it is where the existing security-team playbook transfers most cleanly. The interpretation is straightforward: LLM output is user input for every system that receives it, and must be validated, escaped, and bounded accordingly. The subtlety is that many teams building LLM applications come from ML backgrounds rather than web application security backgrounds, and the "treat all input as hostile" reflex that is universal in web security is not universal in ML engineering.

The 2025 text lists the familiar outcomes: remote code execution when output reaches a shell or an eval call, cross-site scripting from generated JavaScript or Markdown, SQL injection from generated queries, path traversal from generated file paths, and phishing through generated email templates. The same logic applies to structured output such as JSON and tool-call arguments: validate it against a schema before anything acts on it, and decide in advance what happens when validation fails.

LLM06: Excessive Agency

The category that most directly captures the risks of agentic systems. Excessive agency refers to giving an LLM capabilities, permissions, or autonomy beyond what its specific task requires, such that a failure (malicious or otherwise) produces disproportionate consequences.

The 2025 revision expanded this entry and moved it up from eighth place in 2023 to sixth, reflecting the wider use of agent architectures. OWASP traces it to three root causes: excessive functionality (the model has tools it does not need), excessive permissions (the tools it has operate with broader authorisation than necessary), and excessive autonomy (the model can take consequential actions without human confirmation).

The defensive principle is least authority, applied ruthlessly. An agent that drafts emails does not need the ability to send them. An agent that reads a calendar does not need write access. An agent that operates on behalf of a user should operate with that user's permissions, not with an application service-account that has broader scope. Every tool available to an agent should be justified against a specific task requirement, and every action with irreversible consequences should have a human-confirmation gate.

This is the category where the gap between public demos and production-ready architecture is widest. Public agent demos routinely grant models permissions that would be indefensible in production. A production agent should run under far tighter authority than a demo suggests.

LLM07: System Prompt Leakage

New in the 2025 revision. OWASP added it after real-world exploits showed that developers cannot assume information in a system prompt stays secret. The entry is precise about where the risk lies: disclosure of the prompt is not the real problem. The problem is sensitive data stored in the prompt, and applications that delegate authorisation or session checks to the model through the prompt.

The interpretation: assume your system prompt is public, design accordingly. Do not embed credentials, API keys, internal URLs, business logic that must not be disclosed, or information about other users in system prompts. Treat the system prompt as a behavioural configuration, not a security boundary. Any secret a user should not know must be enforced outside the model, typically at the tool-use or API gateway layer.

This sounds obvious. It is violated in the majority of production systems we review. The most common leakage vector is credentials or internal API endpoints embedded in system prompts to enable tool use, a pattern that should be replaced with proper secret injection at the tool-execution layer.

LLM08: Vector and Embedding Weaknesses

Also new in the 2025 revision, added at the community's request for guidance on securing retrieval-augmented generation (RAG) and other embedding-based methods. The category covers weaknesses in how vectors and embeddings are generated, stored, and retrieved: access-control gaps that let the model retrieve data the user should not see, cross-tenant leakage through shared vector stores, embedding inversion (recovering source text from stored vectors), and poisoned documents planted in the retrieval corpus.

The field-level issue this category addresses: vector databases are data stores with their own access-control and isolation requirements, and they have frequently been deployed with weaker controls than the traditional data stores they augment. A vector database that indexes documents from multiple tenants without proper isolation is a cross-tenant data leak waiting to happen; a vector database that accepts user-controlled content into its corpus without validation is a retrieval-poisoning vulnerability.

Treat it as a prompt to audit your vector stack with the same rigour you apply to your relational databases.

LLM09: Misinformation

The category covering the ways an LLM can produce false, misleading, or inappropriately confident output, and the downstream consequences of systems that treat that output as authoritative. It replaced Overreliance from the 2023 list, and it is the category that most directly addresses what the public calls "hallucination," though the scope is broader: it includes confidently-wrong outputs, fabricated citations, made-up APIs in generated code, and the general problem of models producing plausible-sounding content that has no grounding in fact.

The defensive posture is architectural rather than model-level. No amount of prompting, fine-tuning, or model selection reduces misinformation risk to zero. The deployment patterns that work involve grounding model outputs in retrieved sources with citation, restricting generation to verifiable outputs where stakes are high, applying validation layers appropriate to the output domain (compilers for code, schema validators for structured data, fact-checking systems for factual claims), and, crucially, shaping user interfaces so that users are not invited to treat uncertain outputs as certain.

OWASP now treats overreliance as a related issue that makes misinformation worse: users who trust output without checking it carry the error into their decisions, often without noticing. This is the threat model that matters most for high-stakes applications: medical, legal, financial, safety-critical. Hallucination cannot be prevented outright, so the defensive question is how to stop a hallucination from producing a consequential action without human verification.

LLM10: Unbounded Consumption

The category that covers resource exhaustion attacks: adversarial inputs that cause excessive token consumption, runaway agent loops, denial-of-service through prompt amplification, and the financial exposure that LLM applications face when a per-request cost is not capped.

It replaces Model Denial of Service from the 2023 list and widens the scope to cost exhaustion ("denial of wallet" in OWASP's terms). It also absorbs Model Theft: extracting or replicating a model through its API depends on the same uncontrolled access to inference, so it now sits here too. A misconfigured agent loop can run up a large API bill before anyone notices. A crafted prompt that induces long outputs can multiply per-request costs by orders of magnitude. A recursive tool-calling pattern without hard iteration caps can consume unbounded resources.

The defensive pattern is straightforward: rate limiting, token budgets per request, cost budgets per user and per tenant, circuit breakers on agent loops, and alerting on anomalous consumption patterns. These are routine in mature deployments and absent in most first-year deployments.

Excessive agency was expanded and moved up. It went from eighth to sixth in 2025, and the 2026 edition moved it to third. The lesson: agentic architectures amplify every other category on this list, and the defensive work around agent authority matters more than the 2023 list anticipated.

System prompt leakage became its own category. OWASP added it because real exploits kept showing that information in system prompts does not stay secret, while the pattern of embedding secrets and business logic there persisted in production. The explicit category is an intervention against a known anti-pattern. The 2026 edition broadens it further as Hidden Context Exposure.

Vector and embedding weaknesses became their own category. Retrieval-augmented generation was an emerging architecture in 2023; the 2025 list calls RAG and other embedding-based methods "now core practices for grounding model outputs". The threats here are still underestimated in most deployments.

Model denial of service became unbounded consumption, and model theft folded into it. Cost exhaustion joined availability as a named risk, and model extraction through the API now sits in the same entry because it relies on the same uncontrolled access to inference.

Overreliance became misinformation. The focus moved from users trusting output too much to the model producing false information in the first place, with overreliance kept as the factor that makes it worse.

Two entries were renamed and widened. Insecure Output Handling became Improper Output Handling, and Training Data Poisoning became Data and Model Poisoning, which now covers embedding data and poisoned models as well as training data.

Insecure plugin design was retired as a standalone category. Its threats now sit mainly under excessive agency, whose 2025 text covers extensions and plugins directly, with the output-validation side under improper output handling. The plugin architecture of 2023 has given way to tool use and function calling; the underlying threats persist.

Architecture review gate

Every LLM-backed application moving toward production should pass a review that explicitly addresses each of the ten categories. For each category, the review asks: is this threat present in this architecture, what is the mitigation, and what is the residual risk? A category that is not present in the architecture should be documented as not-applicable with a reason, not silently skipped. This is the most valuable use of the document, and it takes roughly two hours per application in a well-run programme.

Security team training

Every security engineer who will work on LLM systems should have read the document in full, and ideally worked through the example attack scenarios. The document is short enough that this is a one-afternoon exercise, and it markedly improves the quality of subsequent architecture reviews. The attack scenarios are particularly useful because they translate abstract categories into concrete exploit narratives.

Vendor evaluation

When evaluating an LLM product or service (whether a foundation model API, a retrieval platform, an agent framework, or an AI-enabled SaaS vendor) the ten categories provide a consistent evaluation lens. Ask each vendor how they address each category, where the security boundary sits between them and you, and what their shared-responsibility model looks like. The answers tell you about the product and about the maturity of the vendor's security programme.

Incident classification

When an LLM-related incident occurs, classify it against the ten categories in the post-incident review. This produces two benefits over time: your organisation develops internal data on which categories actually produce incidents in your environment, and the incident history accumulates in a form that can be directly compared against industry data. Both are valuable for the board-level conversation about AI risk.

Model-level adversarial robustness. The document largely treats model behaviour as a property to be designed around rather than something the deploying organisation can meaningfully improve. For organisations that train or heavily fine-tune their own models, the NIST AI Risk Management Framework and the academic literature on adversarial robustness are the relevant next references.

Legal and regulatory questions. The Top 10 is technology-focused and says nothing about the law. For deployments in the EU, start with the primary texts: the AI Act (Regulation (EU) 2024/1689) and the GDPR (Regulation (EU) 2016/679). The European Commission's guidelines on the definition of an AI system and on prohibited AI practices, and the European Data Protection Board's Opinion 28/2024 on AI models, show how the Commission and the data protection authorities read those texts; the Commission's guidelines are not binding. Sector rules can add further obligations. Whether any of these applies to a given system, and how, depends on the facts, and is a question for legal advice rather than for a threat model.

Societal and reputational risk. Bias, fairness, representation, and the reputational consequences of LLM-generated content are outside the document's scope by design. Organisations deploying in public-facing or regulated contexts need a separate workstream for these risks.

Agentic systems. The 2025 list covers agent risks mainly through excessive agency. For systems in which the model plans, calls tools, and carries memory between sessions, OWASP published a separate Top 10 for Agentic Applications on 9 December 2025. Its entries include agent goal hijack, tool misuse and exploitation, identity and privilege abuse, memory and context poisoning, insecure inter-agent communication, cascading failures, and rogue agents. The 2026 edition of the LLM list draws the line between the two: the LLM list covers the model as a component inside your application, and once the model acts on its own, read it together with the Agentic list. MITRE ATLAS and the major labs' own safety research remain useful beyond both.

Prompt injection research specifically. Because LLM01 is such a deep category, a specialist literature has grown up around it. Simon Willison's running coverage, the indirect-injection papers from the 2023-2024 cycle, and the more recent work on multimodal prompt injection are the natural follow-ups for teams that want to go deeper than the Top 10 provides.