TL;DR
What the OWASP Agentic AI Top 10 means for your pipeline
An LLM that says something wrong is a content problem. An agent that does something wrong is a security incident. The OWASP Agentic AI Top 10 is the map for the second.
- What it is: the OWASP Agentic AI Top 10 (officially the OWASP Top 10 for Agentic Applications 2026) lists ten risks specific to AI agents that plan, call tools, keep memory and act on your behalf. The codes run from ASI01 to ASI10.
- How it relates: it extends the OWASP LLM Top 10 rather than replacing it. The LLM list covers what a model says; the agentic list covers what an agent does.
- Where it enters: in a real pipeline, these risks arrive through four doors: the IDE, third-party agent components, your own agent code, and production runtime.
- What you can catch: six of the ten leave fingerprints in code and configuration, so you can stop them before deploy. The other four need runtime design controls, and every one of those starts with knowing which agents you run.
The first step: inventory every agent, tool, MCP server and skill, then gate new agent code in CI with findings tagged to ASI codes.
Why the OWASP Agentic AI Top 10 matters: your pipeline has new committers
A year ago, the code in your repositories came from people. Today, a growing share comes from AI agents: coding assistants that install dependencies, agents that open pull requests, and agent frameworks that ship inside your own products with tools, memory, and credentials of their own. That is the shift the OWASP Agentic AI Top 10 was written for.
That changes the threat model. An LLM that says something wrong is a content problem. An agent that does something wrong (deletes data, leaks a token, installs a poisoned package) is a security incident.
The OWASP Agentic AI Top 10 is the first shared vocabulary for that second kind of problem. Most explainers stop at definitions. This one maps each risk to the place it actually enters your pipeline, and to what you can do about it before deployment.
What is the OWASP Agentic AI Top 10?
The OWASP Agentic AI Top 10 is a peer-reviewed list of the ten most critical security risks in AI agents: systems that plan, call tools, keep memory, and act with delegated authority. Its official name is the OWASP Top 10 for Agentic Applications 2026. The OWASP GenAI Security Project published it on 9 December 2025, through its Agentic Security Initiative, which is where the ASI prefix comes from.
It is still a young standard: this is its first edition. Each entry follows the familiar OWASP format, with a description, common examples, attack scenarios, and prevention guidance. OWASP’s central design advice runs through all ten: avoid giving agents more autonomy than the task needs, and treat observability as mandatory.
Agentic Top 10 vs. LLM Top 10
The agentic list does not replace the OWASP Top 10 for LLM Applications. It builds on it, and its entries cross-reference LLM risks directly. A simple rule of thumb:
| Dimension | OWASP LLM Top 10 | OWASP Agentic AI Top 10 |
|---|---|---|
| Focus | What the model says | What the agent does |
| Typical failure | A manipulated or leaked response | A manipulated goal, tool call or action |
| Applies to | Chatbots, RAG apps, any LLM feature | Agents with tools, memory, delegation or other agents |
| Codes | LLM01 to LLM10 | ASI01 to ASI10 |
If your application only answers questions, the LLM list covers you. The moment it can take actions, you need both. Our guide to model extraction attacks shows one LLM Top 10 risk in depth.
The OWASP Agentic AI Top 10, explained: ASI01 to ASI10 in real pipelines
Here is each risk in the OWASP Agentic AI Top 10 in plain terms, followed by what it looks like in the codebases and pipelines we see every day.
ASI01: Agent Goal Hijack
An attacker changes what the agent is trying to achieve through injected instructions in a document, an email, a web page, or another agent’s message. Agents struggle to tell instructions apart from content, so planted text can redirect a whole multi-step plan.
In your pipeline: an agent that summarizes pull requests reads a PR description containing hidden instructions, and starts approving or leaking instead of summarizing.
ASI02: Tool Misuse and Exploitation
The agent uses a tool it is allowed to use, but in a harmful way: deleting data, calling a costly API in a loop, or sending information out. No privilege is escalated; legitimate access is simply pointed at the wrong target.
In your pipeline: a coding agent with shell access runs a cleanup command against the wrong directory.
ASI03: Identity and Privilege Abuse
Agents inherit credentials, sessions, and roles, and attackers exploit those delegation chains to reach what they could not reach directly. The root cause is identity systems built for humans, applied to software that acts on its own.
In your pipeline: an agent configuration holds a long-lived token with organization-wide scope, shared across several tools.
ASI04: Agentic Supply Chain Vulnerabilities
The models, tools, plugins, MCP servers, skills and prompts that agents load come from third parties, and any of them can be malicious or tampered with. Unlike classic dependencies, agents often assemble these components at runtime.
In your pipeline: a developer installs a typosquatted agent skill whose instructions tell the agent to read credentials and post them externally.
ASI05: Unexpected Code Execution (RCE)
The agent generates or triggers code that runs where it should not: shell commands, deserialized objects, template engines, eval on model output. The result can be full host or container compromise.
In your pipeline: LLM output flows straight into eval, or an agent loads an untrusted dataset with pickle.load.
ASI06: Memory and Context Poisoning
Attackers seed the agent’s long-term memory, summaries or RAG stores with malicious data, so every future decision is skewed. Unlike a one-off prompt injection, the corruption persists across sessions.
In your pipeline: a RAG retriever ingests external documents without sanitization, and one poisoned page shapes every answer that follows.
ASI07: Insecure Inter-Agent Communication
Agents exchange messages without authentication, integrity checks, or validation, so messages can be spoofed, intercepted, or altered. The same instruction can also be read differently by different agents.
In your pipeline: a planner agent accepts tasks from any service on the internal network that speaks its protocol.
ASI08: Cascading Failures
One fault (a hallucination, a poisoned memory, a compromised tool) spreads across agents and workflows faster than humans can react. OWASP applies this category when the damage fans out beyond the original breach.
In your pipeline: one agent writes a bad config, a second deploys it, a third rolls it out to every region. We debated how to contain that blast radius in our Blast Radius SafeDev Talk.
ASI09: Human-Agent Trust Exploitation
People trust confident, well-explained agent output, and attackers or flawed designs exploit that trust to steer decisions. The human performs the final action, so the agent’s role can disappear from the audit trail.
In your pipeline: a reviewer approves an agent’s pull request because the explanation sounds right, without checking the diff.
ASI10: Rogue Agents
An agent drifts from its intended function and keeps acting harmfully, deceptively, or beyond scope. Each action may look legitimate; the overall behavior is not. ASI10 is about losing control after the drift starts, not about the initial intrusion.
In your pipeline: an agent keeps using permissions after its task ends, quietly expanding what it touches.
Of the ten risks, ASI04 is the one most teams already face every day: coding agents choosing and installing packages with nobody reviewing what gets in. We dug into exactly that in a recent SafeDev Talk. Take a look!
Where the OWASP Agentic AI Top 10 enters your pipeline
The ten risks don't arrive through one door. They arrive through four, and each door needs its own control.
| Entry point | What comes in | ASI risks | Where to stop it |
|---|---|---|---|
| Developer IDE and workstation | Coding agents, MCP servers, skills, packages that agents install | ASI04, ASI05 | On the workstation, before install |
| Third-party agent components | Models, tools, plugins, prompts from registries | ASI04, ASI06 | Inventory and review, before adoption |
| Your own agent code | Agent frameworks, prompts, tool definitions, credentials, RAG pipelines | ASI01, ASI02, ASI03, ASI05, ASI06 | Static analysis, in pull requests and CI |
| Production runtime | Agents acting, talking to each other, working with people | ASI07, ASI08, ASI09, ASI10 | Architecture, monitoring and kill switches |
The pattern matters for how you apply the OWASP Agentic AI Top 10. The first three doors leave evidence in code and configuration, which means you can find and block them before anything ships. The fourth depends on runtime behavior, so it relies on design choices: least agency, signed messages, human approval for high-impact actions, and the ability to revoke any agent fast.
Even the runtime controls depend on one thing you build earlier: an inventory. You can’t put a kill switch on an agent you don’t know exists.
How Xygeni catches OWASP Agentic AI Top 10 risks before deployment
Xygeni AI Security scans the AI components your applications are built with, directly from source code. Each finding carries its OWASP LLM Top 10 category and, where applicable, its OWASP Agentic AI Top 10 code, so your team and your auditors read findings in the same language.
Covering the OWASP Agentic AI Top 10 starts with the inventory. AI Security discovers agents, models, tools, MCP servers, skills, prompts, guardrails, vector stores, and datasets across your repositories, and maps how they connect: which agent uses which model, executes which tools, and calls which MCP servers. The inventory exports as a CycloneDX 1.6 ML-BOM.
Xygeni AI Security
What Xygeni detects before deploy, by ASI risk
Every finding is tagged with its OWASP code, so your team and your auditors read it in the same language.
Agent Goal Hijack
Prompt injection surfaces, agents ingesting external content without sanitization, prompts pulled from registries on floating labels.
Tool Misuse
Tool-invoking agents without input guardrails, plus a per-asset view of capabilities such as code execution and auto-execute.
Identity and Privilege Abuse
Static long-lived credentials in agent configs, credentials shared without scope narrowing, MCP and tool servers with elevated privileges, and secrets in prompt files.
Agentic Supply Chain
Malicious or typosquatted skills, with a SAFE / CAUTION / DO_NOT_INSTALL verdict; unsafe model loading (trust_remote_code=True); an AI-BOM of every component.
Unexpected Code Execution
Taint flows from LLM output into eval and from untrusted datasets into pickle.load, in Python and JavaScript; template injection leading to RCE.
Memory and Context Poisoning
Unsanitized RAG retrievers, and vector and embedding weaknesses (LLM08).
Runtime behavior
Inter-agent communication, cascading failures, human trust and rogue agents emerge at runtime. Xygeni gives you the inventory and relationship graph those runtime controls depend on.
Around that core:
- Semantic review of skills and agent instructions. An optional, reproducible LLM review judges the intent of
SKILL.mdandAGENTS.mdfiles, catching prose-only malicious instructions no signature can see. It can run on a self-hosted model. - Gate it in CI. The
xygeni aiscanner runs in your pipeline and fails the build when findings exist. Start in report-only mode, then gate on Critical. - Security inside the agent loop. DevAI brings Xygeni scans, triage, and fixes into the IDE and into AI coding agents through the Xygeni MCP server.
- Protect the workstation. Shield blocks malicious packages on developer machines before they download, whoever runs the install, and attributes every block to the process and command that triggered it.
- Fix fast. AI Triage prioritizes findings, and AI Remediation generates fix guidance for every OWASP LLM category.
OWASP Agentic AI Top 10 readiness checklist
- Inventory: list every agent, model, tool, MCP server and skill in your repositories, and keep the list current on every commit.
- Least agency: give each agent only the autonomy and tools its task needs, and require human approval for destructive actions.
- Scoped identity: replace long-lived, shared agent credentials with short-lived, per-agent tokens.
- Untrusted input: treat every document, web page, email and agent message as untrusted before it can shape a goal or a tool call.
- Vetted components: review skills, MCP servers and models before adoption, pin versions, and keep an AI-BOM.
- No unsafe execution: ban
evalon model output, sandbox code execution and never run agents as root. - Clean memory: sanitize what enters RAG stores and long-term memory, and separate memory by user and context.
- Gate in CI: scan agent code on every pull request and map findings to ASI codes.
- Observe and contain: log every agent action and tool call, and make sure you can revoke any agent fast.
Know which agents you run before they act
The OWASP Agentic AI Top 10 gives you the map. The first move is the same for all ten risks: find every agent, tool, and skill in your code. See how Xygeni AI Security inventories your agents and maps findings to ASI codes, or book a demo.
FAQs
What does ASI stand for in the OWASP Agentic AI Top 10?
ASI stands for Agentic Security Initiative, the OWASP GenAI Security Project team that wrote the list. Each risk carries a code from ASI01 (Agent Goal Hijack) to ASI10 (Rogue Agents), the same way the LLM list uses LLM01 to LLM10.
Do I need the OWASP Agentic AI Top 10 if I already follow the OWASP LLM Top 10?
Only if your AI can act. A chatbot or RAG app that just answers questions is covered by the LLM Top 10. Once your application calls tools, keeps memory, delegates to other agents, or uses credentials, the agentic list covers risks the LLM list does not.
Can static analysis detect OWASP Agentic AI Top 10 risks?
For many of them, yes. Goal hijack surfaces, unguarded tools, over-privileged credentials, malicious skills, unsafe code execution, and unsanitized RAG inputs all leave evidence in code and configuration. Risks that emerge from live behavior, such as cascading failures and rogue agents, need runtime controls on top.







