OWASP Top 10 for Agentic Applications

What is the OWASP Top 10 for Agentic Applications?

The OWASP Top 10 for Agentic Applications is a list of the ten security risks that turn up in AI systems which plan, remember, call tools and act with permissions of their own. The OWASP GenAI Security Project published it on 9 December 2025, as the 2026 edition. The entries are numbered ASI01 to ASI10, and vendor documentation and security reports now cite them that way.

OWASP is the Open Worldwide Application Security Project, a nonprofit foundation that launched in 2001 and has published a Top 10 for web application security since the early 2000s. A Top 10 is not a standard and there is nothing to certify against. It is the security community writing down what actually goes wrong, in an order most of the field can agree on, so a team has somewhere to start instead of a blank page.

This list went through a review round with national cybersecurity agencies, standards bodies, vendors and researchers, with an expert board that included Apostol Vassilev of NIST and people from Microsoft's AI red team. It builds on a taxonomy of agentic threats and mitigations that the same project published in February 2025. The Top 10 is the short readable front door to that material.

The ten risks

Each entry gets a chapter in the published document with attack scenarios and mitigations. This is what they are about.

1. ASI01 Agent Goal Hijack
   Someone changes what the agent is trying to achieve, using text the agent reads rather than code it runs. This is prompt injection landing on something that acts: the agent still thinks it is doing your job, and every step after that is wrong on purpose.

2. ASI02 Tool Misuse and Exploitation
   The agent turns its own tools against you: harmless tools chained into a harmful sequence, output passed unchecked into a command that can delete or send, or a tool whose description was written to mislead the model. Tool poisoning is the best documented example.

3. ASI03 Identity and Privilege Abuse
   The agent works under a shared login, a borrowed employee token or a permission set nobody trimmed, so whatever gets hold of it also gets everything it can reach. Long-lived credentials are what make a single agent worth attacking.

4. ASI04 Agentic Supply Chain Vulnerabilities
   An agent is assembled while it runs out of a framework, a model, plugins, tool descriptors and MCP servers, most of which you did not write. A tampered dependency loads itself into the agent without a build step to catch it.

5. ASI05 Unexpected Code Execution
   Agents write code and run it, and they pass text into shells, file paths and interpreters. Text that came in from outside then executes somewhere it was never meant to, and the sandbox is the only thing between that and the rest of the machine.

6. ASI06 Memory and Context Poisoning
   What the agent stores today steers what it decides next month. A false fact written into conversation history or a document index keeps working long after the session that planted it ended, which is what makes it hard to trace back.

7. ASI07 Insecure Inter-Agent Communication
   When agents hand work to each other, those messages need authentication and integrity checks like any other network traffic. Without them an attacker can impersonate an agent, alter a message in transit, or register a fake peer the others accept.

8. ASI08 Cascading Failures
   One wrong answer travels. A downstream agent trusts an upstream result, acts on it and passes its own result on, so a single hallucination or poisoned record becomes a chain of confident actions before anyone notices.

9. ASI09 Human-Agent Trust Exploitation
   This one is aimed at the person, not the system. A confident summary hides what the agent actually did, or the agent asks for a credential, an approval or a permission change in language that sounds like normal support. People approve what reads well.

10. ASI10 Rogue Agents
    An agent that keeps running outside its intended purpose, through compromise, through misalignment, or because nobody switched off the one a departed colleague built. Each individual action looks legitimate; the pattern over weeks is not.

How it differs from the OWASP Top 10 for LLM Applications

The same project publishes both lists and maps them onto each other on purpose. The dimension that matters is what is being attacked.

The LLM Top 10 assumes a model call: text goes in, text comes out, your application does something with the output. Its entries are about that call and what touches it, from prompt injection (LLM01) to improper output handling (LLM05) and system prompt leakage (LLM07), using the 2025 numbering; OWASP renumbered the LLM list in August 2026. You can review most of it by reading the prompt, the retrieval step and the code that handles the answer.

The agentic list assumes something that keeps state and takes actions between calls. What is under attack is the loop that decides the next step, the memory that survives the session, the tools and credentials the agent holds, and the other agents that trust its output. None of that is visible in a single request.

The two overlap where you would expect. Prompt injection is the technique; agent goal hijack is what that technique does once the reader can act. Excessive agency (LLM06 in the 2025 edition, LLM03 since August 2026) is a single entry in the older list; in the newer one that ground is spread over several entries, from identity and privilege abuse for what the agent may touch to rogue agents for what it does with that over time.

The practical consequence: if you run a chatbot that only writes text, the LLM Top 10 is your list. The moment that same model gets a tool that writes to something, the agentic list starts asking questions the LLM list has no place for, such as whose identity the agent acts under and who can write to its memory.

Using the list as an SME

You do not have to work through all ten. There are two ways to get something out of the list in an afternoon.

As a checklist when you buy or build. Walk the ten entries against the one agent in front of you and mark each as relevant or not. A single agent that drafts quotes has no inter-agent communication and probably runs no code, so ASI05 and ASI07 are out. Write down that you ruled them out and why. That note is what you reread when the second agent arrives and starts talking to the first one.

As a question list for a supplier. The entries convert into questions a vendor can answer without a security team in the room.

• Whose identity does the agent act under, and can we switch it off separately from the employee who set it up? (ASI03)

• Which actions happen without a human click, and which ones cannot? (ASI02, ASI09)

• What gets written to memory, who can put text there, and how do we clear it? (ASI06)

• Which third-party components load while it runs, and are the versions pinned? (ASI04)

• If another system acts on its output, what happens when that output is wrong? (ASI08)

• How do we stop it, who is allowed to press that, and how long before it has actually stopped? (ASI10)

A supplier who answers these plainly has thought about them. A supplier who answers with a certification logo has not answered. For a quicker first pass on the data-leak half of the problem, the lethal trifecta gives you three questions instead of ten; the OWASP list is what you reach for once the answer to those three was uncomfortable.

What the list does not do

It is a risk taxonomy, not a compliance framework. There is no audit, no clause to point at and no such thing as being OWASP-compliant. It gives you shared words for a conversation and a set of mitigations to consider. What you do with them is your decision and stays your responsibility.

The AI Act is a separate obligation. Article 15 of the AI Act requires high-risk systems to be resilient against attempts by unauthorised third parties to alter their use, outputs or performance, and it names data poisoning, model poisoning and adversarial inputs among the things the technical measures have to address. Article 14 requires human oversight, including a stop. Working through the OWASP list helps you build what those articles ask for, and gives you something concrete to write in a technical file, but it does not tell you whether your system is high-risk and it carries no legal weight of its own.

It ranks security risk, not the ordinary ways an agent disappoints you. Wrong answers and money burned on a loop that never finished sit in the LLM list, as misinformation and unbounded consumption, or in your own quality process. An agent can score clean against all ten entries and still be a bad idea.

It is a snapshot with a date on it. The 2026 edition is the first one, and the attacks it names were demonstrated during 2025, many of them against coding agents and MCP setups. Expect a next edition and expect the order to move. What is worth copying is the habit of walking a list before an agent touches production, not the exact ten items.