OWASP Agentic AI Top 10 Risks Explained

82% of executives say they trust their current policies to stop agents from going rogue. Put that next to another number and watch the gap open up: 80.9% of technical teams have already moved past planning into active testing or production, according to Gravitee's April 2026 survey of 750 senior technology leaders. Only 14.4% say all their AI agents go live with full security and IT sign-off.

That gap is where ungoverned agents live and multiply. Most people skip right past it to get to the scarier stuff, which is a mistake, because the gap is the story.

Gartner expects 40% of enterprise applications to include task-specific AI agents by the end of 2026. Deloitte puts the number of companies using agentic AI at 75% or more by 2028. Line those forecasts up against the approval numbers above and the picture gets plain fast: agents are reaching production faster than anyone can build guardrails around them. In most organizations, security teams find out about a new agent the same way they find out about most things: after engineering already shipped it. Shadow AI happens when a team hits a wall waiting for a governed path and builds its own instead.

Documented incidents already show what this costs, and they aren't subtle. In one reported case, an AI coding agent took destructive actions that existing controls were specifically meant to prevent. Around the same time, research from Apiiro found that privilege escalation paths in AI-generated code jumped 322%. The code these agents write is widening the attack surface at the exact moment the agents themselves are running loose with too little oversight.

That's the backdrop for the OWASP Agentic AI Top 10, released December 10, 2025 by the OWASP GenAI Security Project. It's over a year of work, built on input from more than 100 security researchers, practitioners, and technology providers, and reviewed by an Expert Review Board that included people from NIST and the European Commission. NIST, Microsoft, and NVIDIA have all endorsed it, and that matters in a plain, practical way: auditors and regulators now have one shared reference point, where before there was mostly vendor marketing and scattered blog posts.

The Top 10 is one piece of a larger set called the Agentic Security Initiative: five connected documents covering threat taxonomy, architectural threat modeling (the MAESTRO framework), developer and operator controls, this ranked list of ten risks, and a governance and regulatory map. Calling it a rename of the older LLM Top 10 misses the point entirely, and that mistake will cost anyone who makes it. The older list covers a model answering a prompt. This one covers systems that plan, hold memory, call tools, act under an identity, and hand work off to other agents. Autonomy is what creates the new threat surface. Tool misuse, identity abuse, memory poisoning, insecure agent-to-agent messaging, cascading failures, rogue agents: these risks come specifically from systems that act and delegate, not from systems that merely answer questions.

The version that matters most for practitioners is 2.01, published June 1, 2026 as part of OWASP's "State of Agentic AI Security and Governance" report. It rebuilt the whole list around real incidents instead of projected ones. What follows walks through all ten risks in order: how each one actually breaks, and what actually closes the gap.

ASI01 — Agent Goal Hijack: when an agent pursues the attacker's objective instead of the user's

Goal hijack happens when an attacker redirects what an agent is trying to do, using content the agent reads rather than code anyone runs. The agent has no idea it's been hijacked; it still thinks it's chasing the user's original request.

This works because of how language models actually process input. System instructions, user text, and retrieved documents all get flattened into one token stream. There's no wall, consistently enforced, between "instructions I should trust" and "content I happened to read." Prompt injection is the delivery mechanism behind many of the ASI categories, which makes ASI01 less a single risk and more a root cause showing up everywhere else on this list.

The clearest public example is EchoLeak, tracked as CVE-2025-32711 with a CVSS score of 9.3: the first known zero-click, indirect prompt injection to achieve confirmed data exfiltration in a production LLM system. Here's the chain. An attacker sends an email with a hidden prompt, tucked into an HTML comment or written in white text on a white background. Microsoft 365 Copilot's retrieval engine pulls that email in as context during some unrelated task, and the agent then acts on the attacker's buried instruction: no click, no download, no user action of any kind. The flaw touched Microsoft 365 Copilot across multiple products in the suite. Microsoft patched it, but the underlying vulnerability class, any RAG system pulling untrusted content into its reasoning, is still alive everywhere else.

Fixing this means treating every piece of natural-language input, typed message or retrieved document alike, as untrusted until it clears sanitization checks. System prompts need locking and versioning, so the agent's allowed goals and actions live somewhere auditable instead of just implied. Runtime monitoring for goal drift matters just as much: if a task that started as "summarize this invoice" turns into "initiate a wire transfer," that's the moment to stop and pull in a human, not the moment after the money's gone. Any action that changes the agent's goal, or carries real weight, needs a human's explicit sign-off. Skip that visibility layer, and goal hijack usually only shows up during the postmortem, well after the damage is done.

ASI02 — Tool Misuse and Exploitation: legitimate tools weaponized through manipulation

Agents aren't breaking tools. They're getting talked into misusing tools that work exactly as designed, which is a much harder thing to test for than a bug.

Amazon Q Developer's July 2025 incident makes this concrete. A malicious pull request injected instructions telling the agent to "clean a system to a near-factory state" and delete file-system and cloud resources. The agent did precisely what an AI coding assistant is built to do; it just did it with destructive intent behind the wheel, and no sandbox strong enough to stop it.

Tool poisoning is a narrower version of the same pattern. An attacker edits an MCP tool's description so the agent misreads what the tool actually does. The model thinks it's calling a search function; in reality, the tool is exfiltrating data. The attack follows a consistent sequence: the tool description gets silently altered, the agent re-trusts it dynamically without asking for re-approval, the agent executes the call, and data walks out through what looks like a routine, approved action.

A related problem, unsafe tool chaining, happens when an agent strings together several individually permitted tool calls that, combined, produce an outcome no single call would ever be allowed to produce on its own.

OWASP's fix is the "least agency" principle: give an agent only the tools and permissions its specific task needs, nothing more. That alone shrinks the blast radius a lot. Past that, tool descriptions and outputs need real checking, not just confirmation that the tool exists and responds. Every tool call should get logged with its parameters, because that log is the evidence trail investigators need when something breaks. And any time a tool's behavior changes at runtime, that should force a fresh approval, not a silent pass-through.

ASI03 — Identity and Privilege Abuse: what happens when agents inherit more access than they need

Autonomy adds something traditional access control was never built to handle: how much room an agent has to act on its access without checking back with anyone first.

Multi-agent systems make this worse through delegation chains. An orchestrator hands off credentials or roles to sub-agents, and trust flows down the chain without getting re-checked at each hop. If one agent buried in that chain is running a broad, long-lived token and gets hit with a remote code execution attack, everything that token touches becomes reachable from that single point.

OWASP calls the fix "Least Agency," least-privilege thinking applied directly to autonomy itself. Permissions should be scoped to the task at hand and bounded in time, never handed out broadly and left standing around. Agent identities and their contexts need isolation between tasks, with session state wiped clean so nothing, no credential, no leftover context, bleeds across a boundary it shouldn't cross. A central policy engine should approve sensitive actions the moment they're requested, not back at deployment time, when nobody could have guessed what the agent would eventually try. And any privilege escalation, any widening of what an agent can touch, needs a human to sign off on by name. Role-based access control for agents makes sure whatever an agent can do was a decision someone actually made on purpose, not a default nobody bothered to check.

ASI04 — Agentic Supply Chain Vulnerabilities: the attack surface agents load at runtime

Traditional supply chain attacks target dependencies installed when software gets built. Agentic supply chain attacks target what agents pull in while they're running: MCP servers, plugins, tools fetched live from a registry.

Three incidents lay out the shape of this threat. In one documented case, a poisoned prompt inside an AI developer extension nearly triggered destructive file-wipe commands, stopped only by sandboxing. In September 2025, a malicious package impersonated a legitimate MCP server, shipping multiple versions that looked like normal updates until a later version quietly added functionality that routed data to an address the attacker controlled. And a critical remote-code-execution flaw sitting inside widely used MCP infrastructure that large numbers of developers depend on.

The registry problem underneath all three: most MCP marketplaces accept submissions without any real vetting. An attacker can publish a malicious tool and iterate on it through what looks like an ordinary release cadence, version bump after version bump, until the one update that matters slips through unnoticed.

The fix here isn't optional and it isn't complicated: a centralized, approved registry of MCP servers and tools, one where every server an organization actually runs has an entry someone can point to. An unregistered tool is an unaccountable one. Tool versions should be pinned, with integrity hashes checked before an agent loads anything, and a version bump ought to trigger a re-review, not get waved through as routine maintenance. Tool descriptions need vetting independent of whether the tool works correctly, since a tool that runs perfectly can still carry a poisoned description. And outbound data flows from tool calls need real-time monitoring, not a log somebody checks after the fact.

ASI05 — Unexpected Remote Code Execution: when agent sandboxes fail

Agents that run code or touch system resources directly can get talked into running arbitrary code outside the boundary they were meant to stay inside.

The sandbox assumption doesn't always hold up. Plenty of deployment setups assume the agent runs fully isolated, but dynamic tool composition at runtime, agents combining tools in ways nobody explicitly planned for, can break that isolation without anyone noticing until it's too late. The critical MCP infrastructure flaw mentioned above is the clearest documented case: a weakness at the infrastructure level, not in the model itself, opened a remote-code-execution path across a large population of developers.

There's a direct link back to ASI03 here, and it's worth saying plainly. Remote code execution with no privilege limits is close to catastrophic; the same failure inside an environment built on task-scoped, least-agency permissions stays contained. That's exactly why the ASI03 fixes end up doing a lot of the load-bearing work for ASI05 too.

Strict sandboxing needs enforcement at the infrastructure level, with checks confirming that runtime tool composition genuinely can't escape its execution boundary. Network egress controls should stop code execution from reaching any external endpoint the task doesn't specifically need. Treat agent execution environments as hostile by default: assume untrusted input eventually reaches the execution layer no matter what precautions exist upstream. And infrastructure-level MCP components like mcp-remote need patching and version-pinning with the same urgency any application-level dependency would get.

ASI06 — Memory and Context Poisoning: corrupting what agents remember and retrieve

This risk targets an agent's persistent memory and shared context stores: vector databases, knowledge graphs, conversation history. Poison those, and the agent pulls from and acts on corrupted information across every future task that touches that store.

It's structurally different from ASI01. Goal hijack operates within a single interaction, while memory poisoning corrupts a store that persists across sessions, touches multiple users, and often looks exactly like legitimate retrieved knowledge, which is what makes it hard to catch. RAG pipelines are especially exposed, since the retrieval step brings external content into the agent's reasoning path, and the agent has no reliable way to tell attacker-planted content apart from the real thing. In multi-agent systems this compounds: one corrupted shared knowledge store can misdirect every agent that draws from it.

Memory and retrieval stores deserve treatment as a security boundary in their own right, with access controls and integrity checks on what gets written in, not just what comes back out on a query. Every write to persistent memory should get logged with an identity and a timestamp attached; odd write patterns are often the earliest sign something's gone wrong. Memory stores should be separated by sensitivity tier, so an agent only pulls from the stores its task actually needs. And retrieved content should pass through the same untrusted-input checks user-supplied text goes through, instead of getting a free pass just because it came from an internal database rather than a stranger's email.

ASI07 — Insecure Inter-Agent Communication: trust assumptions that break down in multi-agent systems

In a multi-agent setup, a compromised or malicious agent can send a crafted message to a peer agent, and that peer often treats the message as a trusted instruction for no better reason than it came from inside the system.

That's the core problem, and it's simple to state plainly: agents in a pipeline generally accept messages from other agents with no cryptographic check on where the message came from or whether it got altered along the way. Orchestrator-to-subagent communication, subagent-to-subagent handoffs, none of it typically carries the kind of verification that would catch a forged or tampered message before it gets acted on. Trust flows through the pipeline by default, and that default is exactly what an attacker needs. Compromise one node, and the rest of the system starts obeying instructions it was never supposed to hear.