What is the latest version of the OWASP Top 10 for LLM Applications?

The 2026 edition, published by the OWASP GenAI Security Project in 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. It replaces the 2025 list and is the first edition partly weighted by data from real incidents.

Can prompt injection be fully prevented?

No. The 2026 OWASP document states that no reliable prevention mechanism exists today, because language models do not separate instructions from data. Filters and classifiers lower the success rate but weaken against attackers who adapt to them. The workable approach is to design for failure: limit what the model can read and do, validate its output in code and require human approval for irreversible actions.

What is the difference between the OWASP LLM Top 10 and the Agentic Top 10?

The LLM Top 10 covers risks when a model is a component inside your application, such as a chatbot or a document search. The Top 10 for Agentic Applications, published in December 2025 with IDs ASI01 to ASI10, covers models that act: calling tools, keeping memory and triggering actions in other systems. OWASP recommends reading both once your model starts acting on its own.

How do I test a chatbot for prompt injection before launch?

Write a set of attack prompts covering direct overrides, requests for the system prompt and instructions hidden in documents, emails or web pages the bot reads. Give every injected instruction a harmless, visible marker, such as a code word or a call to a test email address. Run the set against staging on every release and track which attacks succeed. Treat a clean run as a minimum.

Does the OWASP LLM Top 10 replace the standard OWASP Top 10?

No. An LLM feature still sits inside a web application, so broken access control, injection and vulnerable components still apply. The LLM list adds the risks that come from the model itself: instructions hidden in text, data leaking through answers, agents with too much power and runaway costs. Review both lists for any product with an AI feature, starting with authentication and access control.

OWASP LLM Top 10: A Practical Guide for Product Teams

The OWASP Top 10 for LLM Applications lists the ten most serious security risks in products built on large language models. The current edition, published in August 2026, puts prompt injection first, sensitive information disclosure second and excessive agency third. For a product team, the useful work is to map each risk to a feature you ship, run one test per risk before launch and design so that a fooled model cannot do much harm.

I use three features throughout, because most products have at least one: a customer support chatbot, a RAG assistant that answers questions over company documents, and an agent with tools that can read email, update the CRM or query a database.

What changed in the 2026 OWASP LLM Top 10?

For the first time the ranking is partly driven by evidence. The project collected 7,714 real incidents from public vulnerability databases and an AI-harm database, classified the 6,639 with enough detail and gave that data a quarter of the weight. Practitioner voting carries the other three quarters.

Excessive Agency climbed to third, because both the vote and the incident data point at agentic deployments. Unbounded Consumption rose four places. Improper Output Handling fell from fifth to tenth. System Prompt Leakage became Hidden Context Exposure, which covers everything the model can see and the user cannot. Prompt Injection stays first. OWASP notes it would fall out of the top ten on raw incident counts and reads that as a defence effect. Teams fight injection hard, so fewer clean exploits reach public databases.

OWASP also published a separate Top 10 for Agentic Applications in December 2025, numbered ASI01 to ASI10 and starting with Agent Goal Hijack. The LLM list treats the model as a component. Once the model calls tools, keeps memory and sets off actions in other systems, OWASP says to use both lists together.

The OWASP LLM Top 10 at a glance

2026 risk	2025 ID	Feature most exposed	Main mitigation
LLM01 Prompt Injection	LLM01	All three	Limit what a fooled model can reach
LLM02 Sensitive Information Disclosure	LLM02	RAG assistant	Authorise before retrieval
LLM03 Excessive Agency	LLM06	Agent	Least-privilege tools, human approval
LLM04 Supply Chain	LLM03	Agent, RAG	Inventory, pin and vet components
LLM05 Data and Model Poisoning	LLM04	RAG, fine-tunes	Control who writes to your data
LLM06 Unbounded Consumption	LLM10	Chatbot, agent	Token quotas and hard spending caps
LLM07 Misinformation	LLM09	Chatbot	Ground answers, verify before acting
LLM08 Hidden Context Exposure	LLM07	Chatbot	No secrets or rules in the prompt
LLM09 Vector and Embedding Weaknesses	LLM08	RAG assistant	Tenant scope inside the index query
LLM10 Improper Output Handling	LLM05	All three	Treat output as untrusted input

What does each OWASP LLM risk look like in a real product?

LLM01: Prompt Injection

In the product: a user tells the support bot to ignore its instructions and list every discount code, or a document in the RAG index carries hidden text telling the model what to say. Test: run a library of direct and hidden-instruction attacks against staging on every release (see the next section). Mitigation: assume some attacks will land. Constrain what the model can reach and do, validate its output in code and confirm irreversible actions with a person.

LLM02: Sensitive Information Disclosure

In the product: the document assistant answers a junior employee’s question with figures from an HR spreadsheet, because the index ignored file permissions. Test: log in as a low-privilege test user and ask for things only HR, finance or another customer should see. Mitigation: OWASP’s advice is to authorise before retrieval, enforcing document and chunk permissions inside the index query. Keep credentials out of prompts and scrub logs.

LLM03: Excessive Agency

In the product: an email agent built to summarise can also send and delete, or a CRM tool uses one admin key for every user. Test: list every tool and permission the agent holds and write down the worst single call each one allows. Then try to make the agent call a tool the user never asked for. Mitigation: least privilege, covered below.

