The OWASP Top 10 for Agentic Applications lists the ten biggest security risks of AI systems that plan and act on their own, from Agent Goal Hijack (ASI01) to Rogue Agents (ASI10). The OWASP GenAI Security Project published the 2026 edition on December 9, 2025. If your staff use agents like Claude Code, Cursor or Codex, at least five of the ten apply to you right now, even if you've never built an agent.
Most summaries of this list are written for the teams building agents. This one is for the person responsible for the agents already running in their company. For each risk, it covers what it means on your side and what evidence you'd want to have. The mapping to deployed agents is our own reading, so use the official document for OWASP's full text.
The ten risks
| ID | Risk | What it means in plain language |
|---|---|---|
| ASI01 | Agent Goal Hijack | Content the agent reads changes what it's trying to do |
| ASI02 | Tool Misuse and Exploitation | The agent uses a legitimate tool in a harmful way |
| ASI03 | Identity and Privilege Abuse | The agent inherits or escalates credentials it shouldn't use |
| ASI04 | Agentic Supply Chain Vulnerabilities | A plugin, MCP server or template the agent relies on is compromised |
| ASI05 | Unexpected Code Execution | The agent generates or runs code unsafely |
| ASI06 | Memory and Context Poisoning | Bad data in the agent's memory corrupts later decisions |
| ASI07 | Insecure Inter-Agent Communication | Messages between agents get spoofed, replayed or changed |
| ASI08 | Cascading Failures | One small error spreads across steps and gets bigger |
| ASI09 | Human Agent Trust Exploitation | People trust an agent's output too much and act on it |
| ASI10 | Rogue Agents | An agent acts harmfully while looking legitimate |
The five that apply to every company using agents
These don't depend on what you build. They apply as soon as someone installs an agent on a work machine.
ASI01, Agent Goal Hijack. An agent reads web pages, tickets and pull requests all day. If one of them carries hidden instructions, the agent may follow them. Filtering content won't catch all of it, so you also need to see when an agent acts right after reading something suspicious. We show what this looks like in what a prompt injection looks like on a laptop.
ASI02, Tool Misuse and Exploitation. The tools are real and the access is valid, which is why normal security tools don't flag this. The evidence you want is a record of every tool call, plus a list of which agents hold tools that can delete things or send data out.
ASI03, Identity and Privilege Abuse. A coding agent usually runs as the developer, with all the access that person has. Amazon's own account of its Kiro outage comes down to this: an engineer's role had broader permissions than expected. You need to know which credentials each agent can reach and whether any of them are shared across machines.
ASI04, Agentic Supply Chain Vulnerabilities. Developers add MCP servers, skills and extensions without a review, and some fetch new code when they start. You need an inventory of these components across every machine, and you need to know when an approved one changes. Our MCP security guide covers how to review a server.
ASI05, Unexpected Code Execution. Running code is what a coding agent does, so you can't simply ban it. Look at where it runs and what's within reach. Generated code on a laptop full of live credentials is a very different risk from the same code in a throwaway container. One setting decides a lot of this, which we cover in our guide to the --dangerously-skip-permissions flag.
Join the launch list and see these five risks across your own endpoints. You'll be first in when ZYBE opens.
The other five
ASI09, Human Agent Trust Exploitation. This one comes down to your people, and it applies to you too. In Meta's Sev 1 incident, an employee reportedly followed an agent's bad advice, and data became visible to engineers who shouldn't have seen it. Your change controls should treat an agent's advice the way they'd treat advice from anyone else.
ASI10, Rogue Agents. An agent nobody approved can do as much damage as a compromised one. Start by finding agents you didn't know about, then watch for behaviour that doesn't match what the agent normally does. Our shadow AI guide explains how to find them.
ASI06, ASI07 and ASI08. Memory poisoning, agent-to-agent messaging and cascading failures matter most if you build multi-agent systems of your own. If you only use off-the-shelf agents, ask those vendors how they handle these risks. On your side, unusual bursts of activity are the signal to watch, such as far more tool calls or subagents than an agent normally uses.
What to do this quarter
- List every agent. You can't assess risks on agents you don't know about, and a survey will miss some of them.
- Map what each one can reach. That means credentials, MCP servers, and whether it acts without asking.
- Set a standard for approvals. Decide where agents may act alone, and enforce that through managed settings. Our AI agent governance guide can help you set this up.
- Keep the records. Keep a dated log of what agents did, so you can show this list to an auditor or a customer with evidence behind each line.
Why you can't do this by hand
You can check one laptop in an afternoon. With three hundred laptops, several agents on each, and settings developers can change at any time, a spreadsheet is out of date the day you finish it. Most of these risks also show up as behaviour, so a point-in-time review won't catch them.
How ZYBE handles this
ZYBE finds every AI agent on every endpoint, shows what each one can reach, and stops the ones that shouldn't act. For the five risks above, these are some of the rules that fire:
| Risk | ZYBE rules |
|---|---|
| ASI01 | Instructions to the agent in tool output, Agent acted after instructions arrived in tool output, Same injected instructions on several endpoints |
| ASI02 | MCP server has destructive tools, Agent ran a destructive command, Data sent to a paste site, file share or webhook |
| ASI03 | Agent read a credential file, Credential used, then the network, Same credential on several endpoints, Agent signed in as somebody who has left |
| ASI04 | MCP tool description carries instructions for the agent, Approved component changed, Package flagged as malicious |
| ASI05 | Remote script piped into a shell, Agent acts without asking, Agent may run shell commands without asking |
For ASI10, Agent nobody shipped finds the agents you didn't approve, and More tool calls than this agent normally makes picks up unusual behaviour. Each finding is dated and tied to a machine, so you've got evidence ready when someone asks.
Join the launch list and be first to run this on your own endpoints
Frequently asked questions
Who publishes the OWASP Top 10 for Agentic Applications? The OWASP GenAI Security Project. The 2026 edition was published on December 9, 2025.
What is the difference between the OWASP LLM Top 10 and the Agentic Top 10? The LLM Top 10 covers risks in applications built on a language model, such as prompt injection and sensitive data disclosure. The Agentic Top 10 covers what goes wrong once a model can plan and act through tools, credentials and other agents.
Is the OWASP Agentic Top 10 a compliance requirement? No. It is a guidance document, and no regulation requires it by name. It is still useful in an audit or a customer review, because it gives you a recognised list to show your controls against.
Does the OWASP Agentic Top 10 apply if we only use AI agents and do not build them? Yes, though not every item applies equally. Goal hijack, tool misuse, privilege abuse, supply chain and code execution all apply to any company whose staff run agents like Claude Code, Cursor or Codex.