OWASP LLM Top 10 2026 and the Agentic Top 10: Mapping Twenty Risks to Real Controls

OWASP LLM Top 10 2026 and the Agentic Top 10: Mapping Twenty Risks to Real Controls

In early August 2026, the OWASP GenAI Security Project published the 2026 edition of the Top 10 for LLM Applications. It landed eight months after the Top 10 for Agentic Applications, now at v2.01. Two lists, twenty risks, and a question that has moved from conference panels into procurement questionnaires: which of these does your platform actually enforce. If you want the fundamentals of how agentic risk differs from model risk, the agent governance stack covers that ground. This post goes one level deeper: what changed in the OWASP LLM Top 10 2026, why two lists now exist instead of one, and how each of the twenty risks maps to a control that either sits in the path or does not.

What changed in the OWASP LLM Top 10 2026?

Prompt Injection held first. Sensitive Information Disclosure held second. Read the headline and you would conclude nothing moved.

Eight of the ten entries moved.

The reason sits in the method. This edition weighted the ranking 75 percent on community vote and 25 percent on catalogued incident data, the first time OWASP has checked expert consensus against a corpus of what has actually gone wrong. Of the incidents reviewed, 6,639 carried enough detail to classify. That single change reshuffled most of the list and produced one instructive anomaly: Prompt Injection stayed at number one despite a thin incident record, because organizations that block injection successfully never file an incident report. Misinformation moved the opposite way, climbing on evidence that voters had not weighted heavily.

The movements that matter for control design:

• Excessive Agency rose from sixth to third, the largest promotion on the list, as production incidents clustered around systems where model output triggers action.
• Unbounded Consumption climbed from tenth to sixth, reframed around cost asymmetry rather than plain denial of service.
• Misinformation climbed from ninth to seventh on incident evidence rather than expert opinion.
• System Prompt Leakage was renamed Hidden Context Exposure and broadened from a prompt-field problem to a whole-context problem, covering retrieved policy text, tool schemas, and workflow rules.
• Improper Output Handling fell from fifth to tenth, not because the risk shrank but because it is well understood and fixable with encoding and validation practice teams already have.

No new categories were added. Prompt Injection absorbed cross-modal attacks hidden in images and audio, and Data and Model Poisoning absorbed fine-tuning subversion, so the list consolidated rather than expanded.

The framing shift is the one worth reading twice. The project leads open by telling teams to stop trying to build a model that cannot be fooled, and to build the system around it so that when the model is fooled, nothing important breaks. After two years of the industry optimizing the model, the list now says optimize the containment. That is not a new position for anyone already governing the context layer. It is a standards body arriving at it.

What is the OWASP Top 10 for Agentic Applications?

The OWASP Top 10 for Agentic Applications, ASI01 through ASI10, is the first industry-standard taxonomy of security risks specific to AI agents. It was published on 9 December 2025 with input from more than 100 security experts, and updated to v2.01 on 1 June 2026.

Where the LLM list covers what a request or response can do on its way through an application, the agentic list covers what happens once a system stops generating text and starts acting: planning, tool use, memory, identity, and coordination with other agents. It is deliberately incident-driven, with nearly every entry anchored to a public 2025 or 2026 event, which makes it usable as an audit checklist rather than an awareness poster.

Two principles run underneath it. Least agency limits not just what an agent can access but how much it can do without checking back. Strong observability means seeing what an agent did, why, and under whose identity. Both are architectural commitments rather than product features, which is why the list reads as a design review and not a scanner output.

Why the OWASP LLM Top 10 alone no longer covers agentic AI?

OWASP draws the boundary itself. The 2026 LLM edition orders risks for the model as a component inside an application, and states that the moment the model becomes an actor, with tools it can call and memory it carries between sessions, the risk moves to the Agentic Top 10. The authors say directly that neither list covers the full picture alone.

Three properties account for the split:

• Autonomy: the agent picks its own next step, so one poisoned input redirects an entire multi-step plan rather than producing a single bad answer.
• Tool access: the agent holds credentials and calls real APIs, so a reasoning failure stops being a wrong answer and becomes a write to a production system.
• Persistence: the agent carries memory across sessions, so an instruction planted today can trigger next week, long after the session that introduced it has closed.

Most enterprise AI sits on both sides of that line. A RAG chatbot is an LLM application. The same chatbot with an MCP connection to your ticketing system is an agentic one, and the
change is a configuration decision rather than a rebuild.

So do not inventory by list. Inventory by capability, ask whether each component plans, acts, or remembers, then apply whichever list governs what you found. The 2026 release offers a fast triage test alongside it, borrowing Simon Willison's lethal trifecta: an agent is exposed when it can access private data, ingest untrusted content, and communicate externally at the same time.

