Key OWASP Agentic AI Risks Enterprise Teams Must Know

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.

Why the OWASP Top 10 for Agentic Applications Is Its Own 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.

The Ten Risks at a Glance

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.

• Detect: Screen retrieved and external content for injected instructions, and watch for unexpected goal changes. Both are heuristic and can miss, so treat them as signals rather than guarantees.
• Limit impact: Independent authorization on every action, narrow tool scope, and approval gates for goal-changing or high-impact actions.

ASI02: Tool Misuse and Exploitation. An agent uses a legitimate tool in an unsafe or unintended way.

• Detect: Log tool calls and alert on unusual sequences or parameters.
• Limit impact: Per-task tool scoping, parameter validation, and denying sensitive operations by default.

ASI03: Identity and Privilege Abuse. Cached credentials, delegation chains, or implicit identity are exploited.

• Detect: Alert on actions outside an agent's declared scope, or on credentials used from unexpected contexts.
• Limit impact: Per-agent identity with short-lived, scoped credentials instead of inherited broad ones.

ASI04: Agentic Supply Chain Vulnerabilities. A tool, server, plugin, or dependency the agent loads is compromised.

• Detect: Verify provenance and integrity, and monitor for changes to tool definitions.
• Limit impact: Allow only registered components, isolate third-party tools, and keep an inventory.

ASI05: Unexpected Code Execution (RCE). Code the agent generates becomes remote or local code execution.

• Detect: Inspect generated code and watch for unexpected process or network activity. This is one useful layer, but it cannot guarantee safe execution.
• Limit impact: Run generated code in a sandbox with restricted filesystem, network, and credential access. These restrictions matter more than inspection.

ASI06: Memory and Context Poisoning. Corrupted memory or retrieved context skews later decisions.

• Detect: Screen content before it is written to memory, and review anomalies.
• Limit impact: Scope memory to a task or tenant, expire stored context, and record provenance.

ASI07: Insecure Inter-Agent Communication. Messages between agents are spoofed or tampered with.

• Detect: Verify sender identity and message integrity, and flag unexpected communication paths.
• Limit impact: Authenticated, integrity-protected channels and network restrictions between agents.

ASI08: Cascading Failures. One agent's error or compromise spreads across agents and systems.

• Detect: Monitor for loops, error spikes, and cost anomalies.
• Limit impact: Step and budget limits, circuit breakers, and validation at boundaries.

ASI09: Human-Agent Trust Exploitation. An agent's apparent authority is used to manipulate the person it serves.

• Detect: Flag unusual approval patterns on high-risk actions.
• Limit impact: Show reviewers the real action and context, and require independent confirmation for high-impact actions.

ASI10: Rogue Agents. An agent acts outside its sanctioned scope or intent.

• Detect: Audit logs support investigating rogue behavior after the fact.
• Limit impact: Enforce scope at runtime and provide a way to pause or revoke the agent. This is the stronger control, since logs alone only explain what happened.

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.

Assess Your Exposure

Not every category applies equally to every system. A few questions about how an agent is built point to where to look first:

Where to Start: The Three Risks That Interlock

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.

The Remaining Seven, Grouped by Where They Bite

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.

Turning the List Into Runtime Defenses

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:

1. Per-agent identity and least agency. Limits ASI03 directly and shrinks the impact of ASI01, ASI02, and ASI10.
2. Policy checks on every tool call and model request. Addresses ASI02 and ASI08 at the point of action, and ASI01 where the check evaluates inputs.
3. Human approval for high-risk actions, designed to show the real action. Mitigates ASI01 and ASI09 together.
4. An inventory of every tool, server, and dependency. Supports ASI04 and makes access reviews possible.
5. Containment for code execution and bounded limits on loops and spend. Covers ASI05 and ASI08.
6. Tamper-resistant logs tied to each agent's identity. Makes ASI10 detectable and every other incident investigable.

Where a Runtime Policy Layer Sits

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:

• What is checked. An agent calls a function on a registered MCP server. The control plane's tool proxy checks the call against the functions and scope an administrator allowed for that server.
• What happens if it fails. If the function is not permitted, the call is blocked before it reaches the tool. For a model request that triggers a configured policy such as prompt injection defense, the control plane blocks or rewrites the request before the model call completes.
• What is recorded. A structured audit log entry ties the interaction to the policy that applied and the outcome (allowed, blocked, or rewritten), and flows into the organization's existing SIEM.

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.

Questions Worth Asking

1. How is the OWASP Top 10 for Agentic Applications different from the OWASP Top 10 for LLM Applications?

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.

2. Is the list a compliance requirement?

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.

3. Which risk should a team address first?

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.

4. Does covering all ten risks make an agent secure?

No. It makes the risk categories visible and gives each a control, but it does not eliminate risk, and the list will evolve.