The OWASP LLM Top 10 for 2026.

Every previous edition was built on judgment: hundreds of practitioners voting on what matters most. That vote is still three-quarters of the weight. What is new is the other quarter.

The project pulled 7,714 real incidents from public vulnerability databases and an AI-harm database, and classified the 6,639 that carried enough detail to sort. Then they asked one question: does what practitioners fear match what the incident record shows?

The answer was no, and the disagreements are the most useful part of the document.

Prompt injection is the clearest case. Practitioners rank it number one. Rank the categories by the raw incident record and it falls out of the top 10 entirely. OWASP reads that gap as a defense effect: teams fight injection hard, so fewer clean exploits reach a public database. It stays at number one because the surface, a model reading untrusted input, is everywhere.

Misinformation runs the other way. Voters put it near the bottom; the incident record put it near the top. That is the gap in the direction that actually hurts, and it is worth sitting with. When a confident, fluent answer drives a decision or a tool call, a wrong answer becomes a wrong action.

The moves worth knowing:

1. Excessive Agency climbed from 6th to 3rd. OWASP calls this the most consequential move on the list, and the one place where the vote and the incident record simply agree: agentic deployments are where the damage is landing.
2. Unbounded Consumption rose four places, from 10th to 6th. Resource and cost exhaustion is now a mainstream concern, not a footnote.
3. Improper Output Handling fell the furthest, from 5th to 10th.
4. System Prompt Leakage was renamed Hidden Context Exposure, a broader framing of the same failure: trusting information that should have stayed out of reach.
5. Prompt Injection and Sensitive Information Disclosure held 1st and 2nd.

Several entries also absorbed newer risks rather than spawning new categories. Prompt Injection now covers cross-modal attacks that hide instructions in an image or audio track. Supply Chain covers the case where a promoted model artifact is not what it claims to be. Improper Output Handling now spans insecure code that assistants generate at scale.

The clearest single page in the report is the bullseye. Attacks enter at the perimeter, pass through amplifying machinery, and land as impact in the middle.

1. Entry vectors: Prompt Injection, Supply Chain, Data and Model Poisoning
2. Amplifiers: Hidden Context Exposure, Vector and Embedding Weaknesses, plus Excessive Agency and Improper Output Handling
3. Impacts: Sensitive Information Disclosure, Unbounded Consumption, Misinformation

"Attack flows inward. Defense pushes outward." If you only remember one diagram from the 2026 list, make it this one, because it tells you where controls belong. You cannot close the entry vectors, a model reading untrusted input is the whole point of the product. You can shrink the amplifiers and cap the impacts.

OWASP is unusually blunt about prompt injection: LLMs make no architectural distinction between instructions and data, so no reliable prevention mechanism exists today. Their conclusion, which matches NIST and the UK NCSC:

They point at Simon Willison's "lethal trifecta" as a pre-deployment check. An AI agent that can simultaneously access private data, ingest untrusted content, and communicate externally has the conditions for high-impact exploitation. Remove any one leg and you remove them.

That is a design review question, not a scanner finding. It is also the most useful thing on this list for a team shipping next quarter.

Worth studying if your threat model currently stops at "we use a hosted model." It does not stop there: fine-tuning data, LoRA adapters, container images, package repos, the dev environment, and on-device deployment are all in scope.

A Top 10 is a risk register. It tells you what can go wrong, not how to run a system that survives it. The difference matters, because most of these risks have no clean prevention, you are buying containment and recovery, not immunity. That is a resilience programme, and resilience is an operating habit rather than an audit finding.

Here is the translation, in the order we would do it.

For every AI feature, write down three things: can it reach private data, can it ingest untrusted content, can it communicate externally. Any feature with all three has the lethal trifecta and is your priority, wherever it sits on the Top 10. An afternoon of this reorders a backlog more honestly than a quarter of scanning, because it ranks by consequence rather than by finding count.

Then ask the recovery question for each one: if this acted on an attacker's instruction at 3am on a Sunday, what would we have to undo, and could we? That question, not the risk ranking, is what tells you where to spend.

Excessive Agency is the biggest mover on the 2026 list, and the report gives a genuinely useful diagnostic. Every case reduces to one of three:

1. Excessive functionality, the tool can do more than the job needs. A read-only summarizer wired to a mail tool that can also send.
2. Excessive permissions, the credential can do more than the tool needs. A reader connecting with an identity that also holds UPDATE and DELETE, or a per-user feature running as a shared privileged account.
3. Excessive autonomy, the system takes a high-impact action without independent verification.

These are separable and separately fixable, which makes them a good review checklist for a design doc. The report's own example is a hijacked email assistant: the fix is not a better prompt, it is a read-only OAuth scope and a tool that has no send function to abuse.

This is the control that does the most work, and the report describes it directly as a graduated enforcement policy: audit, warn, block, escalate. Low-consequence and easily reversible actions auto-approve. High-consequence and irreversible ones route to a human.

OWASP's example is worth stealing verbatim: a customer service bot can auto-process a refund as store credit, because that is recoverable, while an external payout routes to human approval. Same intent, different reversibility, different gate.

In practice that means classifying every action your system can take before it runs:

1. Read-only or draft-only, runs freely, no ceremony.
2. Reversible side effect, runs, but records who and why, so it can be found and undone.
3. Irreversible, stops. Most of it waits for a named person: deploys, payments, sending to a customer. A pinned set has no release path at all and only a signed-in person can run it.

The name matters. "Approved by the system" is not a control, and "approved by whoever triggered it" is not separation of duties. This is the step that turns a successful injection into a contained incident, which is the whole posture of the 2026 list.

The report is explicit that system-prompt instructions are a partial control: an attacker who infers the prompt can bypass it. Allow and deny lists for models and tools have to be enforced where the call is made and checked at the moment of use, not asserted in a policy document. Prefer narrow tools with strict input schemas over open-ended ones, a file-writing tool rather than "run a shell command."

Unbounded Consumption rose four places, and the mitigation is more interesting than a rate limit. The report suggests thresholds that halt, rate-limit, or escalate for human review when exceeded, and notes that context-aware thresholds can be based on the cumulative value of a tool's input parameter, not just the number of calls. Ten refunds of $5 and ten of $5,000 are not the same event. Budget by consequence, and make the breaker escalate rather than silently fail.

Every risk on this list produces the same question after an incident: what ran, which model, what did it touch, who approved it. If that record is written while the work happens, the question is a lookup. If it has to be reconstructed from logs and memory, you are doing incident response and archaeology at the same time, usually under a disclosure clock.

This is also the difference between compliance and resilience. A control you can evidence on demand is a control you can actually rely on mid-incident; one you can only describe in a policy is a control you will discover was broken.

None of this holds still. Models change, tools get added, someone widens a scope to unblock a release. A few habits keep it honest:

1. Re-run the trifecta map whenever a feature gains a tool or a credential. Adding one tool can move a feature from contained to critical.
2. Review what the approval gates actually stopped last month. Gates that never fire are either perfectly placed or quietly bypassed, and it is worth knowing which.
3. Rehearse one containment: revoke a compromised tool credential, or roll back an agent-made change, and time it.
4. Watch the boundary. OWASP is clear that this list owns the risk when the model is a component. The moment it becomes an actor, tools it can call, memory that persists across sessions, consequences downstream, you also need the OWASP Agentic Top 10. Neither list covers that ground alone.

The 2026 edition quietly stops promising that you can prevent your way out of this. It asks a different question: when the model is fooled, what happens next?

That is an architecture question, and it has architecture answers, least privilege, approved lists enforced at the call site, reversibility gates on anything you cannot take back, and a record that writes itself while the work happens. None of them require the model to behave.

• Read the full report at OWASP

Source: [OWASP Top 10 for LLM Applications 2026, v1.0](https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/), OWASP GenAI Security Project, released August 4th 2026. Project lead Steve Wilson, co-lead Rock Lambros. Figures 1, 2 and 3 are reproduced from the report, cropped from the original pages with no other changes, and are used under [CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/). Quoted passages are the report's own words. TEKIMAX is not affiliated with OWASP and this article is not endorsed by the project.