LLM04: Supply Chain

In the product: the team adds a fine-tuned model from a public hub, or an MCP server a coding assistant suggested. OWASP cites a malicious postmark-mcp package that blind-copied email to an attacker across an estimated 300 organisations. Test: produce an inventory of models, adapters, datasets, packages and MCP servers with source and version, and confirm every AI-suggested package exists and is the intended one. Mitigation: vet suppliers, pin versions and keep that inventory current.

LLM05: Data and Model Poisoning

In the product: the knowledge base accepts uploads from customers or partners, or you fine-tune on support tickets. Test: plant a false fact in a staging corpus, such as a 365-day refund window, and see whether the bot repeats it. Then list everyone who can write to that corpus. Mitigation: control and log who can add data, validate it on the way in and track where each dataset came from.

LLM06: Unbounded Consumption

In the product: a public chatbot with no login, or an agent that loops. OWASP points to the cost asymmetry, where a cheap request triggers expensive computation. Test: script a burst of long prompts from one account and start an agent task with no clear end state. Mitigation: token-based quotas, spending caps that halt inference instead of sending an alert, and step, time and cost limits per agent run.

LLM07: Misinformation

In the product: the support bot invents a refund policy, or an agent acts on a figure it made up. Test: build an evaluation set from your own documentation, including questions the documents do not answer, and count wrong answers and missing “I don’t know” replies. Mitigation:ground answers in cited sources and verify claims in code before any tool call acts on them.

LLM08: Hidden Context Exposure

In the product: the system prompt contains an API key, or a rule such as “never approve refunds over £100” that the app relies on. Test: try to extract the prompt by asking for it in another language, as JSON or as a poem. Then assume you succeeded and ask what an attacker gains. Mitigation:OWASP says to treat hidden context as discoverable. Keep secrets out of it and enforce rules in code.

LLM09: Vector and Embedding Weaknesses

In the product: a multi-tenant RAG feature keeps every customer in one index and filters results after retrieval. Test: as tenant A, search for terms that exist only in tenant B’s documents, and call the similarity-search endpoint without credentials. Mitigation: apply tenant scope inside the index query, authenticate vector endpoints and use separate indexes for high-sensitivity tenants.

LLM10: Improper Output Handling

In the product: the chat window renders model Markdown, so an injected image link sends conversation data to an attacker’s server, or model output flows into SQL or a shell. Test:get the model to return an HTML payload and a Markdown image pointing at a domain you control, and watch whether the UI renders or fetches either. Mitigation: treat output as untrusted user input, with context-aware encoding, parameterised queries and a strict Content Security Policy.

How do you test for indirect prompt injection?

Indirect injection arrives in content the model reads rather than in the user’s message: an uploaded file, an inbound email, a support ticket, a web page or a tool response. The user never sees the instruction. The OWASP document describes researchers at General Analysis dumping a production database through Cursor’s Supabase MCP server, which ran with the service-role key and so bypassed row-level security.

List every source the model reads that a stranger can write to.
Plant a harmless instruction in each one: visible text, white-on-white text in a document, an HTML comment, an email signature. Give it an observable effect, such as a code word in the answer or a call to a test address.
Run the normal user task, such as “summarise this email”, and check whether the marker appears.
Repeat with invisible Unicode characters, another language and Base64. OWASP recommends stripping zero-width and tag characters at every ingest point.
Rerun the set after every prompt, model or tool change.

Treat a clean run as a floor. OWASP cites research in which static attacks almost never beat recent defences, while attackers who adapted to them succeeded more than 90% of the time against most of the twelve tested.

Can any tool fully prevent prompt injection?

No. The 2026 OWASP document says plainly that “no reliable prevention mechanism exists today”, because a model sees instructions and data as one stream of tokens. Simon Willison made the same point in 2025. Guardrail classifiers are worth having as one layer. Budget for them as a speed bump, and put the real effort into limiting what a successful injection can do.

How do you give an AI agent least-privilege tools?

Start with Willison’s “lethal trifecta”: an agent with access to private data, exposure to untrusted content and a way to communicate externally can be turned against its user. Remove any one leg and the worst case shrinks. The 2026 OWASP entry adopts Meta’s “Rule of Two” as a floor. An agent that combines untrusted input, sensitive data and the power to change state or communicate externally should need human approval for every action.

When I review an agent, these are the rules I check first:

Give read-only tools unless writing is the feature. A mailbox summariser does not need send or delete.
Prefer narrow tools to open-ended ones. create_refund(order_id) with a cap enforced in code is far safer than run_sql or fetch_url.
Run tools as the signed-in user with scoped OAuth, not under a shared admin identity.
Enforce authorisation in code before each call. A system prompt is not an access control.
Show the exact action for approval before anything irreversible or external happens.
Cap steps, time and cost per run, and log every tool call.

If your AI feature sits on a vibe-coded app, the ordinary web risks come first. The vibe-coded app security checklist covers row-level security, leaked keys and auth checks, and why vibe-coded apps fail in production covers the rest of the gap between demo and production. To have both lists tested for you, the AI App Security Review includes OWASP LLM Top 10 coverage and prompt-injection tests.

OWASP Top 10 for LLM Applications: A Practical Guide for Product Teams