Last updated:
The OWASP Top 10 for Agentic Applications is a peer-reviewed list of the ten most critical security risks in autonomous AI agents, published by the OWASP Gen AI Security Project on December 10, 2025. Its entries are coded ASI01 to ASI10, from Agent Goal Hijack through to Rogue Agents.
Who publishes it and when was it released?
The list is produced by the OWASP Gen AI Security Project through its Agentic Security Initiative, which is where the ASI prefix comes from. It was released on December 10, 2025, for the 2026 cycle, after more than a year of research and review involving over 100 security researchers and practitioners. It sits alongside, and does not replace, the OWASP Top 10 for LLM Applications, which addresses model-level and prompt-level risk. Note that OWASP also runs a separate Agentic Skills Top 10 project, so it is worth checking which list a given document refers to.
What are the ten risks?
ASI01 Agent Goal Hijack, where an attacker manipulates the agent's objectives through content it reads. ASI02 Tool Misuse and Exploitation, where legitimate tools are chained or invoked in unintended ways. ASI03 Identity and Privilege Abuse, where an agent holds more permission than its task needs or borrows a user session. ASI04 Agentic Supply Chain Vulnerabilities. ASI05 Unexpected Code Execution. ASI06 Memory and Context Poisoning. ASI07 Insecure Inter-Agent Communication. ASI08 Cascading Failures. ASI09 Human-Agent Trust Exploitation. ASI10 Rogue Agents.
How is this different from LLM security?
Prompt-level security asks what the model says. Agentic security asks what the system does. An agent reads untrusted content, decides its own next step, calls tools and changes state in other systems, so the blast radius of a successful attack is operational, not conversational. ASI01 illustrates the shift: a malicious instruction buried in a document or web page the agent retrieves can redirect its goal, and no amount of output filtering catches that, because the harmful outcome is an action the agent takes, not text it returns.
How does it connect to AI governance?
Most of the ten are governance failures as much as engineering ones. Identity and privilege abuse is a permissioning decision. Rogue agents and cascading failures are questions of what an agent is allowed to do without human confirmation and what happens when several agents interact. Human-agent trust exploitation is about how much authority an interface implies the agent has. Controls that address these live in the approval and permission layer, which is why the list has become a useful spine for agentic governance policy and not only for security review.
How should teams use it?
Treat it as a checklist at two moments. At intake, when an agentic use case is proposed, work through the ten and record which apply and what control answers each one. At review, use it to structure red-teaming, since several entries describe attacks that only appear when the agent is exercised against hostile input. Mapping the ten to an existing control framework, whether that is the NIST AI RMF or ISO/IEC 42001, avoids running agentic security as a separate program from the rest of AI governance.
Real world example:
A support team deploys an agent that reads customer emails, looks up account records and issues refunds. Working through the list at intake, the team finds three live exposures. ASI01 applies because a customer can put instructions in an email the agent will read, so untrusted content is separated from instruction context. ASI03 applies because the agent was given the same database role as a human administrator, so its permissions are narrowed to the specific records and operations it needs. ASI02 applies because the refund tool accepts an arbitrary amount, so a value cap and a human confirmation step above that cap are added. The controls are recorded against the use case, giving the security reviewer and the auditor the same evidence.
