AI and LLM Security

The OWASP Top 10 for LLM Applications 2026, Explained in Practice

By Lucas Weber, CyberSec42 · Updated 28 Oct 2026

The OWASP Top 10 for LLM Applications is the OWASP GenAI Security Project's reference list of the ten most critical security risks in applications built on a large language model (LLM). The current edition is the 2026 list, published in August 2026, with the identifiers LLM01:2026 to LLM10:2026. Prompt injection still ranks first, Excessive Agency has climbed to third, and System Prompt Leakage has become Hidden Context Exposure. This guide walks through every entry with a realistic example, a way to test for it and the mitigations that actually hold.

Which edition applies: 2025 or 2026?

The list is maintained by the OWASP GenAI Security Project. The 2025 edition came out in November 2024, the 2026 edition in August 2026. What changed is the method. Until now the ranking rested purely on practitioner judgement. For 2026 the project team tested that vote, for the first time, against a corpus of 7,714 publicly recorded incidents. The vote carries three quarters of the weight, the incident data one quarter. That is why the order moved more than in previous years.

The identifiers are tied to the year. "LLM03" meant supply chain in 2025 and means Excessive Agency in 2026. In reports, tickets and requirements, always write the full identifier with the year, for example LLM03:2026.

Why LLM applications need their own Top 10

A language model makes no technical distinction between instructions and data. The system prompt, user input, retrieved documents and tool responses all end up in the same context window. There is no equivalent of the parameterised SQL query that cleanly separates commands from content. The project team sums up the stance of the 2026 list in one line: stop trying to build a model that cannot be fooled, and build the system so that nothing important breaks when it is.

The ten risks in detail

LLM01:2026 Prompt Injection

An input changes the model's behaviour in a way the developers did not intend. Directly, that happens through the chat box. Indirectly, it happens through content the model reads: a web page, a PDF, an email, a tool response or a memory entry. The 2026 edition explicitly adds instructions hidden in images and audio. In OWASP's assessment, no reliable control currently exists that prevents prompt injection outright.

Example: An assistant is asked to summarise a web page. Hidden in the page source is an instruction to insert a Markdown image whose URL carries the conversation so far as a parameter. The browser loads the image, and the conversation ends up with the attacker.

How to test: Plant crafted content wherever the model reads and watch whether it triggers tools or moves data outward. Test against an attacker who knows your defences, not just against known patterns. How to mitigate: keep privileges in application code rather than in the model, check every action deterministically at call time, strip invisible Unicode characters at every boundary, and require confirmation that shows the exact action for anything consequential. The deeper mechanics are covered in our piece on prompt injection and tool poisoning.

LLM02:2026 Sensitive Information Disclosure

The application exposes confidential, personal or business-critical data through a channel nobody authorised. That is not only the chat answer. OWASP also counts tool-call arguments, reasoning output, retrieved chunks, logs, telemetry and measurable properties such as response timing as disclosure channels. The cause can sit in training, in the runtime context, in the data pipeline or in outside observation.

Example: An internal knowledge assistant searches every document and only afterwards checks whether the person may see it. A cleverly phrased question pulls passages from salary spreadsheets into the summary, because the permission check on the finished result does not catch them.

How to test: Ask the same questions from test accounts with different permissions and compare. Review logs and traces for plaintext data. How to mitigate: enforce authorisation inside the retrieval query, not after it. Send the model only the fields the task needs. No secrets in the system prompt. Scrub logs before they reach monitoring tools.

LLM03:2026 Excessive Agency

The model is allowed to do more than the task requires, so it causes damage the moment it errs or is manipulated. OWASP names three root causes: excessive functionality, excessive permissions and excessive autonomy. The trigger matters less than you might think, a hallucination does as much harm as a prompt injection. This is the biggest climber of the 2026 edition, from sixth to third.

Example: An email assistant is meant to summarise incoming mail. The extension it uses, however, can also send and delete. A crafted email gets it to forward the mailbox to an outside address.

