OWASP Top 10 for Agentic Applications

Last Updated on July 2, 2026 by Arnav Sharma

Security teams that spent two years hardening chatbots are now staring at a different problem. The OWASP Top 10 for Agentic Applications, released for 2026 by the OWASP GenAI Security Project, exists because autonomous AI systems break the assumptions that traditional application security and even the OWASP Top 10 for LLM were built on. An agentic AI system does not just answer a prompt. It plans, calls tools, holds memory, talks to other agents, and acts with real credentials across live workflows. That shift turns a contained model risk into an active attack surface, and this list of ten critical security risks is the framework most teams will use to get ahead of it. It is the clearest single reference for the AI risks that come with securing agentic systems built on large language models.

This guide walks through all ten entries, ASI01 to ASI10, with the attack vector and the mitigation for each. It also covers how agentic risk differs from a traditional LLM application, and where to start if you are securing your first AI agent in production.

What is the OWASP Top 10 for Agentic Applications?

The OWASP Top 10 for Agentic Applications is a globally peer-reviewed framework that identifies the most critical security risks facing autonomous and agentic AI systems. It distils a broad body of OWASP GenAI Security guidance into a single operational list of 10 risks, aimed at builders, defenders, and decision-makers who need a clear starting point rather than a research paper. These are the top 10 risks for agentic AI applications as the OWASP Gen AI Security Project frames them for 2026.

The framework was announced during Black Hat Europe 2025 alongside the OWASP Agentic Security Summit, and the published version carries a 2026 label. Each risk is given an ASI identifier (ASI01 through ASI10), which is how you will see practitioners reference individual entries in tooling, threat models, and vendor mappings. The ten top 10 entries function as an OWASP guide to the unique security challenges that autonomous systems introduce.

Who built it and why it exists

The list is the product of the OWASP Agentic Security Initiative, part of the wider OWASP GenAI Security Project. It was developed through collaboration with more than 100 industry experts, researchers, and practitioners, then put through open peer review before publication. That community process matters: it means the ten entries reflect observed behaviour in real deployments, not a single vendor’s threat catalogue.

OWASP first flagged the gap in 2023, when it became clear that traditional application security guidance was not addressing the new class of generative AI threats. The OWASP Top 10 for LLM applications answered part of that. The agentic list answers the part that LLM-centric guidance could not, because autonomy introduces failure modes a static model never had.

Why agentic systems need their own list

A traditional LLM application takes input, returns output, and stops. An agentic AI system is different in four ways that each open new risk:

• Autonomous decision-making. The agent independently determines the steps to reach a goal, so a single manipulated instruction can redirect an entire workflow.
• Persistent memory. Agents carry short-term and long-term memory across sessions, which can be poisoned and then trusted later.
• Tool and API access. Agents interact directly with external systems, turning a reasoning flaw into a real action with real consequences.
• Multi-agent coordination. Agents delegate to and trust other agents, so a compromise in one can cascade through the network.

These properties are why the OWASP GenAI Security Project treats agentic applications as a distinct category. If your system has none of these traits, the OWASP Top 10 for LLM remains the right reference. If it has any of them, the agentic list is the one that fits.

How agentic risk differs from the OWASP Top 10 for LLM

The two lists overlap, but they are not interchangeable. The OWASP LLM Top 10, the predecessor that put generative AI threats on the security map, covers single-turn model risk. The agentic top 10 risks extend that into autonomy. Prompt injection, for example, appears in both worlds. The difference is consequence. In a traditional LLM application, a successful prompt injection produces bad text. In an agentic system, the same injection can hijack a goal, trigger a tool, escalate a permission, or move money, because the model is wired to act.

The agentic list also adds risks that simply do not exist without autonomy. Insecure inter-agent communication, cascading agent failures, and rogue agents are all multi-agent or multi-step problems. They have no equivalent in the LLM top 10 because a single-turn model has nothing to delegate to and no chain to corrupt.

The practical takeaway: keep the OWASP Top 10 for LLM applications for your model layer, and layer the agentic list on top once your application starts planning and acting on its own. Each AI vulnerability the older list catches still applies; the agentic entries cover what it takes to secure AI agents that act autonomously.

The OWASP Top 10 for Agentic Applications: ASI01 to ASI10

Here is the full list, ordered as OWASP publishes it. The Top 10 for Agentic AI applications below is the complete set, and the “10 for Agentic Applications 2026” labelling you will see elsewhere refers to this same list. The table gives the fast version; the sections below give the attack vector and the mitigation for each.

Code	Risk	Primary attack vector
ASI01	Agent Goal Hijack	Malicious content alters the agent’s objective or decision path
ASI02	Tool Misuse and Exploitation	Agent is manipulated into misusing legitimate tools
ASI03	Identity and Privilege Abuse	Inherited or cached credentials are exploited
ASI04	Agentic Supply Chain Vulnerabilities	Tampered tools, models, or prompt templates compromise execution
ASI05	Unexpected Code Execution	Agent generates or runs attacker-controlled code
ASI06	Memory and Context Poisoning	Persistent corruption of memory or RAG stores
ASI07	Insecure Inter-Agent Communication	Spoofed, replayed, or tampered messages between agents
ASI08	Cascading Agent Failures	Small errors propagate and amplify across agents
ASI09	Human-Agent Trust Exploitation	Users over-trust a persuasive agent and approve harm
ASI10	Rogue Agents	Compromised or misaligned agents act harmfully while appearing legitimate

ASI01: Agent Goal Hijack

Goal hijacking is the headline risk for a reason. An attacker redirects an agent’s objective by planting malicious instructions in content the agent reads: a tool output, a retrieved document, an email, or an external page. Because the agent treats that content as part of its reasoning, a single poisoned input can quietly rewrite what the agent is trying to do.

Mitigation: treat all agent-consumed content as untrusted. Separate trusted instructions from retrieved data, validate tool outputs before they influence planning, and constrain the agent to a defined goal scope so it cannot silently adopt a new objective. Agent goal hijack is also where the principle of least agency starts: autonomy should be earned for a task, not granted as a default.

ASI02: Tool Misuse and Exploitation

Here the tools are legitimate, but the agent is talked into using them in harmful ways through prompt injection, misalignment, or unsafe delegation. A booking tool gets used to exfiltrate data, or a file tool gets pointed somewhere it should never reach.

Mitigation: scope every tool tightly, enforce per-tool permission boundaries, and require validation on high-impact actions. Tool misuse is contained by limiting what each tool can do, not by trusting the agent to use it well.

ASI03: Identity and Privilege Abuse

This is the entry most identity teams care about. Agents inherit user or system identities, often with high-privilege credentials, which creates openings for privilege escalation and unauthorised access. Common patterns include dynamic permission escalation, cross-system exploitation from weak scope enforcement, and shadow agents that inherit legitimate credentials.

The deeper problem is aggregation. An AI agent acts with the full authority of every key, token, and service account assigned to it, merging multiple permissions into one execution point. Confuse the agent and you inherit every credential it holds, which is why identity and privilege abuse sits at the intersection of the agentic list and non-human identity risk.

Mitigation: apply least privilege to every agent identity, prefer short-lived scoped credentials over standing ones, and make agent permissions discoverable and auditable. Treat each agent as its own non-human identity with the same scrutiny you give a service account.

ASI04: Agentic Supply Chain Vulnerabilities

The agentic supply chain includes tools, plugins, prompt templates, models, agent personas, and external servers. Any of them can be compromised: a malicious tool package executes hidden functionality, a tampered prompt template injects adversarial instructions, or a poisoned dependency returns corrupted data the agent then trusts.

Mitigation: vet and pin agent dependencies, scan tool and skill registries before install, and verify the provenance of prompt templates and models. Agentic supply chain vulnerabilities are managed the way you already manage software supply chain risk, extended to cover prompts and personas.

ASI05: Unexpected Code Execution

Agents that generate or run code or commands can be pushed into unsafe execution, opening the door to remote code execution, sandbox escapes, and data exfiltration. A DevOps agent that runs a generated script with a hidden command is a clean example of how this fails in production.

Mitigation: run agent-generated code in a strict sandbox, deny network egress by default, and require explicit approval before any generated command touches a real system. Code execution risk shrinks when the blast radius is contained before the code runs.

ASI06: Memory and Context Poisoning

Attackers corrupt an agent’s memory, embeddings, or RAG database so that bad information is stored and trusted later. This can happen gradually through repeated interactions, or by exploiting memory limits so the system never recognises an escalation in progress.

Mitigation: validate what enters long-term memory, segment memory by trust level, and periodically reconcile stored context against a trusted source. Context poisoning is defeated by not letting untrusted input write durable state unchecked.

ASI07: Insecure Inter-Agent Communication

In multi-agent systems, the channels between agents become a target. Attackers spoof identities, replay messages, forge false consensus, or plant misleading data that cascades through the network and influences collaborative decisions.

Mitigation: authenticate every agent-to-agent message, sign and verify inter-agent traffic, and reject unverifiable consensus. Insecure inter-agent communication is closed the same way you would secure any service-to-service channel, with mutual authentication and message integrity.

ASI08: Cascading Agent Failures

A small error in one agent propagates across planning, execution, and memory, then amplifies through interconnected systems. A single hallucinated API endpoint or false data point can accumulate in long-term memory and cause failures far from where it started.

Mitigation: add circuit breakers between agents, validate outputs at each handoff, and cap the depth of autonomous chains so one fault cannot cascade unchecked.

ASI09: Human-Agent Trust Exploitation

Modern agents are fluent and persuasive, which leads users to trust an agent’s apparent expertise without verifying its claims. An attacker exploits this by using a hijacked agent to talk a user into approving a malicious command or sharing sensitive data. The audited action looks like a legitimate human decision, while the manipulation stays invisible.

Mitigation: separate the agent’s conversation from the actual security boundary. Route consent and high-impact approvals through a universal login or out-of-band confirmation, never through the agent’s chat interface alone.

ASI10: Rogue Agents

A rogue agent is one that has been compromised or has drifted out of alignment, acting harmfully while still appearing legitimate inside a workflow. Examples include malicious workflow injection that impersonates an approval agent, or orchestration hijacking that reroutes transactions.

Mitigation: monitor agent behaviour against expected baselines, enforce strong identity on every agent in the workflow, and isolate orchestration so a single compromised agent cannot assume trusted roles.

Mapping the risks to mitigations

Most of these risks resolve to a small number of control families. This second view helps when you are assigning ownership across security, platform, and identity teams.

Risk	Core control	Primary owner
ASI01 Agent Goal Hijack	Input trust separation, goal scoping	AppSec
ASI02 Tool Misuse	Tool scoping and permission boundaries	Platform
ASI03 Identity and Privilege Abuse	Least privilege, scoped short-lived credentials	Identity
ASI04 Agentic Supply Chain	Dependency vetting and provenance	AppSec
ASI05 Unexpected Code Execution	Sandboxing, egress control	Platform
ASI06 Memory and Context Poisoning	Memory validation and segmentation	AppSec
ASI07 Insecure Inter-Agent Communication	Mutual authentication, message integrity	Platform
ASI08 Cascading Agent Failures	Circuit breakers, output validation	Platform
ASI09 Human-Agent Trust Exploitation	Out-of-band consent	Identity
ASI10 Rogue Agents	Behaviour monitoring, agent identity	Security operations

Two threads run through the whole list: identity and containment. Credential handling shows up in ASI03, ASI05, and ASI10. Containment of autonomy shows up in ASI01, ASI02, ASI07, and ASI08. If you fix those two foundations, you reduce exposure across the majority of the entries.

How to start applying the framework

You do not need to solve all ten risks at once. A workable sequence:

1. Inventory your agents and their credentials. You cannot secure what you cannot see. Map every agent, the tools it can call, and the identities and permissions it holds. This directly addresses ASI03.
2. Constrain autonomy and tool scope. Apply least agency and least privilege so each agent can only do what its task requires. This blunts ASI01, ASI02, and ASI05.
3. Harden inputs and memory. Separate trusted instructions from retrieved content and validate what reaches long-term memory. This addresses ASI06 and the goal-hijack path in ASI01.
4. Secure the supply chain and inter-agent layer. Vet dependencies and authenticate agent-to-agent traffic, covering ASI04 and ASI07.
5. Add monitoring and human checkpoints. Baseline agent behaviour and route consent out of band, closing ASI08, ASI09, and ASI10.

Run this against your highest-impact agent first, the one with the broadest credentials or the most autonomous reach, then extend the same controls outward.