The Agent Action Layer: The Security Gap Every Incumbent Skipped

Security spending in 2025 and 2026 clustered around the prompt layer, the model layer, and GenAI governance dashboards. The layer where an AI agent actually acts, calling a tool, invoking an MCP server, reading a skill, was skipped. That is exactly where agents get hijacked. A trusted MCP server called postmark-mcp silently BCC'd between 3,000 and 15,000 emails per day for 15 published versions before anyone caught it. No prompt filter and no model guardrail was ever going to see that, because the attack lives in the tool call, not the prompt.

I am Adam Lin. I build and operate ATR, Agent Threat Rules, an open MIT-licensed detection standard for exactly this layer. This essay is the argument for why the agent action layer needs a neutral, open standard, rather than one more single-vendor box. The early signal is that ATR rules have been contributed to and merged upstream — accepted by maintainers at Cisco, Microsoft, MISP, Gen Digital, and SigmaHQ into their repositories (some in production rule paths, some in community-rules examples). These are maintainer-accepted contributions, not vendor endorsements.

What is the agent action layer, and why did incumbents skip it?

The agent action layer is the moment an agent stops talking and starts doing: a tool call, an MCP exchange, a skill loaded off a registry, a shell command written to disk. Incumbents skipped it because their products were designed one layer too low. Prompt-injection filters inspect the text going into the model. Model-layer guardrails constrain what the model outputs. GenAI governance dashboards track policy and usage. All three are real and useful. None of them watch the tool call itself, which is where the compromise executes.

The public CVE record makes the gap concrete. MCPJam Inspector shipped with a default 0.0.0.0 binding, so a single HTTP request became remote code execution in every version before v1.4.3 (CVE-2026-23744). Azure MCP Server had an SSRF that stole managed-identity tokens and reached into Azure resources (CVE-2026-26118). Claude Code's own hooks and MCP config were exploited for arbitrary shell execution and API-key theft (CVE-2025-59536 and CVE-2026-21852). Every one of these is an action-layer failure. A prompt filter sees none of them.

Why does this layer need an open standard, not a product?

The action layer is a shared surface. The same malicious skill, the same booby-trapped MCP server, the same tool-misuse pattern hits Claude Code, Cursor, Windsurf, Gemini CLI, Cline, and Codex CLI alike. A detection encoded once should protect all of them. That is a standards problem, not a product problem. CVE did this for vulnerabilities and Sigma did this for SIEM detections: a neutral, portable format that any vendor can read and any vendor can contribute to.

A single-vendor product cannot fill this role for a structural reason. If the detection logic is proprietary, a rival will not run it, and the attacker only has to evade one implementation. If the format is open, a rival adopts it into their own scanner, contributes rules back, and the whole ecosystem hardens together. That is why ATR is governed as an independent standard that PanGuard is built on and operates, the same relationship Sigma has with the vendors who ship it, not a captive feature of one company.

The standard has to be executable, not a checklist. ATR maps to all ten OWASP Agentic Top 10 (2026) categories, from ASI01 Agent Goal Hijack through ASI10 Rogue Agents, with 866 rule-to-category mappings and nine of the ten categories at STRONG coverage. It also aligns to MITRE ATLAS, covering 34 of 101 top-level techniques across 13 of 16 tactics. The difference from a framework is that these are deterministic rules that run in milliseconds, not a maturity model you self-assess against.

Is the ecosystem actually converging on this layer?

ATR rules have been contributed to and merged upstream into several security tools, each backed by a merged pull request in the ATR ADOPTERS record — maintainer-accepted contributions, not vendor endorsements.

To be precise about what is shipped versus in flight: Google ADK, NVIDIA garak, OpenAI Guardrails, and the NIST OSCAL catalog (PR #338) are open pull requests in review, not endorsements. A merged PR means the code runs, not that the organization endorses me. I keep that line hard on purpose, because overstating adoption is how standards lose trust.

How well does the standard actually detect attacks?

The honest answer is that it depends on the corpus and the lane, and I refuse to quote a single blended number. Against NVIDIA garak's in-the-wild jailbreak corpus (650 samples), the Layer 1 deterministic rules hit 97.2% recall. On a self-built PINT-format corpus (850 samples, drawn from deepset prompt-injections and Lakera Gandalf, not Lakera's private PINT), 99.7% precision at 63.6% recall. On HackAPrompt (4,780 samples), 69.6% recall against a 28.6% baseline at 100% precision. On a 498-sample real-world SKILL.md corpus, 100% recall and 97% precision at 0.2% false positives.

False positives are lane-based, and I say so plainly. Against a 65,000-sample benign gate, the enforce lane runs about 0.24% false positives and the default hunt lane runs about 9%. There is no single engine-wide FP number, and anyone who quotes you one for an agent-security product is rounding away the truth. The corpus size and the lane always travel with the number.

The scale of the problem justifies the approach. I scanned 96,096 AI agent skills across six public registries and confirmed 751 malicious. Threat crystallization is how the standard keeps up: an AI understands a new attack once, it gets written as a deterministic rule, and that rule then executes in milliseconds for everyone. New attack to shipped rule takes about an hour. ATR now carries nearly 690 rules across ten categories (688 as of July 2026, npm agent-threat-rules v3.5.6).

FAQ

Is ATR PanGuard's proprietary standard?

No. ATR is an independent, MIT-licensed open standard governed on its own. PanGuard is one product built on it, the same way vendors build on Sigma or CVE. ATR rules have also been merged upstream into tools from Cisco and Microsoft, as maintainer-accepted contributions.

Why can't a prompt-injection filter catch these attacks?

Because the compromise executes in the tool call, not the prompt. postmark-mcp's silent BCC and the MCPJam RCE both live at the action layer, which prompt filters and model guardrails never inspect.

Does a merged pull request mean the organization endorses ATR?

No. A merged PR means the code runs in that product. I label endorsement separately, and I keep in-review PRs (Google ADK, NVIDIA garak, OpenAI Guardrails, NIST OSCAL) clearly marked as in review, never as adoption.

What is the compliance driver behind this?

EU AI Act Article 15 makes detecting adversarial attacks a legal duty for high-risk AI systems, enforced at the end of 2027 after the omnibus delay to December 2027. There is no near-term 2026 deadline.

The next step is one command. Run npm install -g @panguard-ai/panguard && pga up, then pga scan <target> to scan a skill or MCP server before you install it. The scanner and the rules are free and MIT-licensed. Or read the standard itself and contribute a rule, because the whole point of an open action layer is that a detection written once protects everyone.