This article is a deep-dive from JudyAI Lab — an AI engineering playbook series with 100+ published guides, 5,000+ weekly readers across 60+ countries, focused on the practical side of running AI agents, trading systems, and content pipelines in production.

The OWASP GenAI Security Project released a new list in 2026—Top 10 for Agentic Applications [Source: https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/]. This isn’t a minor upgrade to the traditional Top 10; it’s a brand-new framework specifically made for AI Agent systems, peer-reviewed by industry expert communities [Source: https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/].

The ASI01 through ASI10 naming follows a different logic from the original LLM Top 10—ASI01 (Agent Goal Hijack) directly combines prompt injection (former LLM01) and excessive agency (former LLM06) [Source: https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/], because an Agent’s multi-step autonomous execution amplifies single-response attacks to a completely different level.

Why Agents Need Their Own List

Traditional OWASP Top 10 was designed for web apps, and LLM Top 10 later filled in the risks for single-turn inference. But Agents are different—they call their own tools, remember what happened before, and accumulate state across tasks.

Stack these capabilities together, and the attack surface becomes completely different.

Compare: doing prompt injection on a chatbot, worst case is it spits out one reply it shouldn’t. But doing goal hijack on an Agent, it might then run ten steps, transfer money, change settings, integrate with downstream systems—and each step looks like “executing a task,” so from the logs you can’t tell where it started going off track.

Compared to LLM Top 10, ASI07 (Inter-Agent Trust Exploitation), ASI08 (Cascading Failures), and ASI10 (Rogue Agents) focus more on horizontal and systemic risks specific to multi-agent scenarios [Source: https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/], because these scenarios simply don’t exist in the single-turn inference world.

ASI01–ASI10 in One Line Each

  • ASI01 Goal Hijack: Attackers rewrite what the Agent is actually pursuing
  • ASI02 Tool Misuse: Legitimate permissions being used for the wrong thing
  • ASI03 Excessive Permissions: Agent exceeds its original authorization scope
  • ASI04 Agentic Supply Chain: Third-party Agent, tools, plugins, model sources themselves are compromised
  • ASI05 Unexpected Code Execution: Agent triggers code paths it shouldn’t execute when parsing input
  • ASI06 Memory Poisoning: Planting poison into long-term memory
  • ASI07 Inter-Agent Trust Exploitation: Horizontal attacks in multi-agent systems
  • ASI08 Cascading Failures: One Agent errors out, drags the entire system down along the chain
  • ASI09 Human-Agent Trust Exploitation: Agent exploits human trust, leading users to make wrong decisions
  • ASI10 Rogue Agents: Compromised or runaway Agent operating within the system

Check the official OWASP documents for full definitions and English original text [Source: https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/].

Deep Dive: What Each One Looks Like and Why They’re Hard to Stop

ASI01 Goal Hijack’s most common attack path is hiding malicious instructions in data sources the Agent must read—crawled web pages, received emails, user-uploaded files. Once the Agent reads them in, those instructions compete with the original system prompt for priority. Multi-step execution amplifies the impact: a single-turn LLM error is one wrong sentence; an Agent error is the entire subsequent chain gone wrong. Traditional LLM defenses can’t stop it because this comes in through “data” and looks like legitimate input.

ASI02 Tool Misuse is about “legitimate but shouldn’t.” Agent has permission to query the database, fine; but attackers trick it into querying data that doesn’t belong to this task—permissions check passes, action completes, and from the system’s perspective there’s no anomaly. The key defense is context checking before tool calls, not just permission checking—the same API call should have different logic for “customer service task” vs. “data exfiltration.”

ASI03 Excessive Permissions is related to ASI02 but different: ASI02 uses existing permissions for wrong things, ASI03 is the Agent actively acquiring permissions it shouldn’t have. Common paths include: self-escalation (tricking the system into issuing admin tokens), lateral movement (using response from tool A to deduce credentials for tool B), escalation chains. RBAC can’t hold this because each individual step looks legitimate—it’s the accumulation that exceeds original authorization.

ASI04 Agentic Supply Chain brings npm/pypi supply chain attacks to the Agent world. Third-party Agents, plugins, MCP servers, pre-trained model weights, prompt template libraries—any component entering your stack is an attack surface. Recent waves of PyPI typosquatting poisoned packages, backdoored models on Hugging Face, malicious MCP servers Tricked into being installed by developers—all fall under this. SBOM must expand to include “Agent components.”

ASI05 Unexpected Code Execution is especially dangerous because Agents often write code and run it themselves: generate SQL then execute, generate Python then eval, generate shell then subprocess. Attackers induce prompts that make the Agent write code containing shell injection / SQL injection / path traversal, then have the Agent run it itself. Sandbox, allowlists, and escaping before template rendering are all required.

ASI06 Memory Poisoning is a unique risk for long-term memory Agents. Attackers plant fake memories in, and days later when the Agent reads them back, it treats the fake stuff as “facts it learned before.” This one is particularly tricky because there’s a long gap between poisoning and usage, making post-incident root cause analysis extremely difficult. RAG systems, vector databases, and knowledge graphs are all potential contamination points.

ASI07 Inter-Agent Trust Exploitation only happens in multi-agent systems. Agent A trusts Agent B’s response, B trusts C—attackers compromise any node in the chain, and all downstream take fake data without knowing. Lateral attacks were called lateral movement in traditional microservices, but in the Agent world they’re worse—because trust between Agents is usually implicit in prompt design, without clear boundaries.

ASI08 Cascading Failures is also a chain problem like ASI07 but with a different cause: ASI07 is malicious, ASI08 is error propagation. One Agent gives wrong data due to hallucination, downstream Agent takes it as truth, passes it along for 5 more steps, and the entire workflow has completely departed from reality. Circuit breakers, confidence scoring, and cross-validation are necessary mitigations.

ASI09 Human-Agent Trust Exploitation goes the other way—Agent uses human trust to do bad things. Common tactics include faking urgency (“click this now or something bad will happen”), social-engineering persuasion, packaging malicious content as the Agent’s “suggestion” so people accept it without thinking. When humans view the Agent as a neutral tool, the attack surface is biggest. UX design needs friction layers—important actions require human two-step confirmation.

ASI10 Rogue Agents is a new threat for multi-agent systems. An Agent gets compromised or planted, infiltrates the team as a normal member, sends tasks, changes settings, reads others’ memories. Traditional zero trust needs redesign in the Agent world—the subject of identity verification isn’t a person, it’s behavior patterns. Anomaly detection needs to upgrade from “this account’s behavior” to “this Agent’s decision trajectory.”

From Principles to Engineering Implementation

OWASP gives you categories and principles—you’ve got to do the engineering yourself. Here are common implementation directions mapped to ASI items.

For ASI04 (Agentic Supply Chain), third-party Agents, plugins, and model sources all need to go into supply chain management—pin versions, verify source signatures, scan manifests in CI—this follows the same approach as traditional SBOM, just swapping the object from npm packages to Agent components.

For ASI05 (Unexpected Code Execution), input parsing must assume malicious inputs will try to trigger eval, template injection, file system access. Anything that will be dynamically executed by the Agent (generated code, generated SQL, generated shell) must first go through sandbox or allowlist checking, not handed directly to runtime.

For ASI06 (Memory Poisoning) and ASI08 (Cascading Failures), knowledge base writes need source tagging and trust weight limiting; every write to vector database must leave trace—who wrote it, what task, with what command. When something goes wrong, you can trace back the causal chain, and also can limit error propagation downstream when an Agent starts spewing wrong data.

For ASI02 / ASI03 (Tool Misuse, Excessive Permissions), every Agent is born with a boundary config—what tools it can use, what downstream it can call, what resources it can access. Requests outside the boundary get rejected outright, not left for the Agent to decide.

For ASI04-derived resource risks, rate limiting is a must—limit how many external API calls each Agent can make per minute, preventing task loops from blowing through quota and also blocking the path where attackers use infinite calls to overwhelm the service. This layer is usually designed together with the ASI02/03 boundary config above.

Three Things Developers Can Do Right Now

Treat all external source content as “data, not instructions.” Web fetches, user uploads, external API responses—anything entering the Agent context goes through sanitize first, then into the main flow. This addresses both ASI01 and ASI05.

Add a layer of context checking before tool calls, not just permissions. The same API call should have different logic depending on task context—RBAC alone can’t block attacks like ASI02.

Memory systems absolutely need trace. Write source, write task, write time—missing any of these and you’ll have zero visibility into root causes after incidents, and both ASI06 and ASI08 will exploit this gap.

The most valuable part of OWASP’s list isn’t really the ten risks themselves—it’s telling you that the security model for Agent systems is different from what you knew before.