Logan Kelly
ASI01–ASI10 are OWASP's ranked risks for AI agents. See what each one means and how to enforce against it.
The OWASP Top 10 for Agentic Applications is a ranked list of the ten most critical security risks specific to AI agents that plan, use tools, and take multi-step actions — published December 9, 2025 by the Agentic Security Initiative (ASI) of the OWASP Gen AI Security Project, developed with more than 100 industry researchers and practitioners. It uses ASI01–ASI10 numbering, distinct from the older OWASP LLM Top 10, because a single risky prompt and a multi-step agent that plans, calls tools, and acts on a user's behalf fail in fundamentally different ways.
That distinction is the whole point of the list. It exists because the previous framework wasn't built for what agents actually do in production.
The problem the framework solves
The OWASP LLM Top 10 was built for a single model call: one prompt in, one response out, one trust boundary to defend. Agentic systems don't work that way. An agent plans across multiple steps, calls tools with real credentials, reads content from emails, tickets, and retrieved documents, and sometimes hands work off to other agents — each of those is a separate point where something can go wrong, and each has different consequences than a single bad model response.
The old framework had one catch-all category for this — LLM06, "Excessive Agency" — and it wasn't enough. The Agentic Top 10 splits that single category across four of its own (ASI01, ASI02, ASI05, ASI10) because a hijacked goal, a misused tool, unsafe code execution, and a fully rogue agent each need a different defense. Treating them as one problem meant most teams were defending against none of them precisely.
The analogy: from perimeter defense to identity-and-action defense
Traditional application security assumes a fairly stable perimeter: a known set of endpoints, a known set of users, requests that either pass validation or don't. Agentic risk doesn't fit that model, because the "user" making a request downstream might be an agent acting on a human's behalf, several steps removed from that human, carrying that human's permissions into a decision the human never reviewed.
That's closer to how identity and privilege escalation are handled in cloud security than to classic input validation — the question isn't just "is this input malformed," it's "does this actor, at this step, in this chain of delegation, still have the authority it's using." OWASP's Agentic Top 10 treats identity as load-bearing for exactly this reason: an agent that's been redirected — through a poisoned memory entry, a malicious tool response, or a compromised sub-agent — doesn't just misbehave, it acts with someone else's full authority in ways nobody approved.
How this applies to AI agents specifically
Every category in the Agentic Top 10 maps to a point where an agent crosses a trust boundary: the model call, a tool invocation, a handoff to another agent, a read from memory or a retrieved document. In a single-call LLM system there's one boundary to defend. In an agentic system, every tool, every memory store, every sub-agent, and every external data source is its own boundary — which is why a framework built for the single-call case consistently under-covers what agents actually do.
The ten risk categories
ASI01 — Agent goal hijack. An attacker manipulates an agent's objectives or decision path — through instructions hidden in an email, document, or tool result — so it pursues outcomes the operator never intended. This is prompt injection's agentic successor: instead of corrupting one response, it redirects a multi-step plan.
ASI02 — Tool misuse and exploitation. An agent uses a connected tool in a way it wasn't designed for, or an attacker crafts inputs that make a tool execute unintended commands — calling a delete endpoint when it should have called a read endpoint, for instance.
ASI03 — Identity and privilege abuse. An agent uses credentials or inherited permissions beyond its task's actual scope: overpermissioned tokens, a sub-agent that inherits its parent's full access, or access granted for one purpose used for another.
ASI04 — Agentic supply chain compromise. Third-party tools, plugins, and MCP servers become attack vectors. A compromised MCP server doesn't just ship bad code — it can serve bad instructions to agents that will act on them with real credentials.
ASI05 — Unexpected code execution. An agent generates, modifies, or runs code outside a safe boundary — sandbox escape, injected
eval-style execution, or persistent changes to its own execution environment. Most relevant to coding agents and any agent with code-execution tools.ASI06 — Memory and context poisoning. An agent's retrieved or stored context is corrupted, stale, or tampered with, so it reasons from false premises — covering both poisoned retrieval data and manipulated persistent memory.
ASI07 — Insecure inter-agent communication. Agents exchange messages with other agents without verifying sender identity, message integrity, or whether the instruction falls within authorized scope.
ASI08 — Cascading failures. A single compromised agent, resource-exhaustion loop, or corrupted output propagates across connected agents and workflows, turning one incident into a much larger one.
ASI09 — Human-agent trust exploitation. An agent's outputs are manipulated to get a human to approve a malicious action or disclose sensitive information — the human is the target, the agent is the delivery mechanism.
ASI10 — Rogue agents. A compromised, misaligned, or drifting agent keeps operating against its intended purpose, accumulating access or persisting after it should have been shut down — often the end state of an undetected failure elsewhere on this list.
How Waxell handles this
Waxell's position on the Agentic Top 10 is that each category needs enforcement at a specific point in the execution path, not a single blanket control. Across Waxell's products, that maps out fairly directly.
Waxell Observe enforces at the model-call boundary against 50+ policy categories — including Content, Reasoning, Control, and Safety — which is where ASI01 (goal hijack) and ASI06 (memory and context poisoning) need to be caught: inspecting inputs and outputs for injected instructions and poisoned context before the agent acts on them, and mapping enforcement to frameworks like the OWASP LLM Top 10, NIST AI RMF, and ISO 42001.
The Waxell MCP Gateway is the most direct answer to ASI02, ASI03, and ASI04. Tool fingerprinting across five trust states (Pending, Drift, Trusted, Blocked, Removed) catches ASI04-style supply chain drift when an MCP server's behavior changes after it's been vetted. A prompt-injection scanner on tool descriptions catches ASI02-style exploitation before an agent ever calls the tool. Identity resolution across three auth modes — on-behalf-of OAuth, shared service account, and bring-your-own token — with one-transaction offboarding, is the direct enforcement layer for ASI03's privilege-abuse problem.
Waxell Runtime targets ASI05, ASI08, and ASI10. Policy enforcement happens before each step runs, not after, with isolated execution and kill switches at every level — an agent, a run, or a whole fleet can be halted immediately. Durable checkpoint-and-resume workflows contain ASI08-style cascading failures by making sure one agent's compromise doesn't propagate silently through the rest of a workflow.
Waxell Connect addresses ASI07's inter-agent trust gap by giving agents a shared, versioned workspace with a full audit trail of hand-offs between agents and teams, rather than opaque message-passing with no record of what was authorized.
Waxell Endpoints extends coverage to ASI09 and ASI10 outside of any single deployed system — discovering 60+ AI provider domains across Mac and Windows so a rogue or shadow agent running on an employee's machine isn't invisible to the same policy layer governing the agents a team built deliberately.
FAQ
Is the OWASP Agentic Top 10 a replacement for the LLM Top 10?
No — they cover different trust boundaries. The LLM Top 10 addresses risks at a single model call. The Agentic Top 10 addresses risks that only exist when a system plans across multiple steps, holds credentials, and calls tools autonomously. Most production agent systems need to defend against both lists, since an agent still makes individual model calls in addition to acting on their outputs.
Which category should a team address first?
OWASP ranks ASI01 (agent goal hijack) as the top risk, and it's a reasonable starting point since it's the entry point for several downstream failures — an undetected goal hijack can lead directly to tool misuse (ASI02) or a rogue agent (ASI10). But the right starting point in practice depends on what an agent can actually do: a coding agent with code-execution tools should prioritize ASI05, while a multi-agent system handing off work should prioritize ASI07.
Does using a well-known LLM provider protect against these risks?
No. All ten categories are architecture and integration risks, not model risks — they exist because of what an agent is allowed to do with tools, memory, and credentials, independent of which underlying model is making the decisions. A well-aligned model with unrestricted tool access is still exposed to ASI02 through ASI04.
How is ASI04 (agentic supply chain compromise) different from typical software supply chain risk?
A compromised software dependency usually needs to be executed to cause harm. A compromised MCP server can cause harm just by being read — its tool descriptions and responses are treated as instructions an agent may act on with real credentials, which is why tool-description scanning and server allowlisting matter specifically for agentic systems in a way they don't for a typical npm or pip dependency.
Is this framework only relevant to security teams, or does engineering need to act on it too?
Both. Several categories (ASI02, ASI04, ASI05) are enforced closest to where engineering builds and connects tools — schema validation, sandboxing, allowlisting. Others (ASI03, ASI07, ASI09) depend on identity and audit infrastructure that security and platform teams typically own. A framework this granular tends to get ignored if it's handed to only one team.
Where does this framework leave gaps?
It's explicitly a top-10 list, not exhaustive — it doesn't deeply cover areas like model-level training risks or physical/robotic agent safety, and some categories (like ASI07's inter-agent trust) are still maturing as multi-agent protocols themselves evolve. Treat it as a prioritized starting point, not a complete risk inventory.
Sources and verification notes
Agentic Governance, Explained
