OWASP shipped a dedicated Top 10 for autonomous agents in December 2025. Here is the full ASI01-ASI10 list, what each risk actually looks like in production, and the concrete control that shuts it down.
What the OWASP agentic AI Top 10 is and why it shipped now
The OWASP agentic AI Top 10 is a peer-reviewed list of the ten most critical security risks specific to autonomous AI agents, published by the OWASP GenAI Security Project on December 9, 2025 with input from more than 100 industry contributors. It is not a refresh of the older LLM Top 10. It is a separate threat model for systems that perceive, reason, and act in the world rather than just answer questions.
The distinction matters because the failure modes are different. An LLM that hallucinates produces bad text. An agent that hallucinates can call an API, move money, delete a table, or message your customers. As Palo Alto Networks framed the shift, the industry is no longer dealing with static models that answer questions but with agents capable of perception, reasoning, and autonomous action, where dynamic tool chaining and persistent memory defeat the static policies that secured earlier systems.
The timing is not accidental. In a Dark Reading readership poll, 48% of security professionals named agentic AI and autonomous systems the top attack vector heading into 2026, outranking deepfakes and passwordless adoption. Yet only about 34% of enterprises report AI-specific security controls, and Darktrace’s State of AI Cybersecurity 2026 found 92% of security pros concerned about AI agents while just 37% have a formal AI policy. The OWASP agentic AI list exists to close exactly that gap. (Figures move; treat poll percentages as point-in-time snapshots.)
OWASP labels these risks ASI01 through ASI10 (Agentic Security Issue). The numbering reflects prevalence and impact ranking, not a sequence you work through. ASI01 (Agent Goal Hijack) sits at the top because it is the entry point for most real-world agent compromises observed in 2025.
ASI01 to ASI05: the action-layer risks
The first five OWASP agentic AI categories cover how an attacker bends an agent’s reasoning and tools into doing harm: goal hijacking, tool misuse, identity abuse, supply chain compromise, and unexpected code execution. These are the risks closest to the agent’s ability to take action, and they are where most exploited incidents start.
The pattern across all five is the same: the agent is given more trust, more reach, or more privilege than the situation warrants, and an attacker finds the seam. The fixes are correspondingly about narrowing trust at every boundary, treating model output as untrusted, and separating the ability to decide from the ability to execute.
| Code | Risk | What it looks like | Concrete fix |
|---|---|---|---|
| ASI01 | Agent Goal Hijack | Malicious text in an email, PDF, or web page rewrites the agent’s objective, turning a copilot into a silent exfiltration engine. | Treat all reasoning-influencing text as untrusted; apply injection filtering; limit tool privileges; require human approval for high-impact changes. |
| ASI02 | Tool Misuse and Exploitation | Ambiguous prompts or manipulated inputs make the agent use a legitimate tool destructively (mass delete, over-broad query, data exfil). | Least-privilege per tool with scope and rate limits; sandboxed execution; validate every tool argument; explicit confirmation for destructive actions. |
| ASI03 | Identity and Privilege Abuse | An agent inherits a high-privilege shared credential and reuses or escalates it far beyond its task scope. | Unique bounded identity per agent; short-lived credentials; task-scoped permissions; re-authorize on privilege escalation; isolate sessions. |
| ASI04 | Agentic Supply Chain Vulnerabilities | A compromised plugin, MCP server, or prompt template fetched at runtime alters agent behavior or leaks data. | Sign and attest manifests and tool descriptors; pin dependencies; curated registries; block untrusted sources; sandbox plus kill switches. |
| ASI05 | Unexpected Code Execution | The agent generates and runs shell commands or deserializes attacker-controlled output, reaching remote code execution. | Separate code generation from execution with approval gates; no direct eval; hardened non-root sandboxed containers; preview before run. |
ASI06 to ASI10: the memory, coordination, and trust risks
The second five OWASP agentic AI categories cover the risks that emerge once agents have memory, talk to each other, chain into long plans, earn user trust, or go rogue: memory poisoning, insecure inter-agent communication, cascading failures, human-agent trust exploitation, and rogue agents. These are the distinctly agentic risks with no real equivalent in the LLM Top 10.
They are also the hardest to detect, because the harm is often delayed. A poisoned memory entry (ASI06) may sit dormant for weeks before it steers a decision. A small planning error (ASI08) can compound silently across a dozen downstream steps before anyone notices the blast radius. This is why observability, immutable logging, and containment controls dominate the mitigations here.
ASI06 and ASI08 are the categories teams underestimate most. Both produce harm that is decoupled in time from the attack, so a single point-in-time test will pass while the system is already compromised. You cannot catch these without continuous provenance tracking and runtime behavioral monitoring.
| Code | Risk | What it looks like | Concrete fix |
|---|---|---|---|
| ASI06 | Memory and Context Poisoning | An attacker plants data in the agent’s memory, embeddings, or RAG store to steer future decisions long after the injection. | Scan and validate memory writes before commit; segment memory by user/task/domain; track provenance; decay or expire low-trust entries. |
| ASI07 | Insecure Inter-Agent Communication | Unauthenticated agent-to-agent messages let an attacker intercept traffic or inject instructions into another agent. | Mutual TLS and encryption on agent channels; sign payloads with nonces and timestamps; anti-replay protection; authenticated discovery. |
| ASI08 | Cascading Failures | A small error in planning or execution propagates across interconnected agents and systems, compounding rapidly. | Zero-trust design with fault isolation; rate limits; blast-radius caps; circuit breakers; pre-deployment testing of multi-step plans. |
| ASI09 | Human-Agent Trust Exploitation | Users over-trust agent recommendations; an attacker exploits that trust to influence decisions or extract sensitive data. | Require explicit confirmations or multi-step approvals for high-impact actions; immutable logs; UI risk and confidence cues; no persuasive language. |
| ASI10 | Rogue Agents | A compromised or misaligned agent acts harmfully while appearing legitimate, persisting across sessions. | Behavioral monitoring and watchdog agents; strict governance; rapid containment via kill switches; comprehensive signed audit logs. |
The four actions that always need a human: where OWASP agentic AI meets operations
OWASP and the wider 2026 security community converge on one operational rule: four classes of irreversible action should require mandatory human approval no matter how confident the agent is. Those are payments, data deletion, credential access, and production deployments. The list explicitly calls for human-in-the-loop approval inside ASI01, ASI02, and ASI09 for high-impact actions, and Dark Reading’s 2026 coverage recommends the same hard gates.
The reasoning is the governance-versus-containment gap that defines agentic security right now. Survey data cited in 2026 reporting found roughly 60% of organizations cannot terminate a misbehaving agent quickly and 63% cannot enforce purpose limitations on what an agent is allowed to do. If you cannot reliably stop an agent mid-action, you must instead refuse to let it take the irreversible actions unsupervised in the first place. Approval gates are the cheapest containment control you can ship today.
The trap to avoid is treating a model’s confidence score as a substitute for an approval step. A hijacked agent (ASI01) is often most confident precisely when it is most wrong, because the injected instruction reads as a clear, unambiguous goal. The gate has to be structural, not conditional on the agent’s self-assessment.
“If you cannot reliably stop a misbehaving agent mid-action, you must refuse to let it take irreversible actions unsupervised in the first place.”
On why approval gates beat confidence scores
Payments and fund movement
Any action that moves money, issues a refund, changes billing, or commits spend. Gate on amount thresholds at minimum; gate everything above a small ceiling. This maps to ASI02 (tool misuse) and ASI09 (trust exploitation).Data deletion and destructive writes
Bulk deletes, schema changes, table drops, and overwrites of production data. Require a preview of the exact affected rows or objects before approval. Maps to ASI02 and ASI05.Credential and secrets access
Reading, minting, or rotating credentials, API keys, or tokens. Each access should be short-lived, scoped to the task, and logged. Maps directly to ASI03 (identity and privilege abuse).Production deployments and config changes
Shipping code, changing infrastructure, or altering security policy. These get a human reviewer and an immutable record of who approved what. Maps to ASI05, ASI08, and ASI10.How to actually adopt the OWASP agentic AI list this quarter
A real threat model, not security theater
Adopt the OWASP agentic AI Top 10 by running it as a checklist against one production agent first, gating the four irreversible actions immediately, then closing the highest-likelihood categories (ASI01, ASI02, ASI03) before moving to the slower-burning ones. Do not try to engineer all ten controls at once; sequence by likelihood and blast radius.
A practical order of operations: start by inventorying every tool each agent can call and stripping privileges down to the task (closes most of ASI02 and ASI03). Add the four human-approval gates next, because they are policy, not infrastructure, and they cap your worst-case loss while you build the rest. Then layer in injection filtering and untrusted-input handling for ASI01, signed manifests and dependency pinning for ASI04, and finally the observability stack (provenance, immutable logs, watchdog monitoring) that ASI06, ASI08, and ASI10 depend on.
The honest reality is that the governance gap is wide. With only about 34% of enterprises reporting AI-specific controls against 48% naming agentic AI their top threat, simply having a mapped checklist puts you ahead of most of the field. The OWASP agentic AI framework gives you the map; the work is closing one path at a time.
If you ship only one thing this quarter, ship the four approval gates and per-agent least-privilege identities. Together they cover the most exploited categories (ASI02, ASI03) and cap your worst-case loss on the irreversible actions, for almost no infrastructure cost.
# Minimal policy gate config — every tool call checked before execution
# Maps to OWASP agentic AI: ASI01 / ASI02 / ASI03 / ASI09
agent: support-copilot
identity:
scope: read:tickets, write:tickets # ASI03 least privilege
credential_ttl: 900s # short-lived creds
tool_policy:
default: deny # deny-by-default, ASI02
allow:
- search_kb
- draft_reply
human_approval_required: # the four hard gates
- action: payment.* # payments
- action: db.delete # data deletion
- action: secrets.read # credential access
- action: deploy.prod # production deploys
audit:
log: immutable # ASI10 forensics
record: [tool, args, provenance, approver]Builder’s take
I run Cyntr, an agent orchestration runtime, so the OWASP agentic AI list is not an abstraction for me. Every one of these ten failure modes maps to a code path I have had to harden. The framework is the first one that names the things that actually break agents in production rather than recycling web-app categories.
- Treat the model output as the least trusted thing in your system. In Cyntr every tool call passes through a policy gate before execution, so a hijacked goal (ASI01) cannot reach a destructive tool (ASI02) without an explicit allow rule. Policy on every path, not just the front door.
- Give every agent its own bounded identity with short-lived credentials. Shared service accounts across agents are how ASI03 privilege abuse turns one compromised agent into a blast radius across your whole fleet.
- Hard-gate the four irreversible actions: payments, data deletion, credential access, and production deploys. These get a human approval step in my systems regardless of how confident the agent is. Confidence scores are not a substitute for a kill switch.
- Log every tool invocation with provenance, and make the log immutable. When an agent goes rogue (ASI10) or memory gets poisoned (ASI06), the audit trail is the only thing that tells you when the drift started and what it touched.
Frequently asked questions
It is a peer-reviewed list of the ten most critical security risks specific to autonomous AI agents, published by the OWASP GenAI Security Project on December 9, 2025 with input from more than 100 contributors. The risks are coded ASI01 through ASI10 and cover threats unique to agents that take action, such as goal hijacking, tool misuse, and rogue agents.
The LLM Top 10 addresses risks in systems that generate text, while the agentic list addresses systems that perceive, reason, and act through tools. Agentic-specific risks like memory poisoning, insecure inter-agent communication, and cascading failures have no real equivalent in the LLM list, because they only emerge once an agent has memory, autonomy, and the ability to call real-world tools.
They are ASI01 Agent Goal Hijack, ASI02 Tool Misuse and Exploitation, ASI03 Identity and Privilege Abuse, ASI04 Agentic Supply Chain Vulnerabilities, ASI05 Unexpected Code Execution, ASI06 Memory and Context Poisoning, ASI07 Insecure Inter-Agent Communication, ASI08 Cascading Failures, ASI09 Human-Agent Trust Exploitation, and ASI10 Rogue Agents.
OWASP and 2026 security guidance converge on four irreversible action classes that should require mandatory human approval: payments and fund movement, data deletion, credential or secrets access, and production deployments. These gates should be structural and not conditional on the agent’s confidence score, because a hijacked agent is often most confident when it is most wrong.
It is wide. A Dark Reading poll found 48% of security professionals rank agentic AI the top attack vector for 2026, yet only about 34% of enterprises report AI-specific security controls. Darktrace’s State of AI Cybersecurity 2026 found 92% of security pros concerned about AI agents while just 37% have a formal AI policy. These figures are point-in-time and will move.
Start with one production agent: inventory its tools and strip privileges to the task to address ASI02 and ASI03, then add the four human-approval gates because they are policy rather than infrastructure and cap worst-case loss. After that, layer in injection filtering, signed supply-chain manifests, and the observability stack that the memory and cascading-failure categories depend on.
Primary sources
- OWASP Top 10 for Agentic Applications for 2026 — OWASP GenAI Security Project
- OWASP Top 10 for Agentic Applications: The Benchmark for Agentic Security — OWASP GenAI Security Project
- 2026: The Year Agentic AI Becomes the Attack-Surface Poster Child — Dark Reading
- State of AI Cybersecurity 2026: 92% Concerned About AI Agents — Cloud Security Alliance / Darktrace
- OWASP Top 10 for Agentic Applications 2026 Is Here — Palo Alto Networks
- Agentic AI Attack Surface: Why It’s the #1 Cyber Threat of 2026 — Kiteworks
Last updated: May 30, 2026. Related: Observability.
