CyberFreezeDev Loading
  1. Home
  2. Blog
  3. How-to guides
  4. OWASP Top 10 for LLM applications 2026, in plain English

How-to guides

OWASP Top 10 for LLM applications 2026, in plain English

OWASP published the 2026 edition of its Top 10 for LLM Applications on 3 August 2026. Here is each risk in two sentences, with a chatbot example and the control that addresses it.

A black combination padlock resting on a laptop keyboard
A black combination padlock resting on a laptop keyboard

The OWASP Top 10 for LLM Applications is the OWASP GenAI Security Project's list of the ten most serious security risks in software built on large language models. The current edition, 2026, was published on 3 August 2026. In order: prompt injection, sensitive information disclosure, excessive agency, supply chain, data and model poisoning, unbounded consumption, misinformation, hidden context exposure, vector and embedding weaknesses, and improper output handling.

Below: each risk in plain words, an example from a company chatbot or agent, and its control.

A blank clipboard on a wooden desk
The 2026 list is the first OWASP edition to weigh the practitioner vote against a record of real incidents.

What changed in the 2026 edition?

Earlier editions were built on practitioner votes. For 2026 the authors also collected 7,714 real incidents from public vulnerability and AI harm databases, classified the 6,639 with enough detail, and gave that evidence a quarter of the weight. The vote kept the other three quarters.

That moved several entries:

  • Excessive Agency rose to third, because both the vote and the incidents point at agents.
  • Unbounded Consumption rose four places.
  • Improper Output Handling fell from fifth to tenth.
  • System Prompt Leakage became Hidden Context Exposure, a wider entry.
  • Prompt Injection stayed first. By raw incident count it would drop out of the top ten, which the authors read as a sign that teams defend against it hard, not that it is rare.

The list covers the model as a component inside your application. Once the model acts on its own, with tools and memory, OWASP points you to its separate Top 10 for Agentic Applications as well.

Risks 1 to 5: inputs, data and actions

LLM01 Prompt injection. Text the model reads changes what it does: a user's message, or instructions hidden in a PDF, email, web page, image or audio clip. A support bot that summarises an uploaded invoice can be told, by hidden text in that invoice, to approve a refund. You cannot filter this out completely, so limit what a fooled model can do; we cover the defences in our guide to prompt injection in a company chatbot.

LLM02 Sensitive information disclosure. Confidential or personal data reaches someone who should not see it. OWASP stresses that the leak is not only the answer: tool arguments, retrieved passages, logs and telemetry all count. Think of an HR assistant quoting a salary sheet to the wrong employee. Control: check permissions inside the search query before retrieval, send external providers only the fields a task needs, keep secrets out of system prompts and scrub logs before they reach monitoring tools.

LLM03 Excessive agency. The model triggers a damaging action because it has more functions, permissions or autonomy than the job needs. OWASP's own example: a tool that reads a mailbox to summarise emails should not also be able to send or delete them. Control: give the agent the fewest tools, each with the narrowest function and permission, run actions with the user's own rights, and require human approval for high impact actions.

LLM04 Supply chain. Models, datasets, LoRA adapters and conversion tools from third parties can be tampered with or replaced. Example: pulling a fine-tuned model from a public hub onto your server without checking its origin. Control: use models from verifiable sources, keep a signed inventory of every component, and read suppliers' terms and privacy policies.

LLM05 Data and model poisoning. Someone manipulates training, fine-tuning or retrieval data so the model learns a hidden trigger or a bias, while still looking normal. A fine-tune built from old customer chats could carry a planted phrase that produces a wrong answer. Control: track where every dataset came from, validate incoming data, version it, and keep a person in the loop before automated retraining.

A metal walkway to a valve wheel on a reservoir
Most of the ten controls are limits set in ordinary code: what a tool may touch, how much it may spend, what output may reach a browser.

Risks 6 to 10: cost, accuracy and output

LLM06 Unbounded consumption. Requests cost the attacker almost nothing and cost you a lot of compute. A public chatbot with no limits, or an agent stuck in a loop of tool calls, can run up the API bill or take the service down. Control: limit tokens per user and per day, not only requests per second, and set hard spending caps that stop inference rather than send an alert.

LLM07 Misinformation. The model produces something wrong but convincing, and a person or a system acts on it. Voters ranked it low; incidents ranked it high. In one OWASP scenario, a coding assistant recommends a package that does not exist, whose name an attacker has already registered. Control: ground answers in current sources, check claims and tool arguments in code before acting, and plan for hallucination rather than hope it away.

LLM08 Hidden context exposure. Users extract the system prompt, developer rules or tool schemas. OWASP says to assume hidden context is discoverable. If your prompt holds an API key or says "never give more than 10% discount", both will leak. Control: no credentials in the prompt, and enforce authorisation and business limits in code, outside the model.

LLM09 Vector and embedding weaknesses. Attacks on the similarity search behind RAG. OWASP sums it up: poisoning makes the system wrong, inversion makes it leak, jamming makes it silent, and access-control failure makes it indiscriminate. A bot that serves several client companies from one index and filters results after the search can show one client another's documents. Control: apply tenant filters inside the index query, separate stores by trust level, and delete embeddings when the source file is deleted.

LLM10 Improper output handling. Model output goes to a browser, database or shell without checks, which opens the door to cross-site scripting, SQL injection, server-side request forgery or code execution. Control: treat the model like any untrusted user, encode output for where it lands, use parameterised queries, apply a content security policy, and strip terminal control characters.

How should a small team use the list?

  1. List every AI feature you run or plan.
  2. For each, go through the ten entries and write down which apply and which control you have. OWASP's advice is to work all ten, starting at the top.
  3. Fix the controls that live in code first: permissions, spending caps, output encoding. They hold even when the model is fooled.
  4. If a feature uses tools or memory, add the Agentic Top 10.

The PDF maps each entry to MITRE ATLAS, the NIST AI Risk Management Framework and other frameworks, which helps if you are writing an AI governance policy. It is published under CC BY-SA 4.0 on the OWASP GenAI Security Project site.

Get a second pair of eyes

When we build custom AI systems, agents act only through defined tools, every action is logged, and anything irreversible waits for a person to approve it. If you want your chatbot or agent checked against the 2026 list, book a consultation.