OWASP Top 10 for Agentic Applications: The Agent Threat List Explained (2026)

When OWASP published the OWASP Top 10 for Agentic Applications on December 9, 2025, it formalized something security teams had been improvising around for two years: the attack surface of an autonomous agent is not the attack surface of a chatbot. A model that answers a prompt has a bounded blast radius. An agent that plans, invokes tools, holds memory across sessions, borrows your credentials, and talks to other agents does not. The 2026 edition is the first widely peer-reviewed attempt to name the risks that live in that gap.

This guide walks through the framework as it actually exists: who publishes it, how the taxonomy is structured, what each ASI item means, how the risks land specifically on AI agents and MCP servers, and how a security team turns a list of ten threats into operating controls. It is a reference, not a pitch. Where the framework is genuinely new and still being implemented across the industry, we say so rather than inventing precision the sources do not support.

What the framework is

The OWASP Top 10 for Agentic Applications is a list of the ten most critical security risks specific to autonomous, tool-using AI agents and multi-agent systems. It is published by the OWASP GenAI Security Project - the same project that maintains the Top 10 for LLM Applications - through its Agentic Security Initiative (ASI). The 2026 edition was released on December 9, 2025, and was developed with more than 100 industry experts, researchers, and practitioners through a global peer-review process.

The critical thing to understand up front: this is not the same list as the OWASP Top 10 for LLM Applications. That list (numbered LLM01 through LLM10, with LLM01:2025 being Prompt Injection) targets single-model prompt-and-response applications - prompt injection, sensitive information disclosure, supply chain, improper output handling, excessive agency, and so on. The agentic list extends that body of work to the things that only exist once a model becomes an agent: autonomous decision-making and planning, tool and API invocation, persistent memory and context, delegated identity and credentials, and agent-to-agent coordination.

Each risk is prefixed ASI - for Agentic Security Initiative, the OWASP initiative that produced the list - and numbered ASI01 through ASI10, written in OWASP's convention as e.g. ASI01:2026. One nuance worth stating clearly: the list is incident-driven and curated from threats observed across real agentic deployments, and OWASP does not frame it as a strict severity ranking. ASI01 is not automatically your highest-risk item; it is the one the contributors saw most across the field.

Where it sits in the broader ASI body of work

The Top 10 is one deliverable inside a larger suite. The Agentic Security Initiative also maintains a threat taxonomy, *Agentic AI - Threats and Mitigations*, threat-modeling guidance, code samples, and a capture-the-flag practice application called FinBot. Many practitioners pair this guidance with MAESTRO, a layered agentic threat-modeling framework published separately by the Cloud Security Alliance, which is a useful structured method for applying the taxonomy to a specific system. If the Top 10 is the headline, the Threats & Mitigations document is the detailed reference behind it.

The taxonomy: ASI01-ASI10

Here is each item, stated at the level the official material supports. Read these as categories of failure, not as individual CVEs - each one spans a family of concrete techniques.

ASI01 - Agent Goal Hijack

An attacker alters an agent's objectives or its decision and planning path through malicious content - direct instruction injection, gradual or indirect injection, or reflection-loop traps - causing the agent to pursue attacker-chosen goals. This is the agentic descendant of prompt injection, but the consequence is not a bad answer; it is a misdirected sequence of real actions.

ASI02 - Tool Misuse

An agent uses legitimate, authorized tools in unsafe ways: parameter manipulation, abusive tool-chain composition or recursion, or scaled misuse of capabilities it is genuinely permitted to call. Nothing is exploited in the classic sense - the agent simply does too much, too fast, or in an unintended combination. This is the failure mode of an over-permissioned but otherwise normal agent.

ASI03 - Identity & Privilege Abuse

Agents misuse, inherit, or escalate credentials, tokens, and delegated permissions to act beyond intended limits. This includes dynamic privilege escalation, cross-system access, and shadow-agent deployment that leverages inherited legitimacy - an agent operating with someone else's effective authority because that is how it was wired.

ASI04 - Agentic Supply Chain Vulnerabilities

Risks introduced through third-party tools, plugins, registries, MCP servers, schemas, prompt templates, and API dependencies that the agent dynamically discovers and trusts - including malicious or poisoned components. This is the item most security leaders underestimate, because agents acquire trust relationships at runtime that never appeared in any design review. See our defender's guide to AI supply-chain attacks for how these get in.

ASI05 - Unexpected Code Execution

An agent generates, modifies, or runs code or commands without sufficient validation or isolation, enabling remote code execution, sandbox escape, or data exfiltration through DevOps and workflow tooling. Coding agents and CLIs are the obvious carriers here - we cover that surface in securing AI coding agents and CLIs.

ASI06 - Memory & Context Poisoning

Stored or retrieved context - agent memory, RAG and vector stores, shared multi-agent memory - is poisoned, stale, or tampered with, corrupting future reasoning and behavior. The dangerous variant is gradual contamination: small, individually plausible writes that bend the agent's behavior over time without any single obvious breach.

ASI07 - Insecure Inter-Agent Communication

Messages exchanged between agents lack authentication, integrity, or policy controls, enabling identity spoofing, message replay and tampering, and strategic false-data injection across an agent network. As multi-agent orchestration becomes normal, the channel between agents becomes an unguarded internal network.

ASI08 - Cascading Failures

Small errors, hallucinations, or compromises propagate and amplify across interconnected planning and execution steps and across multiple agents, producing large-scale, self-reinforcing failure. One agent's bad output is another agent's trusted input, and the system has no natural circuit breaker unless you build one.

ASI09 - Human-Agent Trust Exploitation

Attackers exploit users' over-trust in agent outputs and explanations to drive fraud, phishing, social engineering, and misinformation through a trusted agent interface. This is more an organizational and process risk than a code-level one, but it is on the list precisely because the agent's perceived authority is itself an attack vector.

ASI10 - Rogue Agents

Compromised, drifted, or emergent agents act harmfully while appearing legitimate - via malicious workflow or orchestration injection, goal drift, collusion, or coordinated agent flooding. This is the synthesis risk: the agent looks like it belongs, which is exactly why it is hard to catch.

How it applies to AI agents and MCP servers

Reading the taxonomy, a pattern emerges that matters for how you prioritize. Several items are not really vulnerabilities you patch - they are visibility problems you have to solve before any control is possible. You cannot scope the permissions of a shadow agent you have not discovered (ASI03). You cannot vet an MCP server you do not know is connected (ASI04). You cannot catch a rogue agent that appears legitimate if you never enumerated the legitimate ones (ASI10). This is the practical core of why AI agents and MCP servers are the new shadow IT: the threats land on infrastructure that no inventory currently tracks.

The MCP layer deserves specific attention because it threads through multiple items. ASI02 (tool misuse) runs largely through the tools an agent calls, most of which now arrive as MCP servers. ASI04 names MCP servers explicitly as a supply-chain trust surface. ASI06 poisoning and ASI01 hijack frequently arrive *through* tool descriptions and returned content. If you want depth on that specific surface, see the complete guide to MCP server security and the field write-up on MCP tool poisoning, where hidden instructions in tool metadata drive exactly the ASI01/ASI04 failure modes.

Mapping the framework to what you actually monitor

The table below maps each ASI item to its agentic manifestation and to the observable signal a security team should be watching. The right-hand column is the operational translation: what would actually have to be in your telemetry to detect the risk.

How a security team operationalizes the list

A Top 10 is a checklist, and a checklist is only useful when it drives a process. Here is a pragmatic sequence for turning ASI01-ASI10 into running controls without boiling the ocean.

1. Discover and inventory first. Enumerate every agent and every MCP server actually present in your environment - not the ones in the architecture diagram, the ones in production. ASI03, ASI04, and ASI10 are unaddressable without this baseline.
2. Threat-model each agent system. Use a structured methodology - the ASI's own threat-modeling guidance, or the Cloud Security Alliance's MAESTRO framework - to walk each system against the ten items rather than reasoning ad hoc.
3. Map to existing controls. Many ASI risks already have partial coverage in your stack: identity governance for ASI03, supply-chain review for ASI04, sandboxing and code review for ASI05. Note where coverage stops at the agent boundary.
4. Constrain privilege and tool scope. Treat ASI02 and ASI03 as least-privilege problems: scope which tools each agent may call and which credentials it inherits, and revisit on a schedule.
5. Add runtime behavioral monitoring. Static review cannot catch goal hijack, gradual memory poisoning, or a rogue agent that drifts after deployment. These are detected at runtime or not at all.
6. Keep an audit trail. ASI09 and post-incident response for every item depend on a durable record of what each agent did, when, and with what authority.

For fleets of coding assistants specifically - a fast-growing slice of the agent population and a heavy contributor to ASI02 and ASI05 - our guide on governing AI coding assistants across your fleet walks the policy and rollout mechanics in detail.

A note on what the framework does not do

The list names risks; it does not prescribe a single mandated control set, and OWASP does not present it as a severity ranking for your environment. Do not treat ASI01 as your top priority by default. A fleet of read-only research agents has a very different risk profile from a fleet of agents with shell access and inherited cloud credentials. The list is the vocabulary; your threat model supplies the priorities.

Where continuous agent and MCP visibility fits

Several items on this list collapse to the same prerequisite: you cannot govern what you have not seen. ASI04 is, almost word for word, the shadow-IT problem applied to MCP servers and plugins your agents discovered and trusted at runtime. ASI03 and ASI10 are the shadow-agent and rogue-agent problems - both of which assume you have a definitive inventory of the legitimate agents to compare against.

This is the category Anomity works in: a discover-to-audit loop across the agent fleet. Discovery and inventory address the visibility gap behind ASI03, ASI04, and ASI10 - enumerating every agent and MCP server, the credentials they inherit, and the unvetted components in use. Behavioral monitoring against a baseline addresses the runtime risks - ASI01 goal drift, ASI02 abusive tool-chains, ASI05 code-execution anomalies, ASI06 post-poisoning drift - that static review and design-time threat modeling structurally miss. Fleet-wide visibility and a durable audit trail support ASI07, ASI08, and ASI09, where the value is early detection of propagation and the evidence to investigate after the fact. We describe how the discovery side works in Inside Anomity Discovery, and what we typically surface in what we find when we scan AI agent configs.

The honest framing: no single product closes all ten items, and the OWASP list never implied one would. Identity governance, sandboxing, supply-chain review, and gateway controls each own a slice. What the agentic-specific risks add - and what most existing stacks lack - is continuous visibility into a population of autonomous actors that deploy themselves, acquire trust at runtime, and change behavior after review. Use the Top 10 as the shared vocabulary to find your gaps, then close them with the controls you already trust plus the runtime visibility the agent layer now demands.