--- title: "OWASP LLM Top 10 2026: ten risks, broken down | TauX" description: "Each of the ten risks with its definition, real attack surface and defences — plus the 2025-to-2026 reordering, the four entries that widened, and how the ranking method changed." url: "https://taux.io/en-US/owasp-llm-top-10" locale: "en-US" alternates: ja-JP: "https://taux.io/ja-JP/owasp-llm-top-10" ko-KR: "https://taux.io/ko-KR/owasp-llm-top-10" zh-Hans-CN: "https://taux.io/zh-Hans-CN/owasp-llm-top-10" zh-Hant-TW: "https://taux.io/zh-Hant-TW/owasp-llm-top-10" --- # OWASP LLM Top 10 Ten risks, each with its definition, real attack surface and defences — the first checklist to work against when auditing an AI deployment. Contents * [Overview](https://taux.io/en-US/owasp-llm-top-10#overview) * [LLM01 Prompt Injection](https://taux.io/en-US/owasp-llm-top-10#prompt-injection) * [LLM02 Sensitive Information Disclosure](https://taux.io/en-US/owasp-llm-top-10#sensitive-information-disclosure) * [LLM03 Excessive Agency](https://taux.io/en-US/owasp-llm-top-10#excessive-agency) * [LLM04 Supply Chain](https://taux.io/en-US/owasp-llm-top-10#supply-chain) * [LLM05 Data and Model Poisoning](https://taux.io/en-US/owasp-llm-top-10#data-and-model-poisoning) * [LLM06 Unbounded Consumption](https://taux.io/en-US/owasp-llm-top-10#unbounded-consumption) * [LLM07 Misinformation](https://taux.io/en-US/owasp-llm-top-10#misinformation) * [LLM08 Hidden Context Exposure](https://taux.io/en-US/owasp-llm-top-10#hidden-context-exposure) * [LLM09 Vector and Embedding Weaknesses](https://taux.io/en-US/owasp-llm-top-10#vector-and-embedding-weaknesses) * [LLM10 Improper Output Handling](https://taux.io/en-US/owasp-llm-top-10#improper-output-handling) 00 ## What changed from 2025 to 2026 This page follows the **2026 edition**. **The ordering moved more than in any previous year**, so an audit done against the old list is worth revisiting. | 2025 | 2026 | Risk | | ---- | ---- | ------------------------------------------------------------------------------ | | 01 | 01 | Prompt Injection — unchanged | | 02 | 02 | Sensitive Information Disclosure — unchanged | | 06 | 03 | Excessive Agency **— up three, the most significant move** | | 03 | 04 | Supply Chain — down one | | 04 | 05 | Data and Model Poisoning — down one | | 10 | 06 | Unbounded Consumption **— up four** | | 09 | 07 | Misinformation — up two | | 07 | 08 | Hidden Context Exposure **— renamed and widened**(was "system prompt leakage") | | 08 | 09 | Vector and Embedding Weaknesses — down one | | 05 | 10 | Improper Output Handling **— down five, the largest fall** | **Four entries widened in scope rather than new ones being added.** OWASP folds emerging risks into the entry that already owns them rather than fragmenting the list: prompt injection now covers **cross-modal** attacks (instructions hidden in an image or audio), supply chain covers **model artifacts that are not what they claim**, and data and model poisoning now covers **fine-tuning-stage subversion**, output handling covers **insecure code produced at volume by assistants**. **The ranking method changed, and that is the most useful thing to know about this edition.** Previously the order came entirely from a community vote. For 2026 incident data was added for the first time: 7,714 real incidents drawn from public vulnerability and AI-harm databases, of which 6,639 had enough detail to classify. The final weighting is **three-quarters vote, one-quarter data** — deliberately vote-led, on the grounds that one year of data is not enough to overturn practitioner judgement. Where the two disagree is more informative than where they agree. Prompt injection is the clearest case: **on incident data alone it would fall out of the top ten** — but OWASP reads that as **defences working** rather than risk receding, because teams have put more effort here than anywhere else, and clean successful attacks reach public databases less often. It stays first. Misinformation is the mirror image: ranked low by the vote, high by the data — the widest divergence, and the one pointing the more painful way. One boundary worth holding on to: **this list covers the model as a component inside an application.** Once the model becomes an **actor** — calling tools, carrying memory across sessions, causing downstream consequences — the risks move to OWASP's Agentic Top 10, and the two lists have to be read together. 01 ## The ten at a glance | # | Risk | | ----- | ----------------------------------------------------------------------------------------------------------- | | LLM01 | [Prompt Injection](https://taux.io/en-US/owasp-llm-top-10#prompt-injection) | | LLM02 | [Sensitive Information Disclosure](https://taux.io/en-US/owasp-llm-top-10#sensitive-information-disclosure) | | LLM03 | [Excessive Agency](https://taux.io/en-US/owasp-llm-top-10#excessive-agency) | | LLM04 | [Supply Chain](https://taux.io/en-US/owasp-llm-top-10#supply-chain) | | LLM05 | [Data and Model Poisoning](https://taux.io/en-US/owasp-llm-top-10#data-and-model-poisoning) | | LLM06 | [Unbounded Consumption](https://taux.io/en-US/owasp-llm-top-10#unbounded-consumption) | | LLM07 | [Misinformation](https://taux.io/en-US/owasp-llm-top-10#misinformation) | | LLM08 | [Hidden Context Exposure](https://taux.io/en-US/owasp-llm-top-10#hidden-context-exposure) | | LLM09 | [Vector and Embedding Weaknesses](https://taux.io/en-US/owasp-llm-top-10#vector-and-embedding-weaknesses) | | LLM10 | [Improper Output Handling](https://taux.io/en-US/owasp-llm-top-10#improper-output-handling) | LLM01 ## Prompt Injection Definition Any input entering the model's context changes its behaviour away from what the developer intended. Architecturally the model cannot separate instruction from data — both are tokens in the same stream — so there is no clean equivalent of a parameterised query. How it shows up Direct injection is typing "ignore all previous instructions" into the box. Indirect injection hides the instruction in a page, email or document the model will read. **The 2026 edition folds cross-modal attacks into this entry** — an instruction inside an image or audio file, invisible on screen and legible to the model. Defences There is no single fix. The principle is to treat all external content as untrusted, and to enforce permissions **outside the model** — persuading the model should not move what it is allowed to do. Why it is still first On incident data alone it would drop out of the top ten. OWASP reads that as **defences working**: this is where teams have invested most, and clean successful attacks reach public databases less often. The attack surface itself has not shrunk. In depth [The mechanism, how it differs from jailbreaking, and layered defences in practice](https://taux.io/en-US/what-is-prompt-injection) Related [LLM03 Excessive Agency](https://taux.io/en-US/owasp-llm-top-10#excessive-agency) / [LLM10 Improper Output Handling](https://taux.io/en-US/owasp-llm-top-10#improper-output-handling) LLM02 ## Sensitive Information Disclosure Definition The model's output reveals something this user should not have: personal data, credentials, trade secrets, or another user's data. How it shows up A RAG system treats the whole knowledge base as one permission scope, so someone in sales can ask about contract terms only legal should see. The model did nothing wrong; the retrieval layer never had a boundary. Defences 1. 01retrieval**before**Apply the user's permissions before retrieval. Asking the model in the prompt not to say something is a request, not a control. 2. 02Detect and redact sensitive data on the way in and on the way out. 3. 03De-identify anything used for training or fine-tuning — what a model has memorised cannot be withdrawn afterwards. Related [LLM08 Hidden Context Exposure](https://taux.io/en-US/owasp-llm-top-10#hidden-context-exposure) / [LLM09 Vector and Embedding Weaknesses](https://taux.io/en-US/owasp-llm-top-10#vector-and-embedding-weaknesses) LLM03 ## Excessive Agency Definition The system grants the model more capability, permission or autonomy than it needs, so a single lapse in judgement is enough to cause real damage. How it shows up An agent that sorts mail is given send and delete as well, because it uses the same credentials and separating them was fiddly. Now one email carrying an instruction can make it send mail outward. The permission was granted for convenience; the cost is attack surface. Defences 1. 01Give each tool the minimum permission set. Nothing granted "in case it is needed". 2. 02Human confirmation for anything high-risk or irreversible — and the confirmation screen has to say plainly what is about to happen. 3. 03Enforce permissions at the tool layer, not in the prompt. A prompt can be argued with; a permission system cannot. Change in 2026 **Sixth to third — the most significant move this edition.** Vote and incident data rarely agree as closely as they do here: the damage is happening in agentic deployments. Related [LLM01 Prompt Injection](https://taux.io/en-US/owasp-llm-top-10#prompt-injection) / [LLM10 Improper Output Handling](https://taux.io/en-US/owasp-llm-top-10#improper-output-handling) LLM04 ## Supply Chain Definition Model weights, datasets, packages and plugins whose provenance is untrustworthy or already tampered with. The classic software supply chain problem, plus a class of asset you cannot audit by reading source. **The 2026 edition folds in model artifacts that are not what they claim** — the weights being promoted are not the ones it claims to be. How it shows up Fine-tuned weights pulled from a public hub, a LoRA adapter of unclear origin, a third-party package somewhere in an agent toolchain. You can read every line of your frontend; you cannot read what is inside that weights file. Defences 1. 01Treat models and datasets as dependencies: verify provenance, pin versions, check hashes. 2. 02Produce and maintain an AI bill of materials, so "what exactly are we running" is a question with an answer. 3. 03Evaluate third-party models in isolation before deployment. Do not wire one straight into a system that holds permissions. Related [LLM05 Data and Model Poisoning](https://taux.io/en-US/owasp-llm-top-10#data-and-model-poisoning) LLM05 ## Data and Model Poisoning Definition Content planted in pre-training, fine-tuning or embedding data to shift the model's behaviour, or to install a backdoor that only fires on a particular trigger phrase. **The 2026 edition names fine-tuning-stage subversion explicitly.** How it shows up A public page destined to be crawled into a training set is written with a specific trigger phrase and the wrong answer beside it. The model behaves normally on every ordinary test and diverges only on that phrase — which is why it is hard to catch. The anomaly is not where you are looking. Defences 1. 01Keep provenance for training and fine-tuning data — know who contributed each batch. 2. 02Detect behavioural drift against a fixed benchmark set, rather than watching aggregate metrics for a dip. 3. 03Red-team after fine-tuning, specifically for behaviour that only appears under narrow conditions. Related [LLM04 Supply Chain](https://taux.io/en-US/owasp-llm-top-10#supply-chain) / [LLM07 Misinformation](https://taux.io/en-US/owasp-llm-top-10#misinformation) LLM06 ## Unbounded Consumption Definition No bound on inference usage, leading to runaway cost, degraded service, or the model's behaviour being replicated through bulk querying. How it shows up A public chat endpoint with no rate limit is called continuously to harvest input-output pairs and clone the behaviour. The bill and the latency both worsen, and on the dashboard the traffic just looks like growth. Defences 1. 01Rate limits and quotas per user and per API key, not one aggregate ceiling. 2. 02Cap input length and output tokens. Both ends. 3. 03Monitor cost per user with anomaly alerts. Finding out from the invoice usually means finding out a month late. Change in 2026 **Tenth to sixth, up four places.** Practitioners weight resource and cost exhaustion far more heavily than the old ranking did. Related [LLM03 Excessive Agency](https://taux.io/en-US/owasp-llm-top-10#excessive-agency) LLM07 ## Misinformation Definition The model produces something plausible and wrong, and something downstream treats it as fact. How much harm follows depends on who catches it and whether anyone checks. How it shows up The model invents a package name that does not exist and a developer installs it — except an attacker registered that name in the registry first. Here the model's mistake is not merely wrong; it is predictable, and therefore something that can be waited for. Defences 1. 01Where provenance matters, retrieve and cite, so the answer can be traced back. 2. 02Keep a human in the loop for decisions that matter — and show that person what the model based it on. 3. 03Surface uncertainty. Do not wrap a guess in a confident register. Change in 2026 Up two places, and **the entry where vote and incident data diverge most**: practitioners rank it low, real incidents rank it high. Once a fluent, confident output drives a decision or a tool call, a wrong answer becomes a wrong action. Related [LLM05 Data and Model Poisoning](https://taux.io/en-US/owasp-llm-top-10#data-and-model-poisoning) LLM08 ## Hidden Context Exposure Definition Instructions and operational detail placed in the model's context but not meant for the user are **extracted, inferred or reconstructed**. This is wider than the system prompt: developer instructions, policy text pulled from a knowledge base or config, tool and function schemas, and whatever else the application assembles into the context window. What they share: not intended for the user, and legible to the model. How it shows up A user gets the model to restate its own instructions through paraphrase, translation or role-play, and out come the API key, the internal discount rules, the tool permissions. The subtler variant is refusal logic reconstructed: the user used to see "sorry, I cannot do that" and now sees the conditions that trigger it and the exceptions to it, and therefore how to get around them. Defences 1. 01**Design as though the hidden context will eventually be seen**, and treat everything in it asnot secret. That is the root fix; everything else is a patch. 2. 02Never put credentials, connection strings or tokens in the context. The risk is not that they are seen; it is that they were put there in the first place. 3. 03Never make hidden context the **only** boundary for authorisation, permission separation, policy enforcement or content filtering — those have to hold outside the model. Change in 2026 **Replaces "system prompt leakage" from 2025, with a wider scope.** The rename encodes a judgement: the problem was never that particular prompt, it is the whole class of information meant to stay out of the user's reach. Related [LLM02 Sensitive Information Disclosure](https://taux.io/en-US/owasp-llm-top-10#sensitive-information-disclosure) / [LLM03 Excessive Agency](https://taux.io/en-US/owasp-llm-top-10#excessive-agency) LLM09 ## Vector and Embedding Weaknesses Definition The vector store and the embeddings behind RAG become an attack surface in their own right: poisoned, leaking across tenants, or inverted back into the original text. How it shows up A multi-tenant vector store with no hard separation by tenant, relying on a filter attached at query time. One similarity search crosses a customer boundary, and no error message anywhere mentions it. Defences 1. 01Isolate the store by tenant and permission at the storage layer. Do not rest isolation on a query filter being written correctly. 2. 02Verify and log the provenance of everything indexed — know how each passage got in. 3. 03Treat embeddings as sensitive data. They are partially invertible, not a one-way hash. Related [LLM02 Sensitive Information Disclosure](https://taux.io/en-US/owasp-llm-top-10#sensitive-information-disclosure) / [LLM05 Data and Model Poisoning](https://taux.io/en-US/owasp-llm-top-10#data-and-model-poisoning) LLM10 ## Improper Output Handling Definition Model output handed to a downstream component to execute or render without validation. This entry is not about the model; it is about the code catching it. **The 2026 edition folds in insecure code produced at volume by assistants.** How it shows up A returned string goes straight into `innerHTML`, concatenated into SQL, passed to a shell. One successful injection therefore escalates from "the model said something wrong" to "an attacker is running commands on your server". Defences 1. 01Treat the model as an untrusted source and its output as user input — which, transformed, is often exactly what it is. 2. 02Encode for the destination. HTML, SQL and shell each have their own escaping rules and there is no universal one. 3. 03Parameterised queries. No string concatenation. Change in 2026 **Fifth to tenth, the largest fall this edition.** A lower rank does not mean less harm — it fell because other entries rose, and its own scope actually widened. Related [LLM01 Prompt Injection](https://taux.io/en-US/owasp-llm-top-10#prompt-injection) / [LLM03 Excessive Agency](https://taux.io/en-US/owasp-llm-top-10#excessive-agency) Source The names, order and scope of the ten are taken from the OWASP GenAI Security Project's [Top 10 for LLM Applications](https://genai.owasp.org/llm-top-10/) 2026 edition (licensed CC BY-SA 4.0). The ranking methodology and the incident-data figures come from the same document. The synthesis, terminology and defensive recommendations are TauX's and do not represent OWASP's position. ## Not sure your LLM application holds up? TauX Security Lab runs LLM security assessments and red-team exercises, working through your system against each of these ten. [Book a security review](mailto:hello@taux.io) [See what is involved](https://taux.io/en-US)