The OWASP LLM Top 10 names ten specific risks in LLM-powered apps: prompt injection, data leakage, excessive agency, and seven more, each with its own attack pattern. Testing against these risks means chaining a planted instruction through to real data exposure or confirming that rate limits cap costs, rather than just documenting that they should. Our AI and LLM security testing reference this framework, category by category.
Within days, you can build a new large language model (LLM) feature, ship it to production, and connect it to your databases and internal APIs. But this speed introduces new attack surfaces.
We’re sorry to tell you, but unfortunately, your standard security tools aren’t smart enough here. An automated scanner sends a static payload and waits for a specific error code. LLMs don't work like that. Their outputs change constantly.
The best way to secure your systems is to test them against the OWASP Top 10 for LLM Applications. You also need to look at the OWASP Top 10 for Agent Systems.
Reading these frameworks is easy. Testing against them in a live environment, less so.
Which OWASP List This Is (and Which One It Isn't)
OWASP maintains more than one Top 10 in the AI space, and two get mixed up often. This piece covers the OWASP Top 10 for LLM Applications, the 2026 edition, published 3 August 2026: LLM01:2026 through LLM10:2026.
It doesn't cover the separate OWASP Top 10 for Agentic Applications, announced in December 2025. That one handles risks specific to autonomous AI agents. If your app adds agent-style autonomy on top of an LLM, our AI & LLM pentesting model will also include that framework.
The order moved more than usual this year. For the first time, OWASP weighed practitioner opinion against a corpus of 7,714 real incidents, with 6,639 carrying enough detail to classify by category. The vote still carries most of the decision, 75%, with the incident record making up the rest.
The list is part of the OWASP GenAI Security Project, drawing on contributions from hundreds of AI security practitioners across the industry.
The OWASP LLM Top 10, One Risk at a Time
We've kept the standard's order below. If you're mapping testing activity to this list for an audit or a questionnaire, the order matters as much as the content.
LLM01:2026 Prompt Injection
What It Is
Crafted input that gets a model to treat instructions as legitimate when they shouldn't be. It takes several forms.
- Direct injection types straight into the chat.
- Indirect injection hides inside a document, webpage, or API response the model reads later.
- The 2026 edition folds in cross-modal attacks too, instructions hidden inside an image or an audio clip, not just text.
How We Test It
We try all of these. Direct attempts push the model to override its own system instructions in plain conversation. Indirect attempts plant an instruction inside a file the model is asked to summarise. Where the app accepts images or audio, we test whether the model reads instructions hidden in those too.
Then we check whether the model follows the planted line instead of treating it as content. Get this wrong, and an attacker doesn't need your login details. A well-worded sentence, or a doctored image, does the job instead.
LLM02:2026 Sensitive Information Disclosure
What It Is
The model reveals something it shouldn't. That covers more ground than it used to: memorised training data, another user's session details, internal system information. It now also covers what a model leaks through side channels, like response timing or token length, without ever printing the sensitive content directly.
How We Test It
Targeted queries try to pull memorised data directly from the model. In RAG (retrieval-augmented generation)-backed apps, we check whether one user can extract another user's documents through the retrieval layer.
We also check error messages, debug output, and observable behaviour, like response timing, for anything that leaks more than it should. A single successful extraction here can turn into a genuine data protection problem.
LLM03:2026 Excessive Agency
What It Is
The model holds more autonomy, permissions, or tool access than the task in front of it needs. This is the biggest mover in the 2026 list, climbing from sixth to third. Both the practitioner vote and the real incident record agree that agentic deployments are where the damage is landing.
How We Test It
Part of this is mechanical. We map every action the model's connected tools can take. Then we try to push it into taking an action outside its intended scope, like an assistant with email access sending a message nobody asked for.
The other part is judgement. This raises the question of whether the model needed that level of access in the first place.
In February 2026, MITRE's ATLAS team investigated OpenClaw and documented this pattern happening in the wild. One flaw let a webpage manipulate the agent's control flow into acting outside its intended scope. A separate bug in the same investigation, tracked as CVE-2026-25253, let researchers escape the agent's sandbox by getting it to load a malicious link.
This case, one of many, shows how real agent platforms are shipping with the excessive-agency problems this category is named for.
LLM04:2026 Supply Chain
What It Is
Risk inherited from the third-party models, datasets, plugins, and fine-tuning services the app depends on. The 2026 edition sharpens this to cover model authenticity specifically. A promoted or "verified" model artefact needs to be what it claims to be, not just untampered with after the fact.
How We Test It
We map every external component the app pulls in. That means the base model provider, any fine-tuned adapters, plugin marketplaces, and embedding models. Then we check whether any of them could be swapped or tampered with upstream, without anyone noticing downstream.
We also check whether the app verifies a model's identity before trusting it. A compromised dependency rarely stays contained. It travels wherever that component gets reused.
LLM05:2026 Data and Model Poisoning
What It Is
Training, fine-tuning, or embedding data that's been manipulated. The goal is usually to introduce bias, backdoors, or vulnerabilities into the model's behaviour. The 2026 edition folds fine-tuning subversion into this category, rather than treating it as a separate concern.
How We Test It
Where we can reach the fine-tuning or retrieval pipeline, we check who has write access to the data source. That might be a shared drive, a scraped webpage, or a user-submitted document.
Then we test whether that access could let someone inject content that skews future outputs in their favour. This risk moves slowly by nature. The damage tends to show up in outputs weeks after the poisoned data went in.
LLM06:2026 Unbounded Consumption
What It Is
Nothing stops a user, or an attacker, from sending requests that rack up cost or exhaust resources. This one rose four places in the 2026 list, largely because agentic setups make it worse. A single request can fan out into dozens of tool calls, and each one adds to the bill.
How We Test It
Unusually long inputs, rapid-fire requests, and prompts engineered to trigger long, expensive generations all go in. Where the app chains tool calls, we also test whether a single request can trigger a recursive or high-volume chain of tool calls.
We check whether the app enforces real rate limits and cost caps, not just a line in the documentation saying it should. Without real limits in place, one bad actor's session can turn into a large, unplanned bill by month's end.
LLM07:2026 Misinformation
What It Is
The model gives a confident, plausible, wrong answer and presents it as fact. This is the category that OWASP flags as the biggest surprise in the 2026 data. Practitioners ranked it low, but the real incident record ranked it near the top. It's the widest gap the project found between what people feared and what went wrong.
How We Test It
This one is closer to a judgement call than the others. We run domain-specific queries where the correct answer is verifiable. Then we assess whether the model hedges appropriately or states something false with more confidence than it's earned. We also check whether the app's interface signals that uncertainty to the reader or hides it.
LLM08:2026 Hidden Context Exposure
What It Is
The unauthorised extraction, inference, or reconstruction of instructions or context that were never meant to be user-facing. This is a rename and a broadening of what used to be System Prompt Leakage.
It's not just the system prompt now. It's any hidden material a model assembles into its context, including tool schemas, retrieved policy text, and developer instructions.
How We Test It
Extraction prompts try to surface that hidden context. That might mean asking the model to repeat, translate, or output its instructions as code. We then check what's sitting in there. An API key or internal business rule in hidden context is a real problem the moment it leaks. So is a set of refusal rules an attacker can now read and route around.
LLM09:2026 Vector and Embedding Weaknesses
What It Is
Risks specific to retrieval-augmented generation. The retrieval layer itself can be manipulated, or different users' data can bleed together inside a shared vector store.
How We Test It
In multi-tenant setups, we check whether one tenant's documents can surface in another tenant's search results. We also test whether a document, deliberately worded to score well against likely queries, can get planted in the retrieval pipeline and outrank legitimate content. In a shared, multi-tenant product, that's the gap between a minor bug and a real breach between two customers.
LLM10:2026 Improper Output Handling
What It Is
The app trusts the model's output too much. It passes that output downstream without checking it first, into a database query, a shell command, or rendered HTML. The 2026 edition also folds in a newer angle: insecure code that an AI coding assistant generates and a developer ships without review. This entry fell further than any other this year, from fifth to last. The list's weight shifted toward risks the incident data showed causing more damage.
How We Test It
We get the model to produce output containing script tags, SQL syntax, or shell commands. Then we check whether the receiving system runs or renders that output, instead of treating it as plain text.
Where the app is a coding assistant, we also check its suggested code. We ask whether it carries the same class of flaw the assistant would flag in a human's pull request. This is the category that turns an AI feature into an ordinary web vulnerability, with one extra step in front of it. That's why a web application penetration test usually sits alongside this kind of engagement.
Closing the Loop With Actionable Reporting
Finding the flaw is only the beginning. You need guidance to fix it. We provide a concise, focused report. Every finding includes enough technical detail to act on:
- A clear severity rating
- Model behaviour traces
- A working proof-of-concept where one applies.
We map every recommendation back to the OWASP LLM Top 10 and, where relevant, MITRE ATLAS tactics. Your engineering team can see exactly what category a finding falls under and why it matters.
Once your team ships a fix, we retest the attack path to confirm it holds, at no extra cost. This applies if the fix is completed within a year of the report.
What This Means for Compliance and Audit
Security questionnaires and procurement processes increasingly name this list directly, not "AI security" in general terms. A report that maps its findings back to LLM01 through LLM10 gives an auditor something they already recognise. It also doubles as documentation of your AI app security posture for whoever asks next quarter.
As of 2 August 2026, the European Commission's enforcement powers over general-purpose AI providers are active under the EU AI Act. That covers documentation requests, model evaluations, and fines of up to three per cent of global turnover. Article 50's transparency rules, covering things like chatbot disclosure, landed the same day.
Neither obligation is new. What changes is that regulators can now act on them.
Scope Your AI Use Correctly
Our AI and LLM security testing runs against this framework, category by category. It also brings the manual depth that these categories need. Misinformation and excessive agency both call for a person weighing the answer, not a rule checking a box.
Talk to Us About Your AI System
OWASP LLM Top 10 Questions We Often Hear
Is the OWASP LLM Top 10 the Same as the OWASP Top 10 for Web Applications?
No. They're separate lists, run by overlapping but distinct parts of the OWASP community. They cover almost entirely different risk categories. A web app pentest and an LLM pentest can both matter for the same product, but one list doesn't replace the other.
Most LLM-powered products still have a conventional web app or API sitting underneath the model. That layer needs its own testing regardless of which OWASP list you're mapping against.
Does AI app security testing cover our plugins?
Yes. Plugins and tools pose the biggest risk. We test your plugins to see if an attacker can manipulate the model into executing unauthorised actions on your internal network.
How Long Does It Take to Test Against All Ten Categories?
There's no fixed answer, since it depends on how much of the stack is in scope. A single hosted model with no fine-tuning has a small surface. Add a custom fine-tuned model, a vector store, and connected tools, and that surface grows fast. A scoping call settles the real shape of it, not a rate card.
Can We Ask for a Report That Only Covers Specific Categories?
Yes. Some clients already know where their biggest exposure sits, for example, prompt injection and excessive agency for an agent-style app. They want testing weighted there, not spread evenly across all ten. That's a scoping conversation, not a limitation of the framework.
Do We Need to Retest Against the Full List After Every Model Update?
Not necessarily the full list every time. A significant model swap, a new base model version, a newly added plugin, or a materially different system prompt is worth revisiting in full.
A minor prompt tweak or a small dataset refresh usually doesn't need a ground-up retest. Still, mention any changes to whoever tests your app, so they can judge what's worth rechecking.
Talk to Us About Securing Your AI App
Whether you need full coverage across all 10 categories or a targeted look at two or three, the starting point is the same conversation.
- What have you built?
- It’s connection points are?
- What is an auditor or a customer going to ask you to prove?
Find Out What Needs Testing
Want to Read More?
- Learn how manual testers validate authorisation flaws and business logic risks that automated tools miss in our OWASP Top 10 testing guide on real exploitability.
- Stay ahead of evolving security standards by reading our review of the 2026 OWASP LLM list to understand what has changed and what it means for your team.
- Understand the current state of automated threats by exploring the reality of AI hackers vs. human hackers in cybersecurity.
