OWASP Agentic AI vs OWASP LLM Top 10 Compared

OWASP now maintains two separate security frameworks for AI systems: the Top 10 for LLM Applications and the Top 10 for Agentic Applications. They are not competing standards and not a case of one superseding the other. Each one secures a different layer of the same system, because language models stopped being the thing that acts. The rest of this piece is about where one list's authority ends and the other's begins, and why getting that boundary wrong is the single most expensive mistake a security team can make right now.

Why OWASP publishes two separate AI security lists

For years, one list was enough, because the worst a language model could do was produce a bad sentence. It could leak a secret, hallucinate a fact, or get tricked into saying something it shouldn't, but the damage stopped at the output. OWASP's GenAI Security Project broke that assumption on 9 December 2025, when it released the Top 10 for Agentic Applications as a standalone framework rather than folding new entries into the existing LLM list. That decision was architectural. The threat model for agentic systems had changed in kind, not just in degree, because these systems plan, call tools, hold memory across sessions, coordinate with other agents, and act using real credentials inside live workflows. The risk no longer lives in what the model says. It lives in what the system does, and no amount of expanding a list built for a terminal output can account for a model that keeps acting after it finishes talking.

The Modulos governance guide states the operational consequence: most agent systems are also LLM applications. They inherit every LLM-side risk on top of their own. An enterprise agent program ends up applying both lists in layers, with the LLM list supplying the vocabulary for language-model risk and the Agentic list supplying the vocabulary for execution risk. Two lists exist because two distinct failure surfaces exist, and if you pretend otherwise, one of them goes unmonitored.

The scope of the LLM Top 10

The LLM Top 10 secures the model, but only as a component that sits inside a larger application. It covers how the model can be manipulated through input, how it leaks data it shouldn't have access to, how it produces harmful or false output, and how the surrounding infrastructure, from vector stores to inference endpoints, can be compromised. The 2026 edition runs LLM01 through LLM10, and its scope now explicitly cross-references NIST, CWE, MITRE ATLAS, and the companion Agentic list. OWASP wrote that cross-referencing in deliberately: it is the project itself acknowledging these frameworks are meant to be read together.

Three moves in the 2026 edition show where this list's authority stops [12][1][2][4][5][11][3][6]. Excessive Agency jumped from sixth place to third, and that is OWASP conceding that a model with more authority than it needs is a model-layer problem even before any agentic architecture enters the picture [12][1][2][4][5][11][3][6]. Unbounded Consumption, formerly called Model Denial of Service, now widened to include cost-based attacks, where an attacker burns through an organization's inference budget without ever crashing the service. And the framing of the whole document shifted from "build a model that cannot be fooled" to "build the system around it so that when the model is fooled, nothing important breaks." That containment philosophy reaches conceptually toward agentic execution without actually covering it.

The boundary is structural: the LLM list assumes the model is the terminal actor. Its output is a response, not the first link in a chain of downstream tool calls. Once a model becomes an actor with goals, credentials, and the ability to take multi-step action, you still need the LLM list's controls, but they stop being enough on their own.

Agentic Top 10 additions beyond the LLM list

The Agentic Top 10, identifiers ASI01 through ASI10, was published on 9 December 2025 by the OWASP GenAI Security Project with more than 100 industry experts, researchers, and practitioners contributing to it. It addresses threats that exist only because a model now holds tools, memory, identity, and the ability to coordinate with other agents.

Three of its ten entries have no counterpart in a traditional LLM application, because the threat class they describe can't exist with just one model in the loop. ASI07, Insecure Inter-Agent Communication, covers messages between agents that can be spoofed, replayed, or sent without authentication. ASI08, Cascading Failures, happens when an error or compromise in one agent propagates automatically through a multi-agent pipeline, so the damage amplifies with no further action from an attacker. ASI10, Rogue Agents, covers an agent operating outside its intended policy through design failure, behavioral drift, or outright compromise, a deviation that any control inspecting only model outputs would never catch.

