The OWASP Top 10 for Agentic Applications 2026 is a peer reviewed list of the ten most critical security risks in AI systems that plan, remember, call tools, and act with delegated authority. Published on December 9, 2025 by the OWASP GenAI Security Project, it was built with more than 100 industry experts, researchers, and practitioners. Each risk carries an identifier from ASI01 through ASI10, where ASI stands for Agentic Security Initiative.
That is the definition. The more useful question is why a separate list was needed at all, because OWASP already maintains a Top 10 for Large Language Model Applications and most people assume an agent is just a chatbot with extra steps. It is not, and the gap between those two mental models is where the interesting failures live. Ask a chatbot to book a flight and it explains how. Give an agent the same instruction and it opens the browser, fills in the passenger details, and charges a card. Same underlying model, completely different consequences when something goes wrong.
A language model receives input and produces output. An agent has goals, credentials, tools, memory, and permission to chain actions across many steps without asking. Everything on this list follows from that change.
Why Do AI Agents Need Their Own Security List?
Because five properties of agentic systems break the assumptions that older security models were built on. Work through these before you touch the list of ten, because once the properties click, the ten risks stop looking like ten separate things to memorize and start looking like predictable consequences.
Autonomous decision making comes first. An agent plans and executes multi step tasks without a human approving each step, so a security failure at step two keeps compounding through steps three, four, and five before anyone notices. Tool integration comes next. Agents call APIs, query databases, and reach cloud services, and they often compose those tools dynamically at runtime rather than following a fixed path a developer reviewed. Persistent memory is the third. Agents carry context across sessions, which means something injected into memory on Monday can still be shaping decisions on Friday. Inter agent communication is the fourth, where agents send each other messages and delegate work, creating trust relationships that nobody explicitly designed. Emergent behavior is the last and the strangest, because complex interactions between agents can produce outcomes nobody programmed and nobody predicted.
An Analogy That Holds Up
Think about hiring a contractor to renovate your kitchen while you are out of town for two weeks. You hand over a key, a company credit card, and a written scope of work. The contractor can now enter your house, spend your money, bring in subcontractors you have never met, and make judgment calls you never explicitly authorized. All of that is exactly what you wanted when you hired them.
Now consider what could go wrong, and notice that none of it requires the contractor to be malicious. Somebody could slip a fake change order under your door and the contractor would follow it. Maybe the subcontractor is the actual problem. The contractor might read your scope of work in a way you did not intend and knock out a load bearing wall. Two weeks of accumulated notes and decisions could all trace back to one misunderstanding on day one. Every one of the ten OWASP categories is a version of one of those failures, translated into software.
Where the analogy breaks. A contractor knows when they are being asked to do something outside the job. An agent frequently cannot tell the difference between your instructions and text it happened to read in a document, because both arrive as language. That distinction is the root of the first risk on the list, and it is the single most important thing to understand about agent security.
What Are the 10 OWASP Agentic AI Risks?
Here is the complete list as OWASP publishes it, with the official identifier for each category. Read the table first, then read the sections underneath it, where the same ten risks are regrouped by what actually causes them.
Now set the numbering aside. Students who memorize ASI01 through ASI10 in order can recite the list and still fail to recognize any of these in a real system, which is the outcome I care about avoiding. Grouped by root cause, the ten collapse into four ideas.
Group One: The Agent Wants the Wrong Thing
Agent Goal Hijack (ASI01), Memory and Context Poisoning (ASI06), and Rogue Agents (ASI10) all describe an agent pursuing an objective other than the one you gave it. The three differ only in how the objective got corrupted and how long ago.
Goal hijack is the immediate version. OWASP breaks it into direct goal manipulation, where an attacker explicitly overrides the objective, and indirect instruction injection, where hidden instructions ride inside a document, a retrieved knowledge base article, an email, or the output of a tool the agent called. There is also recursive hijacking, where a modified goal propagates through the agent’s own reasoning chain, and cross context injection, where instructions planted in one context surface in another. The reason this works is not a bug anyone forgot to fix. Agents represent plans in natural language, and natural language arriving from a user and natural language arriving from a poisoned PDF look identical to the model.
Memory poisoning is the delayed version of the same problem. Long term memory stores get corrupted, malicious content gets inserted into context, reasoning state gets altered across sessions, and sensitive memory contents leak out. What makes this category worse than goal hijack is persistence. Clean up the poisoned document and the poison may already be sitting in the agent’s memory store, still influencing decisions weeks later.
Rogue Agents is the version where nobody attacked anything. OWASP lists goal drift, where the agent gradually wanders from its original objective, agent collusion, where several agents coordinate toward something nobody intended, reward hacking, where an agent optimizes a proxy metric instead of the real goal, and runaway autonomy, where an agent exceeds the boundaries it was designed to stay inside. Reward hacking should feel familiar to anyone who has ever written a KPI that got gamed by the team it was meant to motivate.
Group Two: The Agent Reaches the Wrong Thing
Tool Misuse and Exploitation (ASI02), Agentic Supply Chain Compromise (ASI04), and Unexpected Code Execution (ASI05) cover what happens between the agent and everything it touches.
Pay attention to how OWASP defines tool misuse, because the wording carries the lesson. The agent causes harmful side effects despite having valid permissions. Nothing was bypassed. The named patterns are recursive tool calls that loop until resources are exhausted, unsafe tool composition where individually harmless tools become dangerous in sequence, tool budget exhaustion from sheer volume of invocations, and cross tool state leakage where information moves between tool contexts that should have stayed separate. Traditional access control has no answer for this, since access control asks whether an action is allowed and every one of these actions is allowed.
Supply chain compromise looks like the software supply chain problem you already know, except the composition happens at runtime rather than at build time. OWASP calls out schema manipulation, description deception where a tool’s own description misleads the agent about what it does, permission misrepresentation, and registry poisoning. An agent that discovers and integrates tools dynamically is trusting a description written by whoever published the tool, which is a level of trust most organizations would never extend to a library in their build pipeline.
Unexpected code execution rounds out the group, covering agent generated code that runs without validation, direct shell command invocation, unsafe evaluation of dynamic expressions, and command injection through agent output. This is the most familiar risk on the entire list to anyone with an application security background, which cuts both ways. Familiarity helps you recognize it, and it also tempts teams into assuming their existing controls already cover it when those controls were written for code paths a developer approved.
Group Three: Nobody Knows Who Is Acting
Agent Identity and Privilege Abuse (ASI03) and Insecure Inter-Agent Communication (ASI07) are the identity problems, and they are where most production incidents actually start.
Identity abuse covers agent impersonation, cross agent trust abuse where implicit trust between agents gets exploited, identity inheritance where privileges get assumed through a chain of agents, and role bypass. An orchestration agent holding credentials for five downstream agents is a single point of compromise with the combined permissions of all six, and the audit log may show only the orchestrator’s identity on every action. Ask yourself who the actor was in that log entry, and whether your logging can even answer the question.
Insecure inter agent communication is one of three categories OWASP flags as having no real equivalent in the LLM Top 10. The named patterns are agent in the middle interception, message injection, and message spoofing where a forged message appears to come from a trusted agent. If that sounds like network security problems from twenty years ago, it should. Multi agent systems are building message buses without consistently applying the authentication, encryption, and integrity checks that any other message bus would require.
Study tip. If you are preparing for any security certification that touches AI systems, practice classifying incidents rather than reciting categories. Take a scenario, decide which ASI number applies, and then argue the case for a second category that could also fit. Most real incidents map to two or three at once, and exam questions built on this material will reward candidates who can explain why one classification fits better than another. Reciting the list in order will not.
Group Four: Small Problems Become Big Ones
Cascading Agent Failures (ASI08) and Human-Agent Trust Exploitation (ASI09) are about scale, and one of them is not a technical risk at all.
Cascading failures propagate through tool chains, agent dependencies, resource exhaustion, and broken trust chains. Anyone who has worked in distributed systems recognizes this immediately, along with the standard countermeasures of circuit breakers, bulkheads, and failure isolation. What makes the agentic version harder is that agents route around failures creatively. A well designed microservice fails fast when a dependency dies. An agent that cannot reach its usual tool may improvise a different approach nobody validated, which turns a clean failure into an unpredictable one.
Human-Agent Trust Exploitation is the one I would spend extra time on with any class, because it is the only category on the list where the vulnerable component is a person. OWASP names authority misrepresentation, misleading explanations that sound plausible and are wrong, overconfidence projection, and responsibility diffusion where accountability for an error gets deflected. Agents write fluently and never sound unsure, and humans reliably read fluency as competence. Security awareness programs spent two decades teaching people to distrust an email that sounds urgent. The next version of that training has to teach people to distrust an answer that sounds certain, which is a considerably harder lesson because the answer is usually right, and the times it is wrong look exactly the same.
How Is This Different From the OWASP Top 10 for LLM Applications?
The OWASP Top 10 for LLM Applications treats the model as something that receives input and produces output, covering risks like prompt injection and training data poisoning at the model layer. Agentic risks pick up where that stops, covering what happens once the model becomes an actor with goals, credentials, tools, memory, and multi step autonomy. Neither replaces the other, and a team building agents needs both.
Most agentic risks are amplifications of an LLM risk rather than something unheard of. Agent Goal Hijack combines prompt injection with excessive agency, but multi step autonomous execution stretches the blast radius far beyond a single bad response. Three categories are new classes with no LLM equivalent: inter agent communication (ASI07), cascading failures (ASI08), and rogue agents (ASI10). Those three exist only because agents talk to each other, depend on each other, and keep running.
A practical rule for which list applies. If your system is a chatbot or a retrieval augmented generation setup with no tool use and no multi agent coordination, the LLM Top 10 covers you and the Agentic list adds nothing. The moment the system starts taking actions on behalf of a user, you need both.
What Does Least Agency Mean?
Least agency means granting an agent only the minimum autonomy required to complete a safe, bounded task. It runs through the 2026 list the way least privilege runs through traditional access control, and the relationship between the two is the most useful thing to take away from the whole document.
The older principle, least privilege, has always been a question about reach, meaning which resources an identity is permitted to touch. Least agency asks something that question never had to cover, which is how much latitude the identity carries once it is already inside. An agent can sit comfortably within its permissions and still cause damage by chaining allowed actions in an order nobody anticipated. Ask both about every agent you deploy, because one that passes the first test can still fail badly on the second.
Anyone who has worked through NIST 800-207 and zero trust theory will find the reasoning familiar. Verify explicitly, assume breach, and grant the narrowest access that still lets the work happen. Least agency extends that thinking to autonomy itself, treating decision making authority as something to be scoped and revoked rather than something an agent simply has.
How Do You Start Applying the OWASP Agentic Top 10?
Start with an inventory, because most organizations cannot yet answer how many agents are running in their environment. Any assessment built on an incomplete inventory produces a false sense of coverage.
The Inventory Problem Starts Below the Threshold
A student in a recent class described something that has stayed with me. One of the help desk technicians on his team had used AI to build a small app for tracking his day. It was a useful tool that he put together on his own initiative, and no approval process was involved because none seemed necessary for a personal productivity script. To make it work he had been pasting in the details of what he actually worked on, which for a help desk technician means system specifications, hostnames, configurations, and a running picture of the environment he supports. The app itself had no security worth the name. Nobody had reviewed it and nobody outside his own desk knew it existed.
Notice that nothing in that story is an agent. It makes no plans and calls no tools. There are no credentials attached to it, and it coordinates with nothing. By the threshold described earlier in this article, the OWASP agentic list does not apply to that app at all. It is still a serious exposure, and it is sitting in an inventory that nobody is keeping.
Now add one feature to it. Let the app open tickets on his behalf so he stops doing that part manually. That single change hands it a credential, gives it the ability to act inside a production system, and turns a memory store full of environment details into something an attacker would very much like to reach. Four or five of the ten risks arrive at once, and they arrive inside a tool that was never reviewed because it began life as a personal convenience.
Which is why I would open an inventory with a conversation rather than a scan. Scans find the agents that were deployed through a platform. Asking people what they have built themselves finds the rest, and the ones people build themselves tend to be the ones holding data nobody sanctioned them to hold.
Once the inventory exists, the list becomes useful for threat modeling, red team scoping, and runtime monitoring design. Governance teams get value from it too, since the categories give auditors and engineers a shared vocabulary for describing the same failure. Organizations working toward an AI management system under ISO 42001 can use ASI classifications as technical evidence underneath the higher level control objectives, which is generally an easier conversation than starting from the standard and working down.
Will the OWASP Agentic Top 10 Appear on Certification Exams?
Not yet by name on the major vendor neutral exams, and I would be cautious about anyone promising otherwise. Exam blueprints move slowly, and a framework published in December 2025 has not had time to work through the objective development cycles at the certification bodies.
The underlying concepts are a different story. AI security content is being absorbed into existing security certifications right now, and the ideas here (delegated authority, prompt and instruction injection, autonomy boundaries, human oversight of automated decisions) are already showing up as scenario material even where the ASI vocabulary is not. What carries a candidate through those questions is understanding why an agent cannot separate instructions from data. Ten memorized labels do nothing, and that has been the pattern with every framework that works its way into exam content.
On the governance side, the connection is more direct. If you are working through AI governance fundamentals or mapping controls across the EU AI Act, the NIST AI Risk Management Framework, and ISO 42001, the ASI categories slot in as the technical layer beneath those frameworks. Governance frameworks tell you what outcomes to achieve. This list tells you what specifically goes wrong when you do not, and our breakdown of how AIGP maps across those three frameworks covers the governance side in detail.
Frequently Asked Questions
What does ASI stand for in the OWASP agentic risk list?
ASI stands for Agentic Security Initiative, the OWASP GenAI Security Project initiative that produced the list. Each of the ten risks carries an ASI identifier, running from ASI01 for Agent Goal Hijack through ASI10 for Rogue Agents.
When was the OWASP Top 10 for Agentic Applications published?
The OWASP GenAI Security Project published the 2026 edition on December 9, 2025. It was developed with more than 100 industry experts, researchers, and practitioners, and it is the first globally peer reviewed risk taxonomy built specifically for autonomous agents rather than for chat style language models.
Is the agentic list a replacement for the OWASP Top 10 for LLM Applications?
No. The LLM list covers model layer risks where the model receives input and returns output. Agentic risks begin once that model has goals, credentials, tools, and the autonomy to chain actions. Teams building agents should assess against both.
Which agentic risks have no equivalent in the LLM Top 10?
Three categories have no counterpart at all. Insecure Inter-Agent Communication (ASI07) exists because agents exchange messages with each other. Cascading Agent Failures (ASI08) exists because agents depend on each other. Rogue Agents (ASI10) exists because agents keep running and can drift from their original objectives over time.
What is the difference between least privilege and least agency?
Least privilege limits which resources an identity can reach. The newer idea, least agency, is about how much an agent gets to decide for itself once it is already inside those boundaries. An agent operating fully inside its permissions can still cause harm by chaining allowed actions in an unanticipated sequence, so both constraints are needed.
Does my chatbot need the agentic Top 10?
Probably not. A chatbot or retrieval augmented generation system with no tool use and no multi agent coordination is covered by the OWASP Top 10 for LLM Applications, and the agentic list adds little. The threshold is whether the system takes actions rather than only producing text.
How do I use the OWASP agentic list for compliance work?
Treat the ASI categories as technical evidence beneath a governance framework rather than as a compliance standard themselves. They pair well with control objectives in ISO 42001, the NIST AI Risk Management Framework, and the EU AI Act, but compliance is determined by the framework or regulation, not by the OWASP list.
VP of Educational Services | Training Camp
Jeff Porch is the VP of Educational Services and Operations at Training Camp, where he leads the company's educational initiatives with a focus on accelerated learning and student success. Beyond overseeing curriculum development, Jeff serves as the lead course designer for Training Camp's CompTIA Security+ program, one of their most popular offerings. He is deeply involved in the instructional side of the business — developing certification courses, training instructors, and ensuring that complex IT concepts are delivered in ways that maximize retention and minimize time-to-certification.