OWASP Agentic Top 10 (2026): A Field Guide to Executable Detection for All 10 Categories
The OWASP Agentic Top 10 names ten agent risks; ATR ships 866 rule-to-category mappings covering all 10, nine at STRONG strength and one (ASI10) at MODERATE.
The OWASP Agentic Top 10 (2026) is a checklist of ten ways an AI agent gets attacked. The Agent Threat Rules (ATR) standard turns that checklist into something a scanner can run: 866 rule-to-category mappings, covering all ten categories. Nine are covered at STRONG strength; one, ASI10 Rogue Agents, is at MODERATE. A checklist tells you what to worry about. A rule tells you when it is actually happening in your logs.
The gap between those two things is the whole point of this post. OWASP gives you the taxonomy. It does not give you if this pattern appears in a tool call, flag it. ATR is an independent, MIT-licensed detection standard built to fill exactly that gap, the way Sigma sits under SIEM detections or CVE sits under vulnerability scanners. Below is every category in one plain sentence, plus how each maps to executable rules.
What is the OWASP Agentic Top 10?
It is OWASP's 2026 list of the top ten security risks specific to AI agents: systems that plan, call tools, hold memory, and act with some autonomy. Traditional application risks (the OWASP Top 10 for web, the LLM Top 10 for prompts) do not capture what happens when a model can invoke a shell, read your email, and spawn sub-agents. The Agentic list is the answer to "what breaks when the model can act, not just talk?"
The ten category IDs run ASI01 through ASI10. Here they are, each in one sentence.
The 10 categories, one sentence each
| ID | Name | In one sentence |
|---|---|---|
| ASI01 | Agent Goal Hijack | An attacker rewrites what the agent is trying to do, usually through injected instructions in content it reads. |
| ASI02 | Tool Misuse and Exploitation | The agent is tricked into calling a legitimate tool in a harmful way (wrong arguments, wrong target, wrong scope). |
| ASI03 | Identity and Privilege Abuse | The agent uses credentials or permissions it holds to reach data or actions it should not. |
| ASI04 | Agentic Supply Chain Vulnerabilities | A malicious or compromised skill, MCP server, or dependency enters the agent's trust boundary. |
| ASI05 | Unexpected Code Execution (RCE) | Attacker-controlled input reaches an interpreter or shell and runs as code. |
| ASI06 | Memory & Context Poisoning | Bad data written into the agent's memory or context steers its later decisions. |
| ASI07 | Insecure Inter-Agent Communication | Messages between agents are forged, intercepted, or trusted without verification. |
| ASI08 | Cascading Failures | One compromised or failing agent propagates the failure across a multi-agent system. |
| ASI09 | Human-Agent Trust Exploitation | The agent is used to manipulate a human, or a human's misplaced trust in the agent is abused. |
| ASI10 | Rogue Agents | An agent operates outside its intended boundaries, whether corrupted, misconfigured, or deliberately planted. |
How does ATR make each category executable?
ATR's Layer 1 is a set of deterministic detection rules: given an agent's input, tool call, or tool response, a rule either matches a known attack pattern or it does not, in milliseconds. Each rule carries metadata that maps it to one or more OWASP Agentic categories. Across the corpus that produces 866 rule-to-category mappings, with all ten categories covered. The reason ASI10 sits at MODERATE and the other nine at STRONG is honest: detecting a "rogue" agent by its behavior is genuinely harder to express as a deterministic pattern than detecting, say, an injected instruction or a shell metacharacter, so the rule coverage there is thinner. We label it as MODERATE rather than pretending otherwise.
The mechanism behind the rules is threat crystallization. An AI understands a new attack once, that understanding is written down as a deterministic rule, and the rule then runs for everyone at machine speed. A new attack becomes a shipped rule in about an hour, versus the weeks a committee-driven standard takes.
What does an executable rule catch that a checklist misses?
Real incidents make the difference concrete. ASI04 (supply chain) is not abstract: the postmark-mcp server was a trusted MCP that silently BCC'd between 3,000 and 15,000 emails a day for fifteen versions before anyone noticed. A checklist says "vet your MCP servers." A rule inspects the server's declared behavior against known exfiltration patterns before you install it.
ASI05 (RCE) is equally concrete. MCPJam Inspector (CVE-2026-23744) bound to 0.0.0.0 by default in every version before v1.4.3, turning a single HTTP request into remote code execution. Azure MCP Server (CVE-2026-26118) had an SSRF that stole managed-identity tokens. Claude Code itself carried CVE-2025-59536 and CVE-2026-21852, where hooks and MCP config were abused for arbitrary shell execution and API-key theft. Each of these is a pattern a Layer 1 rule can flag at scan time, not a paragraph you hope a developer read.
How strong is the detection layer, honestly?
The numbers depend on the corpus, and they should always be cited with their corpus. On the SKILL.md corpus of 498 real-world samples, Layer 1 rules hit 100% recall and 97% precision at a 0.2% false-positive rate. On the NVIDIA garak in-the-wild jailbreak corpus (650 samples), 97.2% recall. On a self-built PINT-format corpus (850 samples), 99.7% precision and 63.6% recall. On HackAPrompt (4,780 samples, EMNLP 2023), 69.6% recall against a 28.6% baseline at 100% precision.
There is no single blended false-positive number, and anyone who quotes you one is oversimplifying. On a 65,000-sample benign gate, false positives are lane-based: about 0.24% in the enforce lane, about 9% in the hunt lane (the default). You pick the lane for the job. That honesty about lanes is deliberate, because a detection standard that hides its false-positive cost is not a standard you can operate.
Where does this fit against MITRE and the law?
ATR also maps to MITRE ATLAS: 34 of the 101 top-level ATLAS techniques and 13 of the 16 tactics, against the ATLAS v5.6.0 draft. So a single ruleset speaks both the OWASP Agentic vocabulary and the ATLAS vocabulary, which matters when your governance team lives in one framework and your red team lives in another.
It also connects to obligation. EU AI Act Article 15 makes detecting adversarial attacks a legal duty for high-risk AI systems, enforced from end-2027 after the omnibus delay to December 2027. That is not a next-quarter fire drill. It is a reason to build detection into your agent stack now, while the standard is free and the rules are already written.
FAQ
Is ATR the same thing as the OWASP Agentic Top 10?
No. OWASP defines the ten risk categories; ATR is an independent, MIT-licensed detection standard that maps executable rules onto them (866 mappings, all 10 covered). One is the taxonomy, the other is the runnable detection.
Does covering all 10 categories mean every attack is caught?
No, and we do not claim that. Nine categories are covered at STRONG strength and ASI10 Rogue Agents at MODERATE, because behavioral "rogue" detection is harder to express deterministically. Coverage means every category has rules, not that detection is perfect.
Why is there no single precision or false-positive number?
Because it would be misleading. Results are reported per corpus, and the benign false-positive rate is lane-based: about 0.24% in the enforce lane and about 9% in the default hunt lane on a 65,000-sample gate.
Do I have to pay for any of this?
No. ATR is MIT-licensed and PanGuard's Community product is the complete tool with no paywall. Install with npm install -g @panguard-ai/panguard && pga up.
Next step: point the scanner at a skill or MCP server before you install it. Run pga scan <target> and see which of the ten categories light up on something you actually use.