TL;DR: The OWASP Top 10 for Agentic Applications is a list of the ten most critical security risks facing autonomous AI agents, published in December 2025. It is a taxonomy to assess exposure against, not a compliance mandate. Goal hijack, tool misuse, and identity and privilege abuse are a practical starting trio because their controls cut across most other categories, and the controls that hold at runtime are the ones that limit what an agent can do, not only the ones that detect trouble. This guide maps all ten risks to detection and impact-limiting controls and shows how to assess where your own agents are exposed.
The OWASP Top 10 for Agentic Applications is a peer-reviewed list of the ten most critical security risks facing autonomous AI agents, published by the OWASP GenAI Security Project in December 2025 with input from more than 100 industry experts and practitioners. It gives enterprise teams a shared vocabulary for agentic application security: systems where models plan, call tools, hold memory, and act with delegated authority rather than only generating text.
This guide covers what each risk means in practice, which ones deserve attention first, and how to turn them into controls that hold at runtime. It treats the list as a taxonomy to assess against, not as a compliance mandate: OWASP's lists are voluntary, community-developed guidance, and this is the first published edition of the agentic list.
The OWASP Top 10 for LLM Applications addresses risks in how any application built on a language model behaves, such as prompt injection and sensitive information disclosure. The agentic list addresses a different layer: what happens when a model can decide to take actions. Most agentic systems are also LLM applications, so the two lists are normally used together rather than as alternatives.
That shift matters for AI agent security because the consequences change. A manipulated chatbot produces a bad answer. A manipulated agent with tool access can move data, change records, or trigger payments. The agentic list is organized around that difference.
These are the ten OWASP security risks for agentic systems, in the order OWASP lists them. The risk names and identifiers come from OWASP's official list. The detection and impact-limiting guidance below, along with the exposure mapping and prioritization later in this guide, are this guide's editorial synthesis, not verbatim OWASP recommendations, so the official source remains the reference for each entry's full guidance.
ASI01: Agent Goal Hijack. An attacker redirects what the agent is trying to accomplish, often through content it reads.
ASI02: Tool Misuse and Exploitation. An agent uses a legitimate tool in an unsafe or unintended way.
ASI03: Identity and Privilege Abuse. Cached credentials, delegation chains, or implicit identity are exploited.
ASI04: Agentic Supply Chain Vulnerabilities. A tool, server, plugin, or dependency the agent loads is compromised.
ASI05: Unexpected Code Execution (RCE). Code the agent generates becomes remote or local code execution.
ASI06: Memory and Context Poisoning. Corrupted memory or retrieved context skews later decisions.
ASI07: Insecure Inter-Agent Communication. Messages between agents are spoofed or tampered with.
ASI08: Cascading Failures. One agent's error or compromise spreads across agents and systems.
ASI09: Human-Agent Trust Exploitation. An agent's apparent authority is used to manipulate the person it serves.
ASI10: Rogue Agents. An agent acts outside its sanctioned scope or intent.
Detection and limiting impact are different jobs. Detection helps identify that something suspicious is happening, such as injected instructions in retrieved content. It is probabilistic and can miss. Put simply, monitoring tells you what happened, while prevention bounds what can. Limiting impact decides what an agent can actually do regardless of what detection catches: independent authorization checks, tool restrictions, approval gates, and containment. A sound design treats detection as one layer and relies on the impact-limiting controls to hold when detection fails.
The ordering in the list is a taxonomy, not a ranking of which risk is most likely in a given environment. Exposure depends on how the agents are built, which the next section turns into a quick assessment.
Not every category applies equally to every system. A few questions about how an agent is built point to where to look first:
| If Your Agents... | Pay Particular Attention To |
|---|---|
| Call tools or APIs | ASI02, ASI03, ASI05 |
| Read untrusted content such as email, documents, or web pages | ASI01, ASI06 |
| Keep persistent memory | ASI06 |
| Load third-party tools, plugins, or MCP servers | ASI04 |
| Coordinate with other agents | ASI07, ASI08, ASI10 |
| Have humans approve their actions | ASI09 |
OWASP does not rank its entries, but one practical reading is that three of them work together in most real incidents. This prioritization is editorial judgment, not part of the OWASP list.
ASI01, Agent Goal Hijack, is how attackers steer. The attacker alters the agent's objective through content it processes, such as an email, a PDF, or a web page. Prompt-injection detection helps identify suspicious content, but what limits the outcome is what the agent is permitted to do once steered: independent authorization checks, tool restrictions, and approval gates for high-impact or goal-changing actions. Detection and mitigation of prompt injection in production covers the underlying techniques.
ASI02, Tool Misuse and Exploitation, is how damage happens. The tool itself is legitimate, but the agent uses it unsafely: chaining a harmless tool with a sensitive API, or forwarding unvalidated output into a powerful command. The mitigation is to scope each tool to the task and validate parameters on every call. Least agency, which limits permissions over models, tools, APIs, and budgets to the minimum a task needs, is the principle that bounds this.
ASI03, Identity and Privilege Abuse, is what limits the damage. Agents often inherit user or system credentials, and cached credentials or delegation chains can be reused or escalated, creating confused deputy situations. Per-agent identity and short-lived, scoped credentials narrow what any hijacked or misused agent can actually do, which is why a zero-trust model for agentic AI starts with identity.
The three interlock. Hijack gets the agent pointed at the wrong goal, tool misuse is the action it then takes, and privilege abuse determines how far that action can reach. Defenses that address only one leave the others open.
Supply chain and execution (ASI04, ASI05). An agent's supply chain includes every tool, server, plugin, and dependency it loads, so a compromised component can behave like a trusted one. Provenance and an inventory of what each agent uses are the starting point, which is what a registered, auditable inventory provides. Where agents generate or run code, execution has to be contained, since agent code execution security depends on keeping generated code inside boundaries it cannot escape.
State and communication (ASI06, ASI07). Memory, retrieved context, and messages between agents are all inputs that can be corrupted. Treat memory writes as untrusted, scope memory to a task or tenant, and review or expire what persists. Between agents, messages need authentication and integrity protection, so one agent cannot impersonate another or alter what it relays. Runtime policy at the API layer does not by itself secure agent-to-agent transport, so this category leans on authenticated channels and network-level restrictions.
System-level behavior (ASI08, ASI10). Cascading failures and rogue agents are about what happens beyond a single request. Step limits, budgets, and validation at each boundary keep one bad outcome from spreading, and reducing an agent's blast radius before deployment bounds the damage in advance. For rogue behavior, enforcing each agent's intended scope at runtime, with a way to pause or revoke it, is the strongest control, and comprehensive, tamper-resistant audit logs of its actions, tool calls, and communications let teams investigate deviation.
The human layer (ASI09). Agents can sound confident and authoritative, and that can be exploited to push a reviewer into approving something harmful. Approval is only a control if the reviewer sees the real action and its context, not just the agent's own description of it.
Working through the list tends to show that security mitigation strategies converge on a small set of controls, each of which addresses several categories at once:
In Prediction Guard's documented architecture, runtime policy enforcement runs in a self-hosted control plane. Applications and agents point their existing OpenAI- or Anthropic-compatible SDK calls at the control plane endpoint, which places the policy layer between the agent and the model or tool, so every call passes through it. Security teams configure policies in an admin console, and each call is evaluated before it executes. For a tool call, one pass looks like this:
This layer addresses some categories directly: input evaluation for ASI01, tool scope for ASI02, and scoped, delegated access to MCP tools for ASI03. It relies on other layers for the rest, such as sandboxing for ASI05 and network restrictions for ASI07. Prediction Guard's sandboxing guide maps each category to the layer that addresses it, including where runtime policy does not apply. For AI application security more broadly, no single layer covers the list, and coverage comes from stacking controls so each category has more than one.
Red-team testing: Prediction Guard also tested its control plane against all ten categories with a team of Purdue University students from Purdue's Data Mine, using intentionally vulnerable agents built for each risk. The methodology and results are in the full write-up.
The LLM list covers how language-model applications handle prompts, data, and outputs. The agentic list covers what agents do with tools, memory, identity, and other agents. Most agentic systems fall under both.
No. It is community-developed guidance for assessing exposure. Regulatory duties, such as EU AI Act logging and oversight obligations, apply according to their own scope.
It depends on how the agents are built, but goal hijack, tool misuse, and identity abuse are a practical starting trio because their controls cut across most other categories.
No. It makes the risk categories visible and gives each a control, but it does not eliminate risk, and the list will evolve.