The remaining seven entries are not restatements of LLM risks. They are amplifications of them. ASI01, Agent Goal Hijack, extends LLM01's prompt injection through the same injection channel, but the consequence is no longer a bad sentence; it's a redirected autonomous plan. OWASP maps the EchoLeak vulnerability class directly to ASI01 as its documented real-world instance. ASI03, Identity and Privilege Abuse, extends LLM03's Excessive Agency: an agent that borrows a user's session or reuses an admin token isn't just exceeding model authority, it's impersonating a human identity at machine speed. ASI04, Agentic Supply Chain Vulnerabilities, extends LLM04 by adding runtime composition: agents load tools, plugins, and even other models dynamically during execution, so a poisoned dependency can enter the system after deployment. ASI06, Memory and Context Poisoning, has no clean LLM analogue at all: persistent agent memory means one successful poisoning event can reshape behavior across every future session, long after the original interaction ended.

The principle tying all ten entries together is Least Agency: autonomy is a feature an agent should earn through demonstrated need, never a default setting. If you give an agent more authority than its narrowest safe task requires, every vulnerability it carries gets amplified by that excess authority. This maps directly onto runtime enforcement architecture. Platforms like Oso that apply fine-grained access controls at the agentic layer can operationalize Least Agency by restricting exactly which tools, credentials, and actions each agent is permitted to invoke, so that even a hijacked or compromised agent can't exceed its narrowest safe scope.

How the two lists interact at the seam between LLM risks and agentic consequences

These two lists are not parallel tracks running independently; they are layers stacked on top of each other, and the same vulnerability can show up on both lists at once because the LLM layer never stops existing inside an agentic system. Adding agents doesn't retire LLM risk, it amplifies it.

The amplification runs through blast radius. A prompt injection against a read-only chatbot produces just one bad output. The identical injection against an agent holding tools, credentials, and the ability to plan autonomously produces actions, and the only thing separating those two outcomes is everything the agent happens to be permitted to do. Because agentic systems act with real credentials in live workflows rather than simply returning text, the threat model shifts from "what can a model output" to "what can a model do," and that shift is what separates the two control strategies: LLM security focuses on containing what leaves the model, while agentic security requires real-time visibility and enforcement over what the agent is actually permitted to execute, including which external systems and identities it can reach.

The 2026 LLM list acknowledges this seam directly: every LLM risk now maps to one or more Agentic counterparts through a multi-framework appendix, and the promotion of Excessive Agency to third place reflects a methodology that, for the first time, weighted expert-practitioner consensus far more heavily than raw incident data across an analysis of 6,639 documented real-world incidents, the classifiable subset of a larger incident corpus, using OWASP's own 2026 methodology.

A financial cascade scenario mapped to ASI08 makes the seam concrete. A Market Analysis agent gets poisoned, an LLM-layer event falling under ASI01 and LLM01, into inflating its risk limits. Downstream, the Position and Execution agents then trade larger positions automatically, based on that corrupted data. Compliance tooling waves the whole sequence through as "valid," because every individual model call still looks legitimate in isolation. The LLM list catches the poisoning event. The Agentic list catches the propagation. Neither one alone catches the incident.

Where practitioners most commonly misapply the two lists

Most practitioners make the same mistake: they treat the LLM list as sufficient coverage for any system that happens to use a language model, even when that model has been handed tools or autonomous authority. The 2026 LLM list corrects for this itself by cross-referencing the Agentic list explicitly, which is as close as a standards body gets to flagging its own readers' most frequent error.

A second failure runs in the other direction: applying only the LLM list to a system that is, in fact, agentic. Traditional SAST and SCA tooling cannot inspect an agent's prompts, tool calls, memory reads, or inter-agent traffic, because the agentic attack surface lives entirely in a layer those tools were never built to reach. A third failure applies only the Agentic list and assumes LLM risk has been handled by omission. ASI01's Goal Hijack is rooted in prompt injection, so if LLM-layer controls don't govern what reaches the reasoning loop first, agentic controls on what the agent is allowed to do end up defending a structure that has no floor underneath it.

A fourth, subtler failure treats these two lists together as a complete inventory of AI risk. The OWASP GenAI Security Project now runs a three-framework ecosystem: the LLM Top 10, the Agentic Top 10, and the Agent Control Standard. The separately maintained OWASP MCP Top 10 covers the protocol connecting agents to external systems, and it addresses supply chain risk at the protocol level, which neither the LLM list nor the Agentic list fully reaches on its own. Agent inventory is one practical gap nobody's framework fully closes, and it sits under all four of these misapplications. Without a standardized, machine-readable record of which tools, models, and data sources each agent can reach, an organization can't answer basic questions about its own agent population, let alone apply any list's controls against it.

How to apply both lists together without duplicating work

The practical architecture is a two-layer control model. Apply the LLM list at the model-component level, governing what the model receives, what it produces, and what it's permitted to say. Apply the Agentic list at the execution level, governing what the agent plans, which tools it calls, how it coordinates with other agents, and whether its behavior stays inside declared policy. The Modulos governance guide offers a usable decision rule: reach for the LLM list when the system is a chatbot or a RAG pipeline with no tool access and no multi-agent coordination, then layer the Agentic list on top the moment the system starts planning and acting. Both lists apply at once from that point forward, because LLM risk does not disappear just because you added agents.

The Agentic list's Least Agency principle translates into three concrete execution-layer controls: hard caps on autonomous loops paired with plan-validation checkpoints before any irreversible action, approval gates on high-impact tool calls such as file writes, external API calls, and credential use, and runtime monitoring that compares an agent's actual behavior against its declared policy rather than just screening individual outputs against a content filter. An organization that doesn't know which agents are running, what tools each one holds, and what permissions each one carries has no population to enforce policy against, which makes agent inventory an upstream prerequisite for these controls to mean much.

Oso is built specifically to close that gap. It gives organizations the ability to discover every agent running inside the company, monitor approved AI traffic in real time, detect anomalous behavior and policy violations as they occur, enforce rules governing what agents can and cannot do, and produce full audit logs of every action taken. That combination covers both the execution-layer controls the Agentic list calls for and the visibility problem that neither OWASP list closes on its own. The OWASP Agent Control Standard, published September 1 to 2, 2026, states the underlying requirement bluntly: enterprises cannot rely on black-box agents operating across cloud, SaaS, on-premises, and endpoint environments, and agents have to be inspectable, traceable, and instrumentable. Oso's runtime monitoring and audit-log architecture is built to satisfy those exact properties. Other tooling, red-teaming exercises, static analysis, broader governance frameworks, has a role to play alongside this, but none of it substitutes for knowing what your agents are and watching what they do in real time.

Which list to reach for first

One question determines where to start: does the system only produce outputs, or does it take actions? A chatbot, a RAG pipeline, or a summarization tool with no tool access produces outputs only, and the LLM Top 10 is the correct starting and ending point, since the Agentic list doesn't yet apply to it. A system that calls tools, writes files, sends messages, executes code, holds memory across sessions, or coordinates with other agents has crossed into taking actions, and both lists apply from day one, with the LLM Top 10 governing the model layer and the Agentic Top 10 governing execution, built on top of an agent inventory as the prerequisite for either to function. A system built on third-party agent frameworks, MCP servers, or external agent platforms needs a third layer on top of both: the Modulos guide flags ASI04, supply chain risk, and ASI07, inter-agent communication, as the two categories most affected by framework choice. The MCP Top 10 enters there as its own distinct layer of coverage.

The 2026 LLM list shifted from preventing model compromise to containing its consequences once compromise happens, so if you run a model-only system, you should start thinking in terms of containment architecture alongside input and output filtering. The two frameworks are converging in philosophy even as they stay distinct in scope. What matters is which layer of the system is under scrutiny, and whether anyone has enough visibility into it to notice the moment a model-layer event turns into an execution-layer incident.