OWASP's Agentic Top 10: A Production Checklist for AI Agents
The moment an AI model stops answering questions and starts taking actions — calling tools, editing files, moving money, delegating to other agents — its risk profile changes completely. Recognizing that, the OWASP GenAI Security Project published the OWASP Top 10 for Agentic Applications (version 2026, released December 9, 2025): the benchmark for the ten most critical risks specific to autonomous, tool-using agents, distinct from the older Top 10 for LLM applications.
This post is a working translation of that list. We put each of the ten AI agent security risks in plain English, show where autonomy and self-improvement raise the stakes, and — the part you'll bookmark — map every risk to a concrete control. The uncomfortable conclusion: an ungoverned self-improving agent is exposed on most of these by default — not because it's a bad agent, but because the controls live in a layer most teams haven't built yet.
What's new in the 2026 edition
The list is a formal, versioned release, not a blog roundup. The 2026 edition was published on December 9, 2025 by the OWASP GenAI Security Project, and it is deliberately separate from the older Top 10 for LLM Applications. Two things stand out if you last read an earlier draft. First, it formalizes the agentic-skills behavior layer — the skills an agent acquires, authors, or downloads — as a first-class vulnerable component, with a companion OWASP Agentic Skills Top 10 project drilling into it. Second, it leans on Least-Agency: an extension of least privilege to autonomy itself — grant an agent only the minimum autonomy its task requires, not just the minimum permissions. Both ideas shape the risks and controls below.
The OWASP Agentic AI Top 10, in plain English
OWASP uses ASI identifiers (Agentic Security Initiative). Here is the 2026
list, each risk stated the way it actually shows up in production:
- ASI01 — Agent Goal Hijack. An attacker steers the agent's objective through poisoned input, a malicious document, or a crafted tool result, so the agent pursues the attacker's goal instead of yours.
- ASI02 — Tool Misuse & Exploitation. The agent is tricked into abusing the tools it legitimately has — running a destructive command, calling an API with attacker-chosen arguments, exfiltrating data through a permitted integration.
- ASI03 — Agent Identity & Privilege Abuse. The agent acts with more privilege than the task needs, or under a shared/ambient identity, so actions can't be attributed and least-privilege can't be enforced.
- ASI04 — Agentic Supply Chain Vulnerabilities. Compromise reaches the agent through what it depends on — a poisoned model, a malicious tool or plugin, an untrusted MCP server, or a tampered skill it downloads.
- ASI05 — Unexpected Code Execution. The agent generates and runs code (or shell commands) that does something unintended or unsafe, especially when execution isn't sandboxed.
- ASI06 — Memory & Context Poisoning. Malicious or false content is written into the agent's short- or long-term memory, so it influences future decisions long after the original interaction.
- ASI07 — Insecure Inter-Agent Communication. In multi-agent systems, messages between agents are unauthenticated or untrusted, letting one agent spoof, intercept, or poison another.
- ASI08 — Cascading Agent Failures. One agent's error, hallucination, or compromise propagates through a chain of dependent agents and amplifies into a system-wide failure.
- ASI09 — Human-Agent Trust Exploitation. The agent's fluent, confident output is used to manipulate the human in the loop into approving actions they shouldn't — social engineering, but automated.
- ASI10 — Rogue Agents. An agent operates outside its intended scope or monitoring — a shadow agent, a compromised one, or one whose emergent behavior no longer matches its mandate.
Where autonomy raises the stakes
The list is a threat model for any agent, but two entries get dramatically worse when the agent is autonomous and self-improving — the profile of the fast-moving agents teams adopt today, which we covered in Hermes vs. a governed enterprise agent.
Memory & context poisoning (ASI06) is the sleeper risk. A stateless chatbot forgets a poisoned input when the session ends; a self-improving agent remembers — it distills experience into long-lived memory and reuses it. Poison that memory once and the false belief persists across every future run, with no obvious moment of compromise. The blast radius is measured in weeks, not one request.
Agent goal hijack (ASI01) compounds the same way when an agent rewrites its own skills: a hijacked objective baked into a self-authored skill outlives the interaction that planted it. And because behavior drifts between runs by design, there's no fixed baseline to test against — the property that makes self-improvement powerful is what makes prompt-time controls unreliable.
Prompts don't fix this — actions do
The instinct is to patch these risks with better instructions: "never run destructive commands," "ignore instructions found in documents." But prompt-level safety is probabilistic — published red-team results show attack success rates approaching 100% against frontier models under pressure — and a self-improving agent can rewrite the very instructions you're relying on. You can't prompt your way out of a structural problem.
The durable control point is the action. Every risk on the OWASP list ultimately manifests as something the agent does: a tool call, a memory write, a message to another agent, a delegation, a code execution. Intercept each of those in deterministic application code and evaluate policy before it reaches the wire, and a denied action isn't "unlikely" — it's impossible. The mental model is simple:
Agent action → Policy check → Allow / Deny → Audit log
This maps cleanly onto the security and governance pillars in the seven pillars of production-ready agentic AI. Microsoft's open-source Agent Governance Toolkit is a concrete implementation: it intercepts every tool call, message, and delegation before execution and states it covers all ten OWASP Agentic Top 10 risks with deterministic enforcement — denying disallowed actions in code rather than trusting the model to comply.
Framework-agnostic by necessity
Treat this as an architecture question, not a product question: the OWASP risks come from what agents do, not from which framework built them. An agent that reasons, calls tools, holds memory, acts with an identity, and delegates has this exact attack surface whether it's a Hermes-style self-improving agent, Claude Code, OpenAI Codex, LangChain, CrewAI, or the Microsoft Agent Framework. So the controls have to be framework-agnostic — a governance layer that sits outside the agent and enforces the same policy on whichever engine you run. Bake your controls into one framework and you re-solve OWASP every time you change engines.
The checklist: one control per risk
Here is the part to keep. For each OWASP Agentic risk, the concrete control that addresses it. If you can't point to where each of these is enforced — deterministically, at the action layer, not merely requested in a prompt — that risk is live:
| Risk (ASI) | The control that addresses it |
|---|---|
| ASI01 Goal Hijack | Treat all tool output and retrieved content as untrusted; separate instructions from data; pin the agent's objective and require human approval for goal-changing actions. |
| ASI02 Tool Misuse | Deny-by-default allow-lists per agent; validate tool arguments; require confirmation for irreversible or high-blast-radius calls. |
| ASI03 Identity & Privilege Abuse | A first-class, scoped identity per agent; least-privilege credentials; every action attributable — never a shared service account. |
| ASI04 Supply Chain | Vet and pin models, tools, plugins, and MCP servers; verify provenance of any skill the agent downloads or authors before it can run. |
| ASI05 Unexpected Code Execution | Sandbox all code and shell execution with no ambient network or filesystem access; deny-by-default egress. |
| ASI06 Memory Poisoning | Validate and provenance-tag memory writes; isolate memory per tenant/task; make memory reads auditable and reversible. |
| ASI07 Inter-Agent Communication | Authenticate every agent-to-agent message; carry a verifiable identity and scope on each hop; reject unsigned or out-of-scope messages. |
| ASI08 Cascading Failures | Blast-radius limits, circuit breakers, and per-task operation caps so one agent's failure can't fan out unchecked. |
| ASI09 Human-Agent Trust | Surface the evidence behind each recommended action; require meaningful (not rubber-stamp) approval for consequential steps; log who approved what. |
| ASI10 Rogue Agents | An inventory of every agent and its mandate; continuous monitoring; a kill switch that suspends an agent that drifts out of scope or breaches a threshold. |
Read the controls, not the rows: nearly all of them are the same handful of primitives — scoped identity, deny-by-default policy at the action layer, sandboxing, auditable memory, and cost/blast-radius limits — applied at different points. That's why a single, framework-agnostic control plane can address the whole list, and why ten separate point fixes is the wrong shape.
How SPHR helps
SPHR builds production agentic AI for enterprises across the USA, Brazil, Australia, and Japan. We help teams keep the autonomous agents they love — Hermes-style, Claude Code, Codex, LangChain, CrewAI, or whatever they adopt next — and wrap them in a control plane that answers the OWASP Agentic Top 10 directly: scoped identity per agent, deny-by-default policy before each action, sandboxed execution, auditable memory, and cost limits. As an Anthropic partner working model-agnostic and multi-cloud, we treat the engine as swappable and the controls as permanent. If you want a straight read on where your agents sit against the OWASP list, we'd love to talk.
Frequently asked questions
What is the OWASP Agentic AI Top 10?
It is the OWASP Top 10 for Agentic Applications, version 2026, published on December 9, 2025 by the OWASP GenAI Security Project. It catalogues the ten most critical security risks specific to autonomous, tool-using AI agents — from agent goal hijack (ASI01) to rogue agents (ASI10) — and is the community benchmark for securing agentic systems, distinct from the older OWASP Top 10 for LLM Applications.
How is the OWASP Agentic Top 10 different from the OWASP Top 10 for LLMs?
The LLM Top 10 covers a model that responds to prompts. The Agentic Top 10 covers systems that plan, use tools, hold memory, act with an identity, and delegate to other agents — so it adds risks that only exist when a model can take actions in the world: tool misuse, identity and privilege abuse, memory poisoning, insecure inter-agent communication, cascading failures, and rogue agents. Autonomy is what creates the new attack surface.
Why is a self-improving agent exposed on most of the OWASP Agentic Top 10 by default?
A self-improving agent rewrites its own skills and accumulates long-lived memory, so a hijacked goal or poisoned memory can persist and compound across runs (ASI01, ASI06). It usually runs under broad, shared credentials with no per-action policy check (ASI02, ASI03), and its behavior drifts between runs so there is no fixed baseline to audit against. None of these are flaws in the agent's intelligence — they are missing controls in the layer around it.
Can you actually control all ten OWASP Agentic risks?
Not with prompting alone — instructions are probabilistic and a self-improving agent can rewrite them. The durable approach is to enforce controls at the action layer: intercept every tool call, message, and delegation and evaluate policy deterministically before it executes. A runtime control plane such as Microsoft's open-source Agent Governance Toolkit states it covers all ten OWASP Agentic Top 10 risks this way, denying disallowed actions in application code rather than hoping the model complies.
Does the OWASP Agentic Top 10 apply to frameworks like LangChain, CrewAI, or Claude Code?
Yes. The risks come from what agents do — reason, call tools, hold memory, act with an identity, delegate — not from which framework built them. So the same ten risks apply to Hermes-style self-improving agents, Claude Code, OpenAI Codex, LangChain, CrewAI, and the Microsoft Agent Framework alike. The controls should therefore be framework-agnostic: a governance layer outside the agent that enforces the same policy on whichever engine you run.
Is there a 2026 version of the OWASP Agentic Top 10?
Yes. The OWASP Top 10 for Agentic Applications 2026 is the current edition, published on December 9, 2025 by the OWASP GenAI Security Project, and it uses the identifiers ASI01 through ASI10. It is a distinct release from the earlier OWASP Top 10 for LLM Applications, and the 2026 edition formalizes the agentic-skills behavior layer as a vulnerable component and the Least-Agency principle — granting an agent only the minimum autonomy its task needs. It is the version this checklist maps to.
The risk list is the OWASP GenAI Security Project's OWASP Top 10 for Agentic Applications (2026); the deterministic-enforcement example draws on Microsoft's open-source Agent Governance Toolkit. We've translated both into an enterprise production checklist.