Mapping the OWASP LLM Top 10 2026 to enforcement controls

Data-first, in-path enforcement applies before data reaches the model and before a response reaches a user. Eight of the ten are enforced natively at DAXA's governance layer, in 2026 order:

• LLM01 Prompt Injection: a fine-tuned classifier swarm detects direct and indirect injection, and Safe Agent inspects MCP tool responses before the model acts on them.
• LLM02 Sensitive Information Disclosure: Safe Infer redacts PII and custom entities before data reaches the model, with identity-aware access enforced through the customer's IdP.
• LLM03 Excessive Agency: least-privilege tool policies, per-agent scoping, and human approval for irreversible actions, addressing all three of OWASP's named root causes: excessive functionality, excessive permissions, and excessive autonomy.
• LLM04 Supply Chain: Trivy scans MCP and tool images, and Guardian Agent tracks tool-definition changes after approval. Covered collaboratively.
• LLM05 Data and Model Poisoning: Safe RAG classifies and controls what is ingested into context at query time. Covered collaboratively.
• LLM06 Unbounded Consumption: token, rate, and cost governance per agent and user, sized to the fan-out problem rather than request rate alone, containing denial of wallet and model DoS.
• LLM07 Misinformation: output-safety policies and grounding controls flag and block ungrounded responses before they reach a user or a downstream agent.
• LLM08 Hidden Context Exposure: prompts and responses inspected in-path, with attempts to extract system instructions, tool schemas, or policy text blocked.
• LLM09 Vector and Embedding Weaknesses: Safe RAG enforces identity-aware retrieval at query time, applying access control before similarity search rather than after it, which is where cross-tenant leakage happens.
• LLM10 Improper Output Handling: unsafe or executable output inspected and blocked in-path, before it reaches users, terminals, IDE panes, or downstream systems.

Note where Excessive Agency now sits. It is the entry that climbed furthest, and it is the entry no filter can address. Filtering does not bound agency. A policy checkpoint at the action boundary does.

One addition under Supply Chain is worth calling out because it changes where the risk enters. The 2026 edition names slopsquatting, where coding assistants hallucinate plausible package names at scale, attackers register those names in advance, and the AI-suggested dependency resolves to malicious code. It arrives through coding assistants rather than through your build pipeline, which is exactly why existing dependency controls do not see it.

Mapping the OWASP Agentic Top 10 to enforcement controls

Eight of the ten are enforced natively. ASI05 and ASI07 are covered in collaboration with the infrastructure layer. Names below follow v2.01:

• ASI01 Agent Goal Hijack: all prompts and responses classified, and MCP tool responses inspected before the agent acts on them.
• ASI02 Tool Misuse and Exploitation: MCP tool policies block write and delete actions, scope by agent and user, and require human approval on destructive calls.
• ASI03 Identity and Privilege Abuse: per-agent identity, blast-radius visualization, and identity-aware data access through the customer's IdP, replacing shared service accounts.
• ASI04 Agentic Supply Chain Vulnerabilities: Guardian Agent severs connections on post-approval tool-definition changes, the exact failure mode behind MCP rug pulls, with local MCP images scanned before use.
• ASI05 Unexpected Code Execution / RCE: prompts that elicit code execution and unsafe outputs are flagged in-path. Covered collaboratively.
• ASI06 Memory and Context Poisoning: ingested context classified and provenance-checked before it persists, so an injection does not survive into a later session.
• ASI07 Insecure Inter-Agent Communication: inter-agent MCP calls logged and inspected. Covered collaboratively.
• ASI08 Cascading Failures: in-path throttling, MCP deactivation, or SOAR break-glass on a Guardian Agent signal, containing propagation before it spreads across a pipeline.
• ASI09 Human-Agent Trust Exploitation: output-safety policies enforced against toxic, biased, or unsafe content before it reaches the human who would approve it.
• ASI10 Rogue Agents: behavioral monitoring outside the model, with deviations triggering SIEM alerts and SOAR containment at agent speed.

Read the list as chains rather than as ten separate items. ASI01 and ASI06 are entry points. ASI02 and ASI05 are where an attack cashes out. Most real incidents combine one of each, which means closing only the entry point or only the impact leaves the chain alive.

The four risks no governance layer covers alone

Sixteen of the twenty are enforced natively. Four sit across a boundary a governance layer does not cross by design: what happens inside a model's training pipeline, and what happens below the application layer in runtime and network infrastructure. Naming them is the point, because collaborative is not a euphemism for unaddressed.

On Supply Chain, spanning LLM04 and ASI04, DAXA covers scanning and monitoring of the tool and MCP layer, including post-approval tool-definition changes. The collaborating control is MLOps provenance: foundation-model and dataset lineage, a discipline the customer already runs.

On Data and Model Poisoning, DAXA covers what enters an agent's live context at query time. The collaborating control is model governance, meaning training-time integrity of models and datasets. This is the one risk on either list that cannot be patched after the fact, since remediation means revalidating data, retraining, or replacing the model. That is precisely why the boundary has to be stated rather than blurred.

On ASI05, DAXA covers the prompt and output pattern that leads to execution, flagged and blocked before the model produces it. The collaborating control is runtime sandboxing: the egress-restricted container or VM that contains execution itself. On ASI07, DAXA covers what agents say to each other, logged and inspected in-path, while mutual TLS covers encryption and authentication of the channel between them.

In each case the risk is covered today, by a governance layer working alongside a control the customer already owns, not by waiting on a roadmap item. The distinction that matters to a security architect is not whether a vendor claims all twenty. It is whether the vendor can say where their enforcement stops and name what picks it up.

What to ask your AI security vendor about OWASP coverage

The lists have become procurement instruments, which means a coverage claim now needs to survive a follow-up question. Five that separate a real answer from a marketing one:

1. Which risks do you enforce in-path, and which do you only detect and report? A dashboard that surfaces a violation after the tool call has completed is an audit record, not a control.
2. Where is the evidence for each claim: which console view, which audit log entry, viewable today rather than described in a datasheet.
3. Which risks do you not cover alone, and what control covers the remainder? A vendor that claims twenty of twenty with no boundary anywhere is describing marketing scope, not architecture.
4. Are you mapped to the 2026 LLM edition or the 2025 one? Eight entries moved, and Excessive Agency at third rather than sixth changes what the control has to do.
5. Do you cover the Agentic list at all, or the LLM list relabelled? Ten of ten on one list is half an answer when your deployment plans, acts, and remembers.

Where OWASP AI security frameworks are heading?

Two shifts will shape how these lists get used next.

Coverage claims will get audited. Once a framework enters vendor risk reviews, "we cover the OWASP Top 10" stops being a marketing line and becomes a statement someone checks against an audit trail. Vendors who cannot show the enforcement point will be asked to, and the asking is already happening in questionnaires rather than in security reviews after the fact.

The lists will keep splitting. The LLM list has revised twice, the agentic list once since December 2025, and the boundary between them is where new categories will appear. Anyone mapping controls to a static snapshot will be mapping to a stale document within a year, which makes version-pinning your own coverage claims part of the discipline rather than an afterthought.

If there is a through-line, it is the one OWASP itself now leads with: assume the model will be fooled, and build so that when it is, nothing important breaks. Twenty risks, sixteen enforced natively and four with a named collaborating control, is a specific and checkable position. We would rather keep it current than round a number up in the meantime.

See how Safe Agent governs the action boundary, or how the same controls apply to homegrown agents in production.

Frequently asked questions

1. What is the OWASP Top 10 for LLM Applications 2026?

It is the reference list of the most critical security risks in applications built on large language models, published by the OWASP GenAI Security Project in early August 2026. It is the third edition since 2023, and the first to weight rankings partly on catalogued incident data rather than expert vote alone.

2. What changed in the OWASP LLM Top 10 2026?

Eight of the ten entries moved. Prompt Injection and Sensitive Information Disclosure held first and second. Excessive Agency rose from sixth to third, Unbounded Consumption from tenth to sixth, and Misinformation from ninth to seventh. System Prompt Leakage was renamed Hidden Context Exposure, and Improper Output Handling fell from fifth to tenth. No new categories were added.

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

The LLM list covers risk when the model is a component inside an application. The Agentic list covers risk when the model becomes an actor with tools it can call, memory it carries between sessions, and consequences downstream. OWASP states the two are complementary and that neither covers the full picture alone.

4. Do I need both OWASP lists?

If any part of your deployment plans, calls tools, or holds memory across sessions, yes. Inventory by capability rather than by list, then apply whichever list governs each component.

5. What is the lethal trifecta in the OWASP 2026 release?

It is a pre-deployment check: an agent is exposed when it can access private data, ingest untrusted content, and communicate externally at the same time. Removing any one of the three closes the high-impact exploitation path.

6. Which OWASP risks can a governance layer enforce directly?

Sixteen of the twenty across both lists, where enforcement sits in the path between the model and the data or tool. The remaining four require a named adjacent control: MLOps provenance, model governance, runtime sandboxing, and mutual TLS.