AI and Agent Security

The OWASP Top 10 for Agentic Applications, Explained in Practice

By CyberSec42 Research · Updated 2026

On 9 December 2025 the OWASP GenAI Security Project published the OWASP Top 10 for Agentic Applications 2026, with the identifiers ASI01 to ASI10. It is the first broadly reviewed reference for the risks that appear once an AI system does more than answer: it plans, calls tools, remembers things, and talks to other agents. It complements the OWASP MCP Top 10: the MCP list describes the server at the seam, this one the agent itself. This guide takes each of the ten classes and adds practical depth: what goes wrong at the core, how you test for it, and which structural countermeasure holds.

Why agentic systems need their own Top 10

A chatbot returns text. An agent acts: it breaks a goal into steps, calls tools with real permissions, writes results into a memory, and hands off to other agents. Three things that people used to control move into an automatic loop: the decision about what to do next, the execution with production credentials, and the memory the next step relies on. Each of these becomes an attack surface, and none of them is covered by a classic web or server checklist. The overview below stays deliberately at the class level and names no specific vulnerable products.

The ten risk classes in detail

ASI01. Agent Goal Hijack

An attacker rewrites the agent's goal or plan without ever having direct access. The lever is usually untrusted content the agent reads along the way: a web page, a ticket, an email, a file. Instructions hidden inside it merge with the actual task, and the agent suddenly pursues a foreign goal with the operator's permissions. This is the agentic form of indirect prompt injection, but more dangerous, because it ends in an action, not just an answer.

Test: Can content from a tool response change the task at hand? Is the original instruction separated from material read later? Fix: strictly separate and label the system task and untrusted data, check the plan against the original goal, require confirmation for steps that change the objective.

ASI02. Tool Misuse and Exploitation

The agent invokes a legitimate tool in a way it was not intended for: a search tool becomes data exfiltration, a file tool writes outside the working directory, an API tool drives bulk actions. The tool itself is not broken; the line between allowed and harmful use is simply never enforced. The more tools an agent has, the larger the number of combinations nobody considered at design time.

Test: Is an allowed invocation defined for every tool, and is that enforced? Can a chain of harmless calls produce a harmful effect? Fix: scope each tool tightly to its purpose, validate parameters server-side, cap rates and volumes, explicitly block dangerous combinations.

ASI03. Identity and Privilege Abuse

The agent acts with an identity or with permissions it is not entitled to: it shares a service account with too much access, inherits the calling user's rights without a fresh check, or escalates through a step that does not repeat authorization. The underlying pattern is shared with BOLA and IDOR from the web world: access to an object without an ownership check, only here a machine in the loop makes the requests.

Test: Does the agent act under its own tightly scoped identity? Is every sensitive action authorized per call against the real user? Fix: give each agent and each tool a minimal identity of its own, check permissions per step rather than once at the start, short-lived tokens, deny by default.

ASI04. Agentic Supply Chain Vulnerabilities

An agent is rarely alone: it pulls frameworks, tool definitions, plugins, prompt templates, and model artifacts from third-party sources. Any of these components can be compromised or tampered with, and a poisoned building block acts deep in the loop, often without a trace. A manipulated tool description alone is enough to steer the agent's behavior, long before any code even runs.

Test: Where do tools, templates, and models come from, and are they versioned and reviewed? Can an external definition enter the system unchecked? Fix: record provenance and verify integrity, pin versions, review tool definitions and templates like code, lock out untrusted sources.

ASI05. Unexpected Code Execution

The agent or its sandbox runs code an attacker controls. This happens through a code-interpreter tool, through a sandbox that is not one, or through a sink like eval, a subprocess, or unsafe deserialization that a tool argument reaches. These are the sharpest severities in the catalog, because a single step leads to full host compromise. The pattern is always the same: untrusted input meets a powerful interpreter.

Test: Can agent-controlled input reach a shell, an interpreter, or a deserializer? Is the sandbox truly isolated, with no network? Fix: never hand agent input to a shell, use real isolation with resource and network limits, use a real parser instead of eval() for expressions, deny by default for execution.

ASI06. Memory & Context Poisoning

Agents remember things: in a short-term context, in a vector database, in shared state between runs. If that memory is filled with manipulated content, it silently misleads later steps, even long after the original attack. Shared memory across users or sessions is particularly delicate: a poisoned entry then affects everyone who retrieves it later.

Test: Does untrusted content land in persistent memory unchecked? Is memory isolated per user and per task? Fix: carry provenance and a trust level on every entry, separate memory per context, validate what may enter memory, expire sensitive entries.

ASI07. Insecure Inter-Agent Communication

In multi-agent systems, agents talk to each other, delegate tasks, and exchange results. If those messages are neither authenticated nor integrity-protected, they can be spoofed, replayed, or injected. An agent then mistakes a planted message for a legitimate instruction from a partner and acts on it. This is the agentic counterpart to unprotected machine-to-machine communication.

Test: Are messages between agents authenticated and protected against replay? Does an agent check who an instruction really came from? Fix: sign every agent message and verify its origin, prevent replay with a nonce or timestamp, make trust between agents explicit rather than assumed.

ASI08. Cascading Failures

An error or compromise in one agent fans out across the system. Because agents trigger and trust each other, a local problem becomes a chain: a wrong result is passed on as truth, a loop fires uncontrolled, or a compromised agent drags the next ones with it. Without breaking points, there is no place where the cascade stops.

Test: Are there boundaries where one agent's error is stopped? Can feedback between agents run without limit? Fix: circuit breakers and hard limits per agent and per chain, validate intermediate results instead of trusting blindly, contain and log failures, halt when in doubt.

ASI09. Human-Agent Trust Exploitation

People trust an agent's fluent, confident output too quickly and grant approvals they should not. An attacker exploits this: the agent presents a manipulated action as harmless, hides a side effect, or obtains approval for something a person would reject on a closer look. The weakness sits at the interface, not in the code.

Test: When approving, does the human see what actually happens, including side effects? Are risky actions marked as such? Fix: present consequential actions clearly and in full, require explicit, friction-aware confirmation for destructive steps, never hide actions in the background.

ASI10. Rogue Agents

An agent operates outside policy, through a design flaw, through drift over time, or because it was compromised. It does things nobody ordered, and because it is part of the system, that goes unnoticed for a long time. This class is the sum of the others: it describes the state in which an agent no longer does what it was built for, and nobody notices, because no component continuously checks its behavior against the intent.

Test: Is each agent's behavior continuously checked against its allowed role? Is there an emergency stop? Fix: give each agent an explicit role and boundary, monitor behavior against that boundary, alert on deviation, keep a reliable kill switch ready.

From a checklist to defensible proof

Knowing a class is not the same as knowing the control holds in your system. Part of these classes is statically detectable, as a code pattern, an unsafe sink, or an over-broad permission. Another part lives in the design of roles, trust boundaries, and memory, and only becomes visible in the behavior of the agent loop, such as goal hijack or trust exploitation. Defensible security therefore needs both levels: a static check against defined invariants and a dynamic check that backs every single finding with an executed proof rather than merely assuming it.

Frequently asked questions