OWASP Agentic ASI Top 10: Risks and Practical Controls
The OWASP Agentic ASI Top 10 (2026) is a framework that lists the ten most critical security risks specific to agentic AI systems. The older OWASP LLM Top 10 covers risks to language models; the Agentic ASI list covers the brand-new attack surface that opens up once you give those models tools, memory, and the freedom to act. This walkthrough goes through all ten, with a practical fix for each.
Why a separate framework for agents
The OWASP LLM Top 10 and Agentic ASI categories overlap. Agent workflows add tool execution, persistent memory and delegated actions, so a security review must follow the full action path as well as the text entering and leaving the model.
The ASI categories provide a structure for reviewing agentic risks. They help teams connect a possible failure to controls and evidence; they are not a ranking of incident frequency in a particular deployment.
Figure: Map risks to the agent boundaries where controls are applied: task intent, identity, tools, memory, peer exchange and human oversight.
ASI01 — Goal hijack
An attacker hijacks the agent’s objective so it chases their goal instead of the user’s. This usually shows up as prompt injection hidden in retrieved content — a document the agent reads contains instructions that quietly override its task. The agent thinks it’s still helping the user; it’s actually running the attacker’s plan.
Mitigation: inspect untrusted inputs for prompt injection, limit capabilities, and authorize each governed tool action against the caller and target. These layers reduce exposure but do not guarantee detection of every injection.
ASI02 — Tool misuse
The agent uses a legitimate tool in a harmful way it was never meant for. A file-read tool gets pointed at /etc/passwd. A database tool gets a query with a destructive side effect. The tool is allowed; the specific use is the attack.
Mitigation: tool tiering with per-tool policies — allowed domains, allowed identities, restricted actions — plus a tool integrity engine that flags when a call’s arguments stray from the tool’s normal behavior.
ASI03 — Identity and privilege abuse
The agent runs with more privilege than the task needs, or an attacker bumps up its effective identity. A support agent that can read any customer’s records — not just the one in the current ticket — is a standing ASI03 risk: one injection away from mass data access.
Mitigation: ABAC operands that tie decisions to agent risk level, data class, and namespace; per-virtual-key budgets and scopes; least-privilege identity resolution.
ASI04 — Supply chain
A tool, model, or dependency in the agent’s supply chain gets compromised. The classic move: an MCP tool is silently re-described — same name and interface, but its description (which the model reads) now carries malicious instructions. Or a typosquatted tool poses as a legitimate one.
Mitigation: inventory discovered tools, review their definitions, pin approved contracts and investigate fingerprint drift. A CycloneDX AIBOM can document the recorded inventory and its review state.
ASI05 — Unexpected remote code execution
The agent gets tricked into running code it shouldn’t — through a code-execution tool, a sandbox escape, or a payload that reaches an interpreter. Agents that can run code are especially exposed.
Mitigation: code-execution detection in the guardrail layer, a sandbox verdict that boxes in risky payloads, and a hard wall between the agent’s reasoning context and any execution environment.
ASI06 — Memory and context poisoning
An attacker plants false information in the agent’s memory or retrieval corpus so it resurfaces later as trusted context. The poison goes in once and keeps coming back, so the damage compounds over time. Think of it as the agentic version of stored XSS.
Mitigation: inspect retrieved passages with RAG trust checks, review low-trust sources and control memory-write access. Coverage depends on the sources and operations routed through those checks.
ASI07 — Insecure inter-agent communication
In multi-agent systems, one agent’s output becomes another’s input. If that channel isn’t secured, a compromised agent can inject instructions into its peers — and the trust agents place in each other becomes the attack vector.
Mitigation: MCP gateway policies checked on both inbound and outbound tool calls, per-tool allowed-identities so an agent only accepts calls from authorized peers, and treating inter-agent messages with the same suspicion as user input.
ASI08 — Cascading failures
A failure or compromise in one agent or tool spreads through the system, getting bigger as it goes. One bad verdict bleeds into the decisions that depend on it; one overwhelmed tool triggers retries that overwhelm the next.
Mitigation: bound retries, isolate failures and define failure handling by operation. Canonical MCP execution requires an exact Allow; an unavailable authorization dependency does not become permission to run a low-risk tool.
ASI09 — Human-trust exploitation
The agent takes advantage of the human operator’s trust — dressing up a harmful action as routine, or burying a consequential step inside a long, plausible-looking sequence so the human waves it through.
Mitigation: an approval queue that shows the full context of each flagged action — inputs, outputs, the policy that triggered it, the principal chain — so humans review with the whole picture instead of rubber-stamping.
ASI10 — Rogue agents
An agent operates completely outside its authorized scope — an unregistered agent making decisions through your infrastructure, or a registered one that’s drifted far from its intended behavior. You can’t govern what you haven’t discovered.
Mitigation: use configured discovery and observed gateway traffic to identify unregistered agents, then review ownership and permissions. Unknown traffic outside that observation boundary remains a separate inventory gap.
The ten ASI categories aren’t independent — one sophisticated attack often chains several together. A supply-chain compromise (ASI04) enables tool misuse (ASI02), which lands a goal hijack (ASI01), kept alive through memory poisoning (ASI06). Defending against the list means defending the whole agentic execution path, not bolting on ten separate point solutions.
Review combined scenarios as well as individual ASI categories, and record which part of the execution path each control actually covers.
A shared control plane can make identity, authorization, review and activity easier to manage. Its coverage still depends on plan entitlement, workspace settings, supported integrations and whether traffic crosses the governed boundary.
How DeepintShield approaches this
DeepIntShield provides agent registration, workload identity, OpenFGA relationship authorization, optional context policy, MCP definition pinning and decision evidence. Use RAG and content guardrails alongside these controls where configured. Map each ASI scenario to the controls actually enabled for the workflow rather than assuming one feature covers every risk.
Frequently asked questions
What is the OWASP Agentic ASI Top 10?
The OWASP Agentic ASI Top 10 (2026) is a framework listing the ten most critical security risks specific to agentic AI systems — including goal hijack, tool misuse, identity abuse, supply-chain compromise, memory poisoning, and rogue agents.
How is the Agentic ASI Top 10 different from the OWASP LLM Top 10?
The LLM Top 10 covers risks to language models answering prompts. The Agentic ASI Top 10 addresses the new attack surface that opens when models are given tools, memory, and the autonomy to act — risks the LLM list was not designed to cover.
Can one attack involve several ASI categories?
Attacks often chain several ASI categories: a supply-chain compromise (ASI04) enables tool misuse (ASI02) that achieves goal hijack (ASI01), persisted through memory poisoning (ASI06). Defending requires securing the whole agentic execution path, not ten separate point fixes.
A simple example
A support agent may read a retrieved document and then call an MCP tool. Instructions hidden in the document can change its goal; a broad tool permission can then turn that change into a data leak. Treat the document as untrusted input and authorize the exact tool action and resource separately.
Use the ASI categories to organize a review, not as evidence that every attack is covered. In DeepIntShield, governed MCP execution needs an exact Allow when Agentic authorization is enabled. Discovery, content checks and human approvals each cover a different part of the workflow.