How to test: For every tool, list the functions and permissions it has and the ones the task actually needs. Check which identity it uses to reach downstream systems. How to mitigate: cut tools, functions and permissions to the minimum, replace open-ended tools such as "run a shell command" with narrowly scoped ones, execute actions in the context of the real user, and have a human approve high-impact steps.

LLM04:2026 Supply Chain

The application rests on third-party building blocks: pre-trained models, fine-tuning adapters, datasets, conversion services, inference servers and ordinary libraries. Any of them can be tampered with, outdated or swapped. New in 2026 is the case of a promoted model artefact that is not what it claims to be.

Example: A team downloads a model from a public hub under a name that closely resembles a well-known provider. The model behaves normally but carries built-in misbehaviour that only surfaces on specific inputs.

How to test: Is there an inventory of every model, adapter, dataset and package, with origin and version? Are checksums or signatures verified? Do the packages a coding assistant suggests actually exist? How to mitigate: keep a bill of materials for software and models, pin versions, verify signatures, assess suppliers, and patch and harden inference services like any other server. A signature proves origin and integrity, not safety.

LLM05:2026 Data and Model Poisoning

An attacker, or a sloppy process, manipulates data or model artefacts so the model learns harmful behaviour, bias or a backdoor. This affects pre-training, fine-tuning, embeddings and feedback loops. The treacherous part is that the model still appears to work.

Example: A support model is regularly retrained on customer reviews. Over several weeks an attacker feeds in targeted reviews until the model cites a false refund rule whenever a particular phrase appears.

How to test: Where do training and fine-tuning data come from, who can change them, and is every change versioned? Is the model probed for hidden triggers after every training run? How to mitigate: document data lineage, validate incoming data, put approval and volume limits on automated retraining, and version datasets so you can roll back to a clean state.

LLM06:2026 Unbounded Consumption

The application allows uncontrolled or expensive volumes of inference. The consequences are outages, unexpected costs or cloning of the model through mass querying. The defining trait is asymmetry: an attacker triggers expensive computation at almost no cost to themselves. Reasoning models, multimodal input and agents that turn one request into many tool calls make this worse.

Example: A public chatbot on a company website has no per-user limit. Overnight, a script sends long requests that force maximum response lengths. By morning the monthly budget with the model provider is gone ("denial of wallet").

How to test: Are there limits per user, key and time window, measured in tokens and cost rather than just requests? Does the application stop when a limit is hit, or does it only send an alert? How to mitigate: rate limiting and input size checks, hard spending caps that halt inference, limits on tool loops and queues, and graceful degradation under load.

LLM07:2026 Misinformation

The model produces wrong, incomplete or unsupported information that is credible enough for a person, a workflow or an agent to act on. The risk is not the wrong answer as such, but that it is trusted. In the incident data this entry appears far more often than the vote suggested.

Example: A coding assistant recommends a package that does not exist. An attacker has already registered exactly that name. Anyone who follows the suggestion installs attacker-controlled code.

How to test: Where does model output trigger a decision or an action without a cross-check? Are sources supplied and verified? How to mitigate: ground claims in authoritative sources, separate generation from execution and verify in between, check tool calls against preconditions, use mandatory fields in structured output to catch omissions, and label what is verified versus assumed.

LLM08:2026 Hidden Context Exposure

This entry used to be called System Prompt Leakage. It covers extracting or reconstructing context users are not meant to see: the system prompt, developer instructions, retrieved policy text and tool schemas. It becomes a security issue when that context holds secrets, policy logic or trust boundaries. OWASP advises assuming that hidden context can be discovered.

Example: A chatbot's system prompt contains an API key and the rule "discounts above 20 percent only for existing customers". A user gets the model to repeat its instructions and walks away with both the key and an idea for getting around the rule.

How to test: What would be exposed if the full context were published tomorrow? Does any security decision depend on an instruction staying secret? How to mitigate: no credentials or security-critical configuration in the context, enforce behavioural limits and permissions deterministically outside the model, and separate tasks that need different privileges.

LLM09:2026 Vector and Embedding Weaknesses

Weaknesses in the vector search that decides what the model gets to see in the first place. This affects RAG, agent memory and semantic caches. Unlike prompt injection, these attacks often need no malicious instruction at all. OWASP puts it this way: poisoning makes the system wrong, inversion makes it leak, jamming makes it silent, and missing access control makes it indiscriminate.

Example: A SaaS application puts every tenant's documents into one shared index and filters only after the search. One tenant never sees another tenant's documents but can infer from result counts and response times which topics the other tenant holds files on.

How to test: Is the tenant and permission boundary enforced inside the index query itself? Who can write content into the index, and is the origin of every entry recorded? How to mitigate: access control in the query and at chunk level, separate indexes for sensitive tenants, normalise content before embedding, store provenance per entry, and monitor unusual retrieval patterns.

LLM10:2026 Improper Output Handling

Model output is passed unchecked to other components: the browser, a database, a shell or a terminal. Because output can be steered through input, this turns into classic flaws such as cross-site scripting, SQL injection, SSRF or code execution. New in 2026 is the insecure code that assistants generate at scale.

Example: An application lets users query a database in plain language and runs the SQL the model generates directly. A phrasing that nudges the model into a DELETE is all it takes.

How to test: Follow every model output to its destination and check whether it is encoded, parameterised or validated there. Does the interface render Markdown images or links automatically? How to mitigate: treat the model like an untrusted user, encode for the target context, use parameterised queries and a strict Content Security Policy, strip control characters, and disable automatic loading of external content or restrict it to an allowlist.

LLM, Agentic, MCP: which list covers what?

OWASP draws the line itself. The LLM list applies while the model is a component inside your application. Once it becomes an actor, with tools, memory across sessions and consequences in downstream systems, the risk moves to the Agentic list. Many real incidents sit right on that line. The third list covers the infrastructure in between, the MCP server.

The lists overlap on purpose. According to OWASP, Excessive Agency (LLM03:2026) shows up in agentic systems as tool misuse (ASI02), identity and privilege abuse (ASI03) and cascading failures (ASI08). The LLM list explicitly hands supply-chain risks for MCP servers and tool registries over to ASI04. In practice: a chatbot without tools is well covered by the LLM list. An assistant that can send email, open tickets or run code also needs the Agentic list, and if it runs on or connects to MCP servers, the MCP list as well.

From test question to AI penetration test

The test questions above show where to look. They do not show whether a control holds. With LLM applications there is an extra catch: defences that look good against known attack patterns often fare much worse against an attacker who knows them and works around them. OWASP therefore explicitly recommends testing with adaptive attackers who have been told which defences are in place.

An AI penetration test for an LLM application combines both: the classic review of interfaces, permissions and data flows, and targeted testing of the model's boundaries, meaning crafted content in every input channel, privilege escalation through tools, data exfiltration through outputs and cost abuse. It runs within a scope agreed in writing, and every finding is backed by a reproducible proof of concept. Our approach is described on the AI and MCP security page. For the web application around the model, the SaaS penetration test is the right frame.

Frequently asked questions

Further reading

• AI red teaming explained
• OWASP Top 10 2025 explained
• LLM Pentesting Checklist: Testing an AI Application Before Launch
• Prompt Injection Testing: Test Plan, Test Cases and Scoring
• The OWASP Top 10 for Agentic Applications, Explained in Practice
• The OWASP MCP Top 10, Explained in Practice
• Prompt Injection and Tool Poisoning in MCP Servers
• Service: AI and MCP security testing

Sources

• OWASP GenAI Security Project: OWASP GenAI LLM Top 10 2026
• OWASP GenAI Security Project: announcement of the 2026 edition
• OWASP GenAI Security Project: LLM Top 10 2025 and translations
• OWASP GenAI Security Project: Top 10 for Agentic Applications 2026
• OWASP: MCP Top 10