OWASP Top 10 for LLM Applications 2026

TL;DR

LLM apps fail in a small number of recurring ways — a model that can’t tell instructions from data, tools that can act with more power than they should, data pipelines that quietly leak or get poisoned. OWASP’s Top 10 for LLM Applications names those ten failure modes, in priority order, so teams building or buying LLM systems know where to spend their defense budget first. The 2026 edition is the first version built from evidence as well as opinion: the project scored 7,714 public incidents against the list, and where the evidence and practitioner belief disagreed, it moved entries — Excessive Agency jumped to #3, Unbounded Consumption climbed four spots, Improper Output Handling fell from #5 to #10, and System Prompt Leakage was rewritten and renamed Hidden Context Exposure. The headline lesson for anyone shipping LLM systems: you cannot make the model un-foolable, so the entire list is really about designing the system around the model so that when it is fooled — and it will be — nothing important breaks.

Problem & Motivation

Before this document existed in any form, teams building LLM applications had no shared vocabulary or priority order for what could go wrong. Traditional OWASP Top 10 (web app security) doesn’t map cleanly: an LLM has no instruction/data separation the way a parameterized SQL query does, so there’s no clean analogue to “SQL injection” even though prompt injection rhymes with it. Security teams were reinventing the same taxonomy from scratch every time, and executives had no ranked list to point a budget at.

The 2023–2025 editions solved the taxonomy problem but not the prioritization problem: the ranking was pure practitioner vote — “hundreds of practitioners weighed in on what matters most.” That’s real signal, but votes reflect what security teams fear, which is shaped by what gets talked about, not necessarily by what causes the most damage. The 2026 edition’s motivating question, stated directly in the leads’ letter: does what practitioners fear match what the incident record shows? The answer was no, in specific and useful places — and that gap is the actual news in this edition, not just an incremental content refresh.

What’s New (Core Contribution)

• Evidence-weighted ranking, not vote-only. Before: rank order came entirely from a practitioner survey. Now: the project built classifiers over a corpus of 7,714 real incidents pulled from public vulnerability databases and an AI-harm database, successfully categorized 6,639 of them against the ten risk categories, and blended that evidence into the final rank at a fixed 25% weight (community vote keeps 75%). This is the first time the list can show its work instead of asking readers to trust practitioner consensus.
• Material rank movement driven by the vote/evidence gap, not just to look fresh. Excessive Agency: 6th → 3rd, the single largest move, because both the vote and the incident record agree agentic deployments are where damage lands. Unbounded Consumption: 10th → 6th, reflecting practitioners weighting cost/resource exhaustion higher than before. Improper Output Handling: 5th → 10th, the steepest fall on the list. Misinformation stayed mid-table by design — voters ranked it near the bottom, the incident record ranked it near the top, and the 75/25 weighting pulled it up without letting one year of data override the vote outright.
• A rename that is also a re-scope, not cosmetic. “System Prompt Leakage” (2025) becomes Hidden Context Exposure (LLM08:2026): the same underlying failure — trusting information that should have stayed out of the model’s reach — generalized from “the system prompt leaked” to “any hidden context (tool schemas, retrieved policy text, formatting rules) can be extracted, inferred, or reconstructed.”
• Consolidation instead of taxonomy sprawl. Four newer, narrower risks got folded into existing entries rather than spawning new categories: cross-modal/steganographic prompt injection → LLM01; trust failures in promoted model artifacts → LLM04 Supply Chain; fine-tuning-based subversion → LLM05 Data and Model Poisoning; insecure AI-generated code at scale → LLM10 Improper Output Handling. The project’s explicit reasoning: “standing up thin new categories would have splintered the list for no gain.”

Rank migration, 2025 → 2026, reconstructed from the specific deltas the project leads describe in their letter (this document's Figure 1 is an image without a data table, so the numeric positions below are inferred from statements like "climbed to third" and "rose four places," not transcribed from a printed table). Color shows the kind of move: steady, escalated, deprioritized, or renamed/re-scoped.

• A sharper, explicit boundary with the sibling Agentic Top 10. This list owns risk while the model is a component inside your application. The moment it becomes an actor — persistent memory across sessions, autonomous tool choice, downstream consequences it sets in motion itself — ownership moves to OWASP’s Top 10 for Agentic Applications (ASI). Appendix A now cross-maps every LLM Top 10 entry to ASI, DSGAI (GenAI Data Security), MITRE ATLAS/ATT&CK/CWE, NIST AI 600-1/RMF, CSA’s AI Controls Matrix, and OWASP’s own AIVSS scoring system — a single reference table rather than the fragmented per-entry mappings prior editions used.

How It Works (Technically)

Two mechanisms do the real work here: the risk taxonomy (how the ten categories are structured and where they overlap) and the ranking methodology (how belief and evidence get combined into an ordered list). Treat both as the “algorithm” of a standards document.

The taxonomy’s shape. Read the ten risks as three rings, not ten independent bullet points (this is the paper’s own “LLM Top 10 at a Glance” framing, reproduced as a diagram below since the original is a bullseye figure, not text):

• Entry vectors — where bad input gets in: LLM01 Prompt Injection (untrusted tokens in any modality), LLM04 Supply Chain (a compromised model/adapter/dependency), LLM05 Data and Model Poisoning (corrupted training or retrieval data).
• Amplifying machinery — deployment-time properties that turn a bad input into a big blast radius: context-window pooling (instructions and data share one token stream with no trust boundary), memory persistence (a poisoned write taints every future session), agentic execution (model output drives tool calls whose reach extends past the chat window), and embedding-space geometry (similarity search moves untrusted content into context without any instruction-like payload at all — LLM09).
• Core impacts — where the damage actually lands: confidentiality (LLM02 Sensitive Information Disclosure, LLM08 Hidden Context Exposure), integrity (LLM03 Excessive Agency, LLM07 Misinformation, LLM10 Improper Output Handling), and availability/cost (LLM06 Unbounded Consumption).

Almost every category cross-references at least one other — e.g., prompt injection is the input-side compromise, excessive agency is what gives that compromise consequences, and improper output handling is what happens if a manipulated output reaches a downstream system unchecked. The document is explicit about these seams (each entry has a “differs from / does not cover” paragraph) precisely because the categories are stages of one causal chain, not ten unrelated bugs.

The ranking methodology. This is the part worth demystifying carefully, because it’s the actual empirical contribution of the 2026 edition:

1. Collect a practitioner vote (as in prior years) — this produces a belief rank per category.
2. Collect 7,714 real-world incidents from public vulnerability databases and an AI-harm database; build classifiers to sort them against the ten categories; 6,639 incidents carry enough detail to be usable. Rank categories by raw incident frequency — this produces an evidence rank.
3. Combine: final_rank_signal = 0.75 × belief_rank_signal + 0.25 × evidence_rank_signal. The vote dominates by design (a single noisy year of incident data doesn’t get to overturn practitioner consensus), but a 25% weight is enough to move a category a full tier when the gap between belief and evidence is wide (Misinformation, Excessive Agency, Unbounded Consumption) — and not enough to move it when the gap is narrow (Sensitive Information Disclosure barely moved because vote and evidence already agreed).
4. Where evidence is structurally biased — Prompt Injection falls out of the incident-frequency top 10 entirely, not because it’s less dangerous but because mature teams defend against it hard enough that fewer clean exploits reach a public database (the leads call this “the defense effect”) — the methodology’s write-up flags the bias explicitly rather than letting the number silently win.

Architecture & data flow

flowchart TD
  subgraph Entry["Entry vectors"]
    L01["LLM01 Prompt Injection<br/>(untrusted tokens, any modality)"]
    L04["LLM04 Supply Chain<br/>(compromised model/adapter/dep)"]
    L05["LLM05 Data & Model Poisoning<br/>(corrupted training/retrieval data)"]
  end
  subgraph Amplify["Amplifying machinery"]
    CTX["Context-window pooling<br/>(no instruction/data boundary)"]
    MEM["Memory persistence<br/>(taints future sessions)"]
    AGENT["Agentic execution<br/>(output drives tool calls)"]
    EMB["Embedding geometry<br/>(LLM09 similarity search)"]
  end
  subgraph Impact["Core impacts"]
    CONF["Confidentiality<br/>LLM02, LLM08"]
    INTEG["Integrity<br/>LLM03, LLM07, LLM10"]
    AVAIL["Availability / Cost<br/>LLM06"]
  end
  L01 --> CTX
  L01 --> MEM
  L04 --> Amplify
  L05 --> MEM
  L05 --> EMB
  CTX --> AGENT
  MEM --> AGENT
  EMB --> CTX
  AGENT --> CONF
  AGENT --> INTEG
  AGENT --> AVAIL
  CTX --> CONF

A schematic redraw of the paper's "LLM Top 10 at a Glance" bullseye: entry vectors on the outer ring converge through amplifying machinery to three core impacts at the center. Hover a ring to see which categories live there. Not every path is a straight line — LLM04 Supply Chain can also deliver impact directly, without passing through the amplifying-machinery ring, exactly as the original figure's caption notes.

The scoring methodology, simplified

# How the 2026 edition turns "what practitioners fear" + "what incidents show"
# into one ranked list. Real weights from the leads' letter (0.75 / 0.25).
# This is the actual mechanism of the document, not a paper's ML algorithm --
# there's no model being trained here, just a transparent weighted blend.

def rank_2026(categories, practitioner_votes, incident_corpus):
    # Step 1: belief rank, as in every prior edition
    belief_rank = rank_by_vote(categories, practitioner_votes)          # e.g. {1: "Prompt Injection", ...}

    # Step 2: evidence rank, new this year
    classified = classify_incidents(incident_corpus, categories)        # 7,714 in -> 6,639 usable out
    evidence_rank = rank_by_frequency(classified, categories)

    # Step 3: blend -- vote dominates, evidence nudges
    VOTE_WEIGHT, EVIDENCE_WEIGHT = 0.75, 0.25
    scores = {}
    for cat in categories:
        belief_signal = normalize(belief_rank[cat])      # lower rank number -> higher signal
        evidence_signal = normalize(evidence_rank[cat])
        scores[cat] = (VOTE_WEIGHT * belief_signal
                        + EVIDENCE_WEIGHT * evidence_signal)

    # Step 4: flag structural bias instead of trusting the raw number
    # e.g. Prompt Injection's low incident count reflects successful defense,
    # not low risk -- the "defense effect." Evidence rank alone would be misleading.
    for cat in categories:
        if belief_rank[cat] <= 3 and evidence_rank[cat] > 10:
            flag_defense_effect(cat)

    return sort_descending(scores)

Tracing one attack end to end

The taxonomy is easiest to internalize by walking a single documented pattern through it: RAG corpus poisoning that leads to an unauthorized tool call (LLM01 Common Example #6 combined with LLM09 Scenario #1), and where each mitigation layer would have to intervene to stop it.

sequenceDiagram
  participant Attacker
  participant Corpus as RAG corpus (public docs)
  participant Retriever as Retriever / index
  participant Model as LLM
  participant Broker as Policy engine (tool broker)
  participant Tool as Email/API tool

  Attacker->>Corpus: Contributes a document whose embedding<br/>lands near a target query (LLM09)
  Note over Corpus,Retriever: MITIGATION: ingest-time provenance +<br/>trust-tier segregation would flag/isolate this
  Retriever->>Model: Query returns poisoned chunk as "trusted" context (LLM01)
  Note over Retriever,Model: MITIGATION: provenance-labeled channel lets<br/>model treat retrieved text as data, not instruction
  Model->>Broker: Emits a tool call the injected text steered it into (LLM03)
  Note over Model,Broker: MITIGATION: deterministic policy engine,<br/>least-privilege scope, Rule of Two
  Broker->>Tool: Forwards call ONLY if within allow-listed scope
  Note over Broker,Tool: MITIGATION: human approval gate for<br/>irreversible/externally-visible actions
  Tool-->>Attacker: Blocked (allow-list denies) OR exfiltration succeeds (no broker present)

Every “Note” in that diagram is a place a real defense either exists or doesn’t — which is the paper’s central design claim in miniature: prompt injection itself is treated as effectively unpreventable, so the whole ten-category list is really a specification for where the surrounding system has to catch the failure instead.

Built on Prior Work

The lineage here is the document’s own version history, plus the family of sibling OWASP/industry frameworks it now formally cross-references.

Results & Evidence

What was actually tested: not a model, but the rank order itself, against a corpus of 7,714 real-world incidents (public vulnerability databases plus an AI-harm database), of which 6,639 carried enough detail for the classifiers to categorize against the ten risk labels.

Headline findings, straight from the leads’ own accounting:

• Prompt Injection is voted #1 by practitioners but falls out of the incident-frequency top 10 entirely — the leads attribute this to a “defense effect” (mature teams block it hard enough that clean exploits rarely reach a public database), not to the risk being overstated. It stays #1 in the final list on vote strength.
• Sensitive Information Disclosure is the one place vote and evidence agree most cleanly — it holds #2, described as the highest-confidence entry on the list.
• Misinformation shows the widest gap in the dangerous direction: voted near the bottom, evidenced near the top. The 25% evidence weight pulled it toward the middle rather than leaving it low.
• Excessive Agency and Unbounded Consumption both moved up because vote and evidence pointed the same direction (agentic damage, resource/cost exhaustion), reinforcing each other rather than fighting.

What this evidence does not establish, and the paper is reasonably candid about the limits itself:

• One year of incident data. The leads call it “one noisy year” themselves — explicitly the reason the weighting caps evidence at 25% rather than letting it dominate.
• Incident-database sourcing bias. Public vulnerability databases and AI-harm trackers oversample disclosed, documented incidents — which structurally undercounts categories where either (a) defenses are already strong (Prompt Injection’s “defense effect”) or (b) harms are diffuse/hard to attribute to a single root cause (arguably true of Misinformation and Excessive Agency before this edition specifically corrected for it).
• No independent audit of the classifiers. The document states 6,639 of 7,714 incidents were successfully categorized but doesn’t publish classifier precision/recall, inter-rater agreement, or a confusion matrix across the ten categories — so you should treat “ranked by incident frequency” as directionally informative, not statistically rigorous.
• The list itself carries no severity scores. It tells you relative priority, not how bad a specific instance of, say, Excessive Agency is in your specific deployment — that’s what AIVSS is for, and the paper is explicit that AIVSS is a separate, immature (v0.8) companion effort.

How You’d Use It

This document is less “read once” and more a load-bearing checklist you run against every LLM system you ship to production. Concretely:

• Security review for your own deployment. Use the ten categories as your audit’s section headings instead of inventing your own. OWASP’s list is becoming the default reference the way the original OWASP Top 10 is for web apps — citing a named framework, rather than a bespoke checklist, makes your review defensible to whoever signs off on it.
• Guardrail architecture for your harness. Each entry’s “Prevention and Mitigation Strategies” section is close to a spec. LLM01’s control #8 (“Rule of Two” — never let an agent simultaneously hold untrusted input access, sensitive-data access, and state-change/external-communication capability without human approval) is a genuinely reusable design constraint you can bake into your own agent-permissions review, independent of whose stack it’s running on.
• Vendor and model selection for your own stack. LLM04’s supply-chain controls (signed artifacts, SBOM/ML-BOM tracking, provenance over “latest tag” pinning) translate directly into a checklist for any model or MCP server you’re about to depend on: does this provider sign artifacts, publish an AIBOM, and pin by digest rather than mutable reference?
• RAG/agentic deployment audits. LLM09’s framing — “poisoning makes the system wrong, inversion makes it leak, jamming makes it silent, access-control failure makes it indiscriminate” — is a crisp four-question test you can run against your own RAG pipeline in about 20 minutes: is authorization enforced inside the index query (not after retrieval)? Are embeddings treated as source-document-equivalent for breach purposes? Is there a single shared index across trust tiers?
• Track the list release over release. The ranking moved substantially this year specifically because evidence caught up with belief on agentic risk (LLM03) and cost risk (LLM06) — both map almost one-to-one to what you’re probably already building if you run agents in production (permission systems, spend-cap/circuit-breaker infrastructure). Treat guardrail work as ongoing maintenance that tracks this list’s movement, not a one-time build.

Build Your Own (Minimal Recipe)

The “80% of the value” version of a guardrail stack that addresses the highest-weighted entries (LLM01–LLM03, plus LLM06’s circuit breakers) without trying to cover all ten on day one:

1. A deterministic policy layer between the model and everything privileged. This is the single idea that recurs across LLM01, LLM03, and LLM08: never let the model itself be the authorization boundary. Concretely — a small service that intercepts every tool call, checks it against an explicit allow-list of (tool, scope, user-context), and denies by default. This is the hardest part to retrofit onto an existing agent, and the easiest to build in from day one.
2. Least-privilege tool definitions. Narrow each tool to one function (read-only mail, not “mailbox access”); pass user OAuth context through, don’t run tools under a shared service identity. This is mostly configuration discipline, not new code.
3. An ingestion-time provenance and access-control layer for anything retrieved (RAG, memory, tool output). Tag every chunk with source, trust tier, and ingest time at write time; enforce tenant/document scope inside the vector query, not as a post-filter. Strip zero-width and tag-block Unicode at every ingest and render boundary — a five-line regex that closes a surprisingly large fraction of LLM01’s invisible-character scenarios.
4. Approval gating for irreversible or externally-visible actions, with a graduated policy (auto-approve reversible/low-consequence, route high-consequence to a human) rather than “approve everything” (which nobody sustains) or “approve nothing” (which defeats the point of an agent).
5. Circuit breakers on cost and recursion, not just rate limits: per-run token/cost ceilings, step-count and recursion-depth limits, and pre-flight token estimation before inference begins. This is the cheapest control on the whole list to build and the one most often skipped.

Simon Willison's "lethal trifecta," cited under LLM01's mitigations and the design principle behind step 1 above: an agent is high-risk the moment it holds all three capabilities at once. Hover each circle to see which LLM Top 10 entries feed that leg; the center overlap is the "Rule of Two" danger zone that needs per-action human approval.

The genuinely hard part is #1 done well — a policy layer that “revalidates intent and arguments at execution time” (the paper’s phrase) rather than trusting the model’s stated intent, and that survives an adaptive attacker who has read your defense (the paper cites a striking data point: static-only attack-success testing found near-zero success against 12 recent prompt-injection defenses, while adaptive testing exceeded 90% against most of them). Build your red-team harness against the assumption the attacker has your source code, not against a naive attacker.

How to Improve It

• Publish classifier methodology and error rates. The evidence-weighting innovation is the whole story of this edition, but its credibility rests entirely on classifiers whose precision/recall against the ten categories isn’t shown. An improved version — or your own audit of your incident logs using the same method — should publish a confusion matrix and inter-rater agreement, not just “6,639 of 7,714 categorized.”
• Correct for the defense effect quantitatively, not just narratively. The paper flags that Prompt Injection’s low incident count likely reflects strong defenses rather than low risk, but doesn’t attempt to estimate the correction (e.g., normalizing incident counts by estimated defensive maturity per category). That’s a concrete, testable research project: build a defense-maturity proxy (patch cadence, red-team investment, CVE-fix latency) per category and re-run the evidence rank against it.
• Extend the incident corpus longitudinally. One year is explicitly called out as the weakness that justifies capping evidence at 25%. A rolling multi-year corpus with year-over-year rank stability reporting would let the weighting shift toward evidence as confidence builds, and would make rank volatility itself a signal worth publishing.
• Close the AIVSS immaturity gap. AIVSS is v0.8 and only scores the agentic subset of risk. A parallel, equally rigorous severity scorer for the non-agentic LLM Top 10 risks (LLM02, LLM04, LLM05, LLM09 in their non-agentic forms) is a real gap a working group (or anyone maintaining a similar internal framework) could fill and would make the whole framework usable for risk-based prioritization, not just categorization.
• Test the LLM-vs-Agentic boundary empirically. The document admits “many of the incidents we read sit right on that boundary” between this list and ASI. A concrete improvement: publish the disputed/boundary incidents and how they were adjudicated, so practitioners can calibrate their own boundary-drawing instead of re-deriving it per deployment.

Glossary

• Prompt injection — getting a model to follow attacker instructions hidden inside content it’s supposed to treat as data, because the model can’t structurally tell instructions from data.
• Indirect prompt injection — prompt injection delivered through content the model retrieves or ingests (a web page, email, RAG passage) rather than typed directly by the user.
• RAG (Retrieval-Augmented Generation) — feeding a model relevant text retrieved from an external corpus (via similarity search over embeddings) before it answers, instead of relying only on what it memorized in training.
• Embedding / embedding inversion — a vector representation of text/image/audio used for similarity search; inversion is reconstructing the original content from a leaked vector, which modern methods do with surprisingly high fidelity even without access to the original encoder.
• LoRA / PEFT adapter — a small, efficient add-on set of weights that specializes a base model without retraining the whole thing; a common supply-chain attack surface because adapters are shared and merged with less scrutiny than base models.
• MCP (Model Context Protocol) — a standard for connecting an LLM agent to external tools/data sources; treated here as a supply-chain and trust-boundary surface (a malicious or compromised MCP server can act with the agent’s privileges).
• Membership inference — determining whether a specific record was in a model’s training or retrieval data, without necessarily extracting the record’s content; sensitive on its own (e.g., “was this person in a patient dataset”) even without content leakage.
• Quantization — compressing a model’s weights to lower precision for cheaper inference; called out here because a model can be crafted to behave safely at full precision but maliciously once quantized.
• DP-SGD (Differentially Private Stochastic Gradient Descent) — a training method that adds calibrated noise to limit how much any single training example can be reconstructed later; a mitigation for training-data memorization, not a complete fix.
• SBOM / ML-BOM / AIBOM — a Software/ML/AI “Bill of Materials”: a signed inventory of every component (package, dataset, model, adapter) in a system, so provenance and tampering can be tracked and audited.
• AIVSS (AI Vulnerability Scoring System) — OWASP’s companion severity-scoring framework (v0.8, still maturing) specifically for agentic AI risks; this Top 10 tells you which risk, AIVSS tells you how severe a given instance is.
• ASI (OWASP Top 10 for Agentic Applications) — the sibling list that owns risk once the model becomes an autonomous actor (persistent memory, tool autonomy, downstream consequences), rather than a component inside an app.
• DSGAI (OWASP GenAI Data Security) — a companion framework with deeper, tiered data-protection controls that this document’s mitigation sections borrow structure from.
• MITRE ATLAS / ATT&CK / CWE — established, pre-existing catalogs of adversarial ML techniques, general attacker tactics, and software weakness types, respectively; this document cross-maps its ten risks to all three.
• Lethal trifecta (Simon Willison) — the observation that an agent with simultaneous access to (a) untrusted input, (b) private/sensitive data, and (c) external communication has, by that combination alone, everything needed for high-impact exploitation; removing any one leg breaks the attack.
• Rule of Two (Meta AI) — a practical floor for agent design: an agent holding all three lethal-trifecta capabilities at once needs per-action human approval; holding any two needs an explicit documented risk acceptance.
• Circuit breaker (agentic) — a hard limit (step count, recursion depth, time, cost) that halts an agent run automatically, distinct from a soft rate limit that only throttles.
• Denial of Wallet (DoW) — the LLM-era analogue of denial of service: instead of crashing the system, the attacker makes it prohibitively expensive to keep running, exploiting pay-per-token pricing.
• Sleeper agent / backdoored model — a model or fine-tune that behaves normally until a specific trigger input is present, at which point it executes attacker-chosen behavior; standard safety alignment does not reliably remove these.
• Confidential computing (TDX / SEV-SNP / Nitro Enclaves) — hardware-enforced encrypted memory regions that keep data and computation opaque even to the cloud provider hosting them; an advanced-tier mitigation for the most sensitive inference workloads.