OWASP Top 10 for Agentic Applications (2026) Explained, With Controls

Why a separate list for agents

The OWASP Top 10 for LLM Applications (2025) covers risks of a language model answering a prompt. Agents add something new: they choose tools, call them in sequence, remember things between sessions and talk to other agents. A single injected sentence can now lead to an email being sent or a record being deleted. The agentic list builds on the LLM list and refers back to it where risks overlap.

Its central idea is least agency: in addition to least privilege, do not give a system more autonomy than the task needs. An automation that follows fixed steps is easier to secure than an agent that decides its own steps, so use agents where they add value, not everywhere. The second idea is observability: if you cannot see what an agent did, which tools it used and why, you cannot find or contain a problem.

The ten risks at a glance

ID	Risk	In one sentence
ASI01	Agent Goal Hijack	Content the agent reads changes what it is trying to do
ASI02	Tool Misuse and Exploitation	The agent uses a legitimate tool, within its rights, in a harmful way
ASI03	Identity and Privilege Abuse	Borrowed, inherited or cached credentials let the agent do more than intended
ASI04	Agentic Supply Chain Vulnerabilities	A third-party tool, MCP server, model, prompt or agent is malicious or tampered with
ASI05	Unexpected Code Execution (RCE)	Text turns into code that runs on a host or container
ASI06	Memory and Context Poisoning	False or malicious content is stored and shapes later decisions
ASI07	Insecure Inter-Agent Communication	Messages between agents are spoofed, altered or replayed
ASI08	Cascading Failures	One fault spreads across connected agents and systems
ASI09	Human-Agent Trust Exploitation	People approve what a persuasive agent recommends without checking
ASI10	Rogue Agents	An agent drifts from its intended function and keeps acting harmfully

ASI01: Agent Goal Hijack

Models cannot reliably tell instructions apart from the content they process. An email, a document, a web page, a calendar invite or a tool result can carry text that redirects the agent's goal or plan. This is the agentic version of prompt injection (LLM01:2025), with bigger consequences because the agent can act on it.

First controls: treat all content the agent reads as untrusted; limit tools so a hijacked agent can do little harm; require human approval for high-impact actions or for actions outside the original task; keep the system prompt and allowed actions under change control.

ASI02: Tool Misuse and Exploitation

Here the agent stays within its permissions but uses a tool in an unsafe way: it deletes data it was allowed to delete, calls an expensive API in a loop, or chains an internal lookup with an outbound email to leak a customer list. Manipulated tool descriptions (tool poisoning) also fall here. It extends Excessive Agency (LLM06:2025).

First controls: a least-privilege profile per tool (read-only where possible, no send or delete rights for a summarizer); egress allowlists; sandboxed execution; confirmation with a preview for destructive actions; a policy check between what the model proposes and what is executed.

ASI03: Identity and Privilege Abuse

Agents often run under a person's account or a broad shared key, pass all their rights to helper agents, keep credentials in memory, or act on authorization that was checked hours earlier. Any of these lets an attacker, or another user, use privileges that were never meant for the task.

First controls: a separate identity per agent; short-lived tokens scoped to one task; a fresh authorization check for each privileged step; human approval for privilege escalation; no inheritance of rights between agents. See AI agent identity and delegated permissions.

ASI04: Agentic Supply Chain Vulnerabilities

Agents load capabilities at run time: MCP servers, plug-ins, prompt templates, other agents found through a registry. Any of them can be malicious or altered. OWASP's examples include a fake MCP server on npm that copied every email to the attacker and an agent card that advertised false capabilities to attract sensitive tasks.

First controls: an inventory of AI components; curated sources and pinned versions; verification of signatures or hashes; review of tool and prompt changes; a way to disable a compromised component everywhere at once. See how to audit an MCP server.

ASI05: Unexpected Code Execution

Coding agents and agents with shell or interpreter tools generate and run code. Injected instructions or unsafe deserialization can turn that into code execution on the host or container, often outside normal security controls.

First controls: no eval of generated code in production; run code in isolated sandboxes, never as root, with limited network access; human approval for elevated runs; static checks before execution and monitoring during it.

ASI06: Memory and Context Poisoning

Agents keep conversation summaries, memories and retrieval indexes. If an attacker gets false or malicious content into them, every later session that retrieves it is affected, long after the original input is gone.

First controls: validate what is written to memory; separate memory per user and per domain; accept only authenticated sources for knowledge bases; record where each memory entry came from; keep snapshots so poisoned memory can be rolled back.

ASI07: Insecure Inter-Agent Communication

When agents coordinate over APIs, message buses or protocols such as A2A, weak authentication or integrity checks let attackers impersonate an agent, alter a message, or replay an old instruction.

First controls: encrypted channels with mutual authentication and per-agent credentials; signed messages; protection against replay; only approved protocol versions; verified agent registries and agent cards. See A2A security.

ASI08: Cascading Failures

Because agents plan, remember and delegate, one error (a hallucinated fact, a poisoned memory, a broken tool) can be passed along and amplified across agents until it reaches a privileged action. This entry is about the spread, not the original flaw.

First controls: design for failure with trust boundaries between agents; separate planning from execution with an independent policy check; checkpoints or human review for high-risk steps; rate limits and automatic pausing when unusual activity spreads quickly.

ASI09: Human-Agent Trust Exploitation

Agents sound confident and competent. People approve their recommendations without checking, and an attacker who controls the agent's input can steer a person into performing the harmful action themselves, which hides the agent's role in the audit trail.

First controls: explicit, specific confirmations for sensitive actions; tamper-proof logs of what the agent showed and recommended; clear visual warnings on high-risk recommendations; a way for users to report odd behaviour; training that covers this, which also serves AI literacy under the AI Act.

ASI10: Rogue Agents

An agent that has drifted from its purpose, whether after an attack or through emergent behaviour, may take actions that each look legitimate but together cause harm. The risk is losing control once the drift has started.

First controls: signed, immutable audit logs; trust zones that limit what agents can reach; monitoring of behaviour against a baseline; a kill switch that revokes credentials and stops the agent at once; a tested way to restore it from a trusted state.

Where to start

For a company that uses agents rather than builds them, five steps cover most of the list:

Inventory every agent, its tools, its data and its credentials (ASI03, ASI04).
Cut tools and permissions to what each task needs, and give each agent its own identity (ASI02, ASI03).
Require human approval for actions that send data out, pay, delete or change access (ASI01, ASI02, ASI09).
Log every tool call and keep a tested kill switch (ASI08, ASI10).
Vet third-party MCP servers, plug-ins and agent providers before use (ASI04, ASI07).

Check one agent now. The free AI Agent Risk Calculator asks 20 questions about an agent's capabilities and controls, scores the risk and flags dangerous combinations. It runs in your browser.

How the list connects to EU rules

The OWASP list is a technical reference, not a legal standard, but it is a practical way to show that agent risks were considered. Under NIS2, the risk analysis, supply chain and access control measures in Article 21(2) apply to agents like any other system. Under DORA, agents and their providers belong in the ICT risk management framework and third-party register. Under the GDPR, Article 32 requires security appropriate to the risk, and a DPIA is often needed when an agent processes personal data at scale.

Turn the list into controls. The AI Agent Governance Pack ($49) has an agent use policy, a delegation and permissions matrix, a risk assessment workbook and an incident playbook. The Agent Security Bundle ($79) adds the MCP Security Audit Kit and the Vendor Security Pack.