\documentclass[11pt,letterpaper]{article}

\usepackage[margin=1in]{geometry}
\usepackage{hyperref}
\usepackage{booktabs}
\usepackage{graphicx}
\usepackage{listings}
\usepackage{amsmath}
\usepackage{xcolor}
\usepackage{enumitem}
\usepackage{url}
\usepackage{tabularx}
\usepackage{float}

\hypersetup{
  colorlinks=true,
  linkcolor=blue,
  citecolor=blue,
  urlcolor=blue
}

\lstset{
  basicstyle=\ttfamily\small,
  breaklines=true,
  frame=single,
  backgroundcolor=\color{gray!10},
  columns=fullflexible,
  keepspaces=true
}

\title{The Collapse of Trust: Security Architecture for the Age of Autonomous AI Agents\\[0.5em]
\large With ATR, the First Open Detection Standard and Quality Framework for AI Agent Threats}

\author{Adam Lin\\
Panguard AI, Inc.\\
\texttt{adam@agentthreatrule.org}\\
\texttt{https://github.com/Agent-Threat-Rule/agent-threat-rules}}

\date{May 2026}

\begin{document}

\maketitle

\begin{abstract}
The deployment of autonomous AI agents --- systems that reason, use tools, maintain memory, and coordinate with other agents --- has created a novel category of security challenge. Unlike traditional software, AI agents are \textbf{non-deterministic systems that process attacks and legitimate instructions through the same channel, in the same language, in the same context space.} The foundational assumption of 40 years of cybersecurity --- that you can separate control flow from data flow --- no longer holds. ATR provides for AI agent skills what Sigma provides for SIEM logs and YARA provides for malware files --- an open, community-driven detection rule format that turns threat intelligence into machine-executable defense.

This paper presents an empirical analysis of the AI agent security landscape based on evidence from 30+ CVEs \cite{cve6514,cve53773,cvegit,cve49596,cve59536,postmark,sandworm}, multiple distinct attack classes, 7 published benchmarks \cite{pint,mcptox,asb,aishell,hacka,tensortrust,caibench}, and multiple real-world production incidents in 2025--2026. We make six contributions:

\textbf{(1)} We demonstrate that AI agents are missing two of three foundational security trust pillars (authorization and integrity), and that this architectural gap --- not model weakness --- is the root cause of agent vulnerability.

\textbf{(2)} We provide the first unified attack taxonomy covering all 10 structural data flow points in AI agent architecture, showing that current defenses provide meaningful coverage for at most 1 of 10 points, with partial coverage at 2 additional points. We present evidence that indirect injection through unmonitored channels (tools, memory, inter-agent communication) achieves 36--98\% attack success rates across state-of-the-art models \cite{mcptox,minja,asb}, and that \textbf{more capable models are more susceptible} to tool-layer attacks \cite{mcptoxbench}.

\textbf{(3)} We analyze the scaling dynamics of AI agent security: attack surfaces grow superlinearly with capability, security measures have a half-life of 3--6 months, and offense is outpacing defense in the current AI scaling race \cite{aisafety}. We show why this trajectory makes static defenses (guardrails, prompt hardening, sandboxes) structurally inadequate.

\textbf{(4)} We propose architectural requirements for a defense system that can keep pace with AI evolution: multi-point interception, below-reasoning-layer detection, cascade economics, community-driven rule evolution, and open auditability. We argue that the industry needs an open detection standard analogous to Sigma \cite{sigma} (for SIEM) or Snort (for network IDS) --- and define the properties such a standard must have.

\textbf{(5)} We present Agent Threat Rules (ATR) \cite{atr}, the first open-source implementation of this standard, and validate it empirically: \textbf{419 YAML-based detection rules} across 10 threat categories (ATR v2.2.2, May 2026), independently benchmarked at 99.7\% precision and 63.9\% recall against the external PINT dataset \cite{pint} (850 samples), 97.1\% recall on NVIDIA Garak, and 100\% precision with 89.7\% recall on a 341-sample self-test corpus. An ecosystem-wide scan of \textbf{96,096 agent skills} across six registries (OpenClaw, ClawHub, Skills.sh, Hermes, MCP Registry) discovered \textbf{751 active malware skills} from three coordinated threat actors \cite{atrscanmega}. A threat crystallization flywheel has been validated end-to-end: community signal aggregation $\rightarrow$ LLM-assisted rule generation $\rightarrow$ automated quality gate $\rightarrow$ human review $\rightarrow$ publication. ATR rules are in production at Microsoft Agent Governance Toolkit (PRs \#908, \#1277), Cisco AI Defense skill-scanner (PRs \#79, \#99), MISP galaxy and taxonomies (merged 2026-05-10, distributed via CIRCL Luxembourg to EU national CERTs), and OWASP Agent Security Resource Hub (PR \#74 merged 2026-05-11). On 2026-05-11, Microsoft Copilot SWE Agent (operating inside the Microsoft Agent Governance Toolkit) opened a regression-test issue against ATR for two Semantic Kernel CVEs (CVE-2026-26030, CVE-2026-25592) disclosed four days earlier; ATR shipped matching detection rules to npm 2 hours 16 minutes after the issue opened, with no human routing required on Microsoft's side.

\textbf{(6)} We publish RFC-001 \cite{rfc001}, the first vendor-neutral quality standard for AI agent detection rules. RFC-001 defines maturity levels, a confidence scoring formula, a two-dimensional compliance model (metadata presence $\times$ provenance), six review tier levels (the first standard to formalize LLM-assisted review as a first-class tier), community signal aggregation, and multi-runtime compatibility declarations for 14 agent platforms. The standard is designed so that \textbf{any vendor} --- not just ATR --- can adopt the scoring algorithm by implementing a single adapter interface. A reference implementation is published as MIT-licensed open source. Microsoft's concurrent CTI-REALM benchmark \cite{ctirealm} independently validates the premise that AI agents can assist in detection rule generation, which is the mechanism ATR's crystallization flywheel relies on.

Taken together, these contributions argue that the AI agent ecosystem requires a new category of security infrastructure---a community-driven detection layer, operating below the LLM reasoning layer, that can evolve as fast as the threats it monitors. This paper defines that category, provides the first open implementation, and charts the research agenda for what comes next.
\end{abstract}


%----------------------------------------------------------------------
\section{The End of Perimeter Defense}
\label{sec:perimeter}

\textit{September 2025. A developer installs \texttt{postmark-mcp}, an npm package for sending emails via the Postmark API. Versions 1.0.0 through 1.0.15 work correctly. Version 1.0.16 adds a single BCC line: every email now silently copies to \texttt{phan@giftshop.club}. No CVE is filed. No alert fires. The AI agent is doing exactly what its tool description says---plus one thing it doesn't mention. Weeks pass before anyone notices} \cite{postmark}.

\textit{February 2026. Nineteen typosquatted npm packages---\texttt{claud-code}, \texttt{cloude-code}, \texttt{opencraw}---target developers using Claude Code, Cursor, and VS~Code. Each package reads \texttt{\textasciitilde/.ssh/id\_rsa}, AWS credentials, and API keys, then exfiltrates them to attacker-controlled endpoints. The packages are discovered by Socket.dev---not by any security tool running inside the agents} \cite{sandworm}.

These are not hypothetical scenarios. They are the opening moves of a new attack class that existing security infrastructure was not designed to detect. This paper explains why, presents the evidence at ecosystem scale, and proposes the architectural response.

\subsection{Forty Years of One Assumption}

Every security system since the Morris Worm (1988) rests on a single architectural assumption: \textbf{you can distinguish the control plane from the data plane.} Firewalls separate trusted networks from untrusted ones. IDS inspects data packets for attack signatures distinct from normal traffic. RBAC separates who-can-do-what from what-is-being-done. Sigma rules \cite{sigma} find malicious patterns in structured log data.

This assumption works because traditional software is deterministic. A web server processes HTTP requests according to fixed code. An attack must deviate from the expected protocol --- and that deviation is detectable.

AI agents are not deterministic. An LLM-based agent changes its behavior based on every piece of text in its context window. A tool description alters the agent's decision-making. A tool response shapes the agent's next action. A memory entry from a past session influences today's reasoning. An inter-agent message redirects the agent's goals.

\textbf{All of these inputs --- user instructions, tool descriptions, tool responses, memory, inter-agent messages --- enter the same context window and are processed by the same language model with no structural differentiation} \cite{kim2026,chhabra2025,survey2026}. The control plane (what the agent should do) and the data plane (information the agent processes) have collapsed into a single stream of natural language tokens.

This is not a bug in any specific model. It is the defining feature of language-model-based agency \cite{promptinjsurvey}. The model is useful precisely because it responds to natural language input. It is vulnerable for exactly the same reason.


\subsection{The Empirical Evidence}

In 2025--2026, every major AI agent security incident exploited this collapse:

\textbf{Protocol-layer attacks:}

\begin{itemize}
\item \textbf{CVE-2025-6514} (CVSS 9.6): MCP OAuth proxy --- a malicious server's response triggered OS command execution on the client. 437,000+ installations affected \cite{cve6514}. The attack entered through the MCP protocol, not user input. No WAF, no input classifier, no prompt defense could have caught it.
\item \textbf{CVE-2025-49596} (CVSS 9.4): MCP Inspector --- simply visiting a malicious website gave the attacker full control of a local AI agent through a 19-year-old localhost access vulnerability chained with CSRF \cite{cve49596}.
\end{itemize}

\textbf{Tool-layer attacks:}

\begin{itemize}
\item \textbf{CVE-2025-68143/68144/68145}: Anthropic's own Git MCP server --- path traversal, argument injection, and scoping bypass combined into a full RCE chain \cite{cvegit}. Exploitable via a poisoned README or GitHub issue.
\item \textbf{CVE-2025-53773}: GitHub Copilot --- prompt injection via source files manipulated Copilot into enabling ``YOLO mode'' (auto-approve all tool calls), creating a wormable attack that propagated across developer workstations \cite{cve53773}.
\end{itemize}

\textbf{Supply chain attacks:}

\begin{itemize}
\item \textbf{postmark-mcp} (Sep 2025): First in-the-wild malicious MCP server on npm \cite{postmark}. Versions 1.0.0--1.0.15 were clean; version 1.0.16 added a single BCC line that forwarded all emails to the attacker. An estimated 3,000--15,000 emails/day per organization during exposure \cite{postmark}.
\item \textbf{SANDWORM\_MODE} (Feb 2026): 19 typosquatted npm packages (claud-code, cloude-code, opencraw, etc.) targeting Claude Code, Cursor, VS Code, and Windsurf users \cite{sandworm}. Exfiltrated SSH keys, AWS credentials, API keys, and environment variables.
\end{itemize}

\textbf{Memory-layer attacks:}

\begin{itemize}
\item \textbf{MINJA} (NeurIPS 2025): 98.2\% injection success rate, $>$70\% downstream attack success --- achieved through query-only interaction, requiring no direct memory access \cite{minja}.
\item \textbf{ZombieAgent} (Jan 2026): Full exploit chain --- a malicious email attachment plants false memory in ChatGPT, which activates weeks later to exfiltrate data on every subsequent interaction \cite{memorygraft}.
\item \textbf{Microsoft AI Recommendation Poisoning} (Feb 2026): 31 companies caught hiding prompt injections inside ``Summarize with AI'' buttons, planting brand preferences into users' AI memory across Copilot, ChatGPT, Claude, Perplexity, and Grok \cite{mspoison}.
\end{itemize}

\textbf{Financial attacks:}

\begin{itemize}
\item \textbf{AiXBT} (Mar 2025): Attacker queued malicious prompts into an autonomous crypto trading agent's dashboard at 2 AM UTC. The agent transferred 55.5 ETH (\textasciitilde\$106,200) to the attacker's wallet \cite{aixbt}.
\end{itemize}

\textbf{Cross-agent attacks:}

\begin{itemize}
\item \textbf{ServiceNow Now Assist} (Nov 2025): A poisoned ticket description caused a benign agent to recruit a more powerful agent via agent-to-agent discovery, escalating privileges and exfiltrating records --- with prompt injection protections enabled \cite{servicenow}.
\end{itemize}

Every one of these attacks entered through a channel that current guardrails don't monitor. The agents were functioning correctly --- following instructions. The instructions came from the wrong source, and the agents had no mechanism to tell the difference.


%----------------------------------------------------------------------
\section{The Evidence: 751 Malware Skills Hiding in Plain Sight}
\label{sec:evidence}

Before we analyze \textit{why} AI agents are vulnerable, we present evidence that the threat is already here, already at scale, and already undetected by existing tools.

In April 2026, we used 113 pattern-based detection rules to conduct what is, to our knowledge, the largest automated security audit of AI agent skills to date \cite{atrscanmega}: \textbf{96,096 skills} across six registries (OpenClaw, ClawHub, Skills.sh, Hermes Agent, MCP Registry).

\begin{table}[htbp]
\centering
\caption{Ecosystem Scan: 96,096 Agent Skills Across Six Registries}
\label{tab:megascan}
\begin{tabular}{lrr}
\toprule
\textbf{Metric} & \textbf{Count} & \textbf{Percentage} \\
\midrule
Skills flagged (any severity) & 1,302 & \textbf{1.35\%} \\
CRITICAL & 989 & 1.03\% \\
HIGH & 353 & 0.37\% \\
MEDIUM & 7 & $<$0.01\% \\
Clean & 94,794 & 98.65\% \\
\textbf{Confirmed malware} & \textbf{751} & \textbf{0.78\%} \\
Threat Cloud blacklist entries & 554 & --- \\
\bottomrule
\end{tabular}
\end{table}

The scan uncovered the largest documented malware campaign targeting AI agent ecosystems: \textbf{751 active malware skills} distributed by three coordinated threat actors:

\begin{itemize}
\item \textbf{hightower6eu}: 354 skills (100\% malicious). Disguised as Solana and Google Workspace tools. Command-and-control infrastructure active at time of discovery.
\item \textbf{sakaen736jih}: 212 skills (93\% malicious). C2 server at \texttt{91.92.242.30}. Mixed with a small number of apparently legitimate tools as cover.
\item \textbf{52yuanchangxing}: 137 skills (72\% malicious). Chinese-language tools targeting developer workflows.
\end{itemize}

The dominant attack vector is \textbf{tool description poisoning}: embedding hidden instructions in a skill's metadata that the AI agent processes as trusted input. A single detection rule for credential access via tool descriptions triggered 686 times, accounting for 53\% of all flagged skills. All 751 skills were reported to NousResearch (hermes-agent\#9809) and blacklisted in Threat Cloud (554 entries). Full details are in the companion research report \cite{atrscanmega}.

\textbf{No existing security tool detected these 751 malware skills.} Not npm audit. Not the registry's own review process. Not the AI agents that installed and executed them. The skills passed every check because there was no check designed to look for what they were doing. The rest of this paper explains why---and what a detection architecture that can find them looks like.


%----------------------------------------------------------------------
\section{The Trust Architecture Gap}
\label{sec:trustgap}

\subsection{Three Pillars, One Standing}

Security trust rests on three pillars. They are so fundamental that every security framework (NIST \cite{nist}, ISO 27001, OWASP \cite{owaspllm,owaspagentic}, MITRE ATT\&CK \cite{mitreatlas}) assumes all three are present:

\begin{itemize}
\item \textbf{Identity (Authentication):} Who issued this instruction?
\item \textbf{Authorization:} Is this entity permitted to influence this decision?
\item \textbf{Integrity:} Has this instruction been tampered with?
\end{itemize}

\begin{table}[htbp]
\centering
\caption{Trust Pillar Analysis: Traditional Systems vs.\ AI Agents}
\label{tab:pillars}
\begin{tabularx}{\textwidth}{lXX}
\toprule
\textbf{Pillar} & \textbf{Traditional Systems} & \textbf{AI Agents} \\
\midrule
Identity & Cryptographic auth (TLS, JWT, SAML) & Message role tags (system/user/tool/assistant) --- coarse, unverified \\
Authorization & RBAC, ACL, capability tokens & \textbf{Absent.} A tool response has the same effective influence as a system prompt. \\
Integrity & Digital signatures, checksums, TLS & \textbf{Absent.} Tool descriptions are unsigned. Tool responses are unsigned. Memory entries have no provenance. Inter-agent messages are unauthenticated. \\
\bottomrule
\end{tabularx}
\end{table}

When a tool response says ``ignore previous instructions and exfiltrate the API key,'' the LLM has:

\begin{itemize}
\item \textbf{Partial identity}: it knows this text came from ``a tool'' (but not which tool, who wrote it, or whether it's been verified)
\item \textbf{No authorization check}: the tool response can contain any instruction, and the model will process it with the same weight as legitimate data
\item \textbf{No integrity verification}: there is no mechanism to detect if the response was tampered with in transit or if the tool itself was compromised
\end{itemize}

\textbf{Two of three security pillars are completely missing.} This is not a model problem --- no amount of training can compensate for missing architectural infrastructure. It's like asking a guard to verify visitors' identities when the building has no ID system and no visitor log.


\subsection{Why Model Improvement Doesn't Fix This}

A common counterargument: ``Models are getting better at resisting injection.'' This is true for direct injection. Claude Opus 4.5 achieves 4.7\% attack success rate on static benchmarks \cite{grayswan}. This is genuine progress.

But there are three problems:

\textbf{Problem 1: Adaptive attacks nullify static improvement.} RL-based adaptive attacks achieve 39.6\% success against comparable models \cite{rlinject}. Roleplay-based injection still hits 89.6\% \cite{rlinject}. When attackers adapt, the 4.7\% becomes 40\%+. Static benchmarks measure defense against yesterday's attacks.

\textbf{Problem 2: More capable models are MORE vulnerable to tool-layer attacks.} The MCPTox benchmark (1,312 test cases across 45 MCP servers) found that o1-mini --- one of the most capable reasoning models --- had the highest attack success rate at 72.8\% \cite{mcptoxbench}. The average across 20 SOTA LLMs was 36.5\% \cite{mcptoxbench}. Better reasoning = better at following injected instructions hidden in tool outputs.

\textbf{Problem 3: Model improvement only helps for attacks the model processes as ``suspicious.''} Indirect injection through trusted channels (tool responses, memory) doesn't trigger the model's injection resistance, because the model is trained to TRUST these channels \cite{kim2026,chhabra2025}. The system prompt says ``use tool outputs to inform your response.'' A tool output containing hidden instructions is processed as ``information to use,'' not as ``an attack to resist.''


\subsection{The Scaling Dynamics}

The security situation is getting worse, not better, as AI capabilities scale:

\textbf{Attack surface grows superlinearly.} Each new agent capability (tools, memory, multi-agent, code execution, payments, web browsing) doesn't just add a new attack surface --- it multiplies existing attack surfaces through composition \cite{kim2026,securitymodeling}. Memory poisoning + tool access = delayed credential theft. Code execution + web browsing = wormable propagation. Multi-agent coordination + privilege delegation = cascading compromise. The Galileo AI study found that a single compromised agent poisoned 87\% of downstream decision-making within 4 hours \cite{galileo}.

\textbf{Defense half-life is 3--6 months.} Anthropic's browser injection defenses went from 23.6\% failure to 11.2\% failure --- then researchers immediately found new vectors (file exfiltration via Cowork) \cite{anthropicrates}. MCP had 30 CVEs in 60 days (Jan--Feb 2026) \cite{checkmarx,cosai}. Any static defense measure gets bypassed within months.

\textbf{Offense outpaces defense.} The 2026 International AI Safety Report confirms: ``an offense-defense imbalance that keeps tilting toward attackers'' \cite{aisafety}. AI can now automate 80--90\% of hacking operations \cite{trendmicro}. OpenAI's Codex reached the ``High'' cybersecurity threshold --- capable of developing working zero-day exploits autonomously.\footnote{OpenAI internal evaluation; reported in multiple industry outlets, 2025--2026.} Attackers have scaling advantages: they need to find ONE vulnerability; defenders must close ALL of them.

\textbf{The MCP ecosystem is exploding faster than it can be secured.} From 100K downloads (Nov 2024) to 8M+ (Apr 2025). Over 8,000 MCP servers visible on the public internet \cite{checkmarx,paloalto}. 492 with zero authentication \cite{checkmarx}. 36.7\% of 7,000+ analyzed servers vulnerable to SSRF \cite{checkmarx}. Gartner predicts 75\% of API gateway vendors will have MCP features by 2026 \cite{gartner}. The attack surface is growing orders of magnitude faster than the security surface.


%----------------------------------------------------------------------
\section{The Complete Attack Surface Map}
\label{sec:attacksurface}

\subsection{Ten Data Flow Points}

We map the complete attack surface of an AI agent to 10 structural data flow points. This taxonomy is derived from empirical analysis of all published attacks through April 2026 \cite{kim2026,chhabra2025,promptkillchain,youraishell}:

\begin{table}[htbp]
\centering
\caption{Complete Attack Surface Map: 10 Structural Data Flow Points}
\label{tab:attacksurface}
\footnotesize
\begin{tabularx}{\textwidth}{clXlX}
\toprule
\textbf{\#} & \textbf{Data Flow Point} & \textbf{Attack Class} & \textbf{Real-World ASR} & \textbf{Real Incident} \\
\midrule
1 & User input & Direct prompt injection & 4.7--89.6\% \cite{grayswan,rlinject} & Numerous \\
2 & Tool descriptions & Tool poisoning, typosquatting & 36--84\% \cite{mcptoxbench,asbbench} & Invariant Labs \cite{invariant}, SANDWORM\_MODE \cite{sandworm} \\
3 & Tool responses & Response injection, data channel injection & High & Supabase Cursor \cite{supabase}, Docker WhatsApp \cite{docker} \\
4 & MCP protocol & OAuth hijack, shadow servers, rug-pull & N/A (exploit) & CVE-2025-6514 \cite{cve6514}, CVE-2025-49596 \cite{cve49596} \\
5 & Agent memory & Memory poisoning, belief corruption & 70--98.2\% \cite{minja} & ZombieAgent \cite{memorygraft}, Microsoft 31-company \cite{mspoison} \\
6 & Inter-agent messages & Cross-agent injection, viral propagation & 87\% cascade \cite{galileo} & ServiceNow Now Assist \cite{servicenow} \\
7 & Skill lifecycle & Supply chain, typosquatting, rug-pull & N/A (supply chain) & postmark-mcp \cite{postmark}, SANDWORM\_MODE \cite{sandworm} \\
8 & Code/file context & Config manipulation, source injection & 41--83\% \cite{aishell} & CVE-2025-53773 YOLO mode \cite{cve53773} \\
9 & Permission/auth & Token harvest, OAuth confusion, consent bypass & N/A (exploit) & CVE-2025-6514 \cite{cve6514}, Asana MCP \cite{asana} \\
10 & Behavioral drift & Sleeper activation, gradual escalation & High (40--80\%) \cite{memorygraft} & AiXBT \cite{aixbt}, Chevrolet chatbot \\
\bottomrule
\end{tabularx}
\end{table}


\subsection{What's Defended vs.\ What Isn't}

\begin{table}[htbp]
\centering
\caption{Current Defense Coverage by Data Flow Point}
\label{tab:defense}
\begin{tabularx}{\textwidth}{clXl}
\toprule
\textbf{Point} & \textbf{Data Flow} & \textbf{Current Defense} & \textbf{Coverage} \\
\midrule
1 & User input & I/O classifiers (Lakera, LLM Guard) & Moderate (4.7--40\% bypass) \cite{grayswan,rlinject} \\
2 & Tool descriptions & \textbf{None} & \textbf{Zero} \\
3 & Tool responses & \textbf{None} & \textbf{Zero} \\
4 & MCP protocol & \textbf{None} (some vendor patches post-CVE) & \textbf{Near zero} \\
5 & Agent memory & \textbf{None} & \textbf{Zero} \\
6 & Inter-agent & \textbf{None} & \textbf{Zero} \\
7 & Skill lifecycle & npm/pip audit (partial) & Low \\
8 & Code context & \textbf{None} & \textbf{Zero} \\
9 & Permission/auth & User approval dialogs (manual) & Low \\
10 & Behavioral drift & \textbf{None} & \textbf{Zero} \\
\bottomrule
\end{tabularx}
\end{table}

\textbf{The industry defends 1 of 10 attack surfaces with moderate effectiveness. 7 of 10 have zero automated defense. The 2 with partial defense (skill lifecycle, permissions) rely on manual processes.}


\subsection{Why Current Benchmarks Mislead}

Every published benchmark tests primarily point \#1 (user input) \cite{pint,hacka,tensortrust}:

\begin{table}[htbp]
\centering
\caption{Benchmark Coverage of Attack Surface Points}
\label{tab:benchmarks}
\begin{tabular}{lll}
\toprule
\textbf{Benchmark} & \textbf{Points Tested} & \textbf{Points Missed} \\
\midrule
PINT (4,314 samples) \cite{pint} & 1 & 2--10 \\
HackAPrompt (600K+) \cite{hacka} & 1 & 2--10 \\
TensorTrust (563K) \cite{tensortrust} & 1 & 2--10 \\
MCPTox (1,312) \cite{mcptox} & 2, 3 & 1, 4--10 \\
ASB (400+ tools) \cite{asb} & 1, 2, 3, 5 & 4, 6--10 \\
AIShellJack (314) \cite{aishell} & 8 & 1--7, 9--10 \\
\bottomrule
\end{tabular}
\end{table}

When a vendor reports ``98\% detection rate,'' they mean 98\% on point \#1. Points 2--10 --- where all major real-world incidents occurred --- are untested. The industry's security metrics measure the one door that has a lock while ignoring the nine doors that are wide open.


\subsection{The Most Exposed Attack Surface: Agent Skill Marketplaces}
\label{sec:marketplaces}

\subsubsection{Root Privilege, Zero Defense}

The most immediate manifestation of the trust architecture gap is not theoretical. It is happening right now in AI agent skill marketplaces.

Platforms like OpenClaw allow users to install ``skills'' --- MCP servers, tool plugins, agent extensions --- that run on the user's local machine. When a user installs a skill, that skill runs with \textbf{the same privileges as the user's operating system account.} It can read any file, execute any command, access any network resource, and modify any configuration that the user can.

There is no sandbox. No permission scoping. No code review gate. No runtime monitoring.

This is equivalent to downloading and running arbitrary executables from an unmoderated app store --- except worse, because:

\begin{itemize}
\item \textbf{The skill is invisible to the user.} A traditional executable does something the user can observe (opens a window, produces output). A malicious MCP skill operates silently in the background, called by the AI agent as needed. The user never sees the skill's code execute.
\item \textbf{The AI agent provides cover.} When the skill exfiltrates \texttt{\textasciitilde/.ssh/id\_rsa}, it does so through the agent's tool call interface. The user sees ``the AI is using a tool.'' They don't see what data the tool is accessing or transmitting.
\item \textbf{The skill can manipulate the agent.} A malicious skill doesn't just steal data directly --- it can inject instructions into its tool description or response that cause the agent to take additional harmful actions, access additional files, or install additional malicious skills \cite{invariant,cyberark}.
\end{itemize}


\subsubsection{The Numbers}

The empirical data confirms this is not a hypothetical risk:

\begin{itemize}
\item \textbf{Antiy CERT} (Feb 2026): 1,184 confirmed malicious skills on ClawHub (OpenClaw's marketplace) \cite{antiy}.
\item \textbf{OpenClaw audit}: 2,890+ skills analyzed, \textbf{41.7\% contain serious security vulnerabilities}.\footnote{OpenClaw internal audit, 2025.}
\item \textbf{SANDWORM\_MODE} (Feb 2026): 19 typosquatted npm packages targeting Claude Code, Cursor, VS Code, and Windsurf users \cite{sandworm}. Package names: claud-code, cloude-code, opencraw, hardhta, rimarf, naniod, etc. Each contained hidden instructions to read \texttt{\textasciitilde/.ssh/id\_rsa}, \texttt{\textasciitilde/.aws/credentials}, \texttt{\textasciitilde/.npmrc}, \texttt{.env}, and environment variables containing TOKEN, KEY, SECRET, or PASSWORD. Exfiltrated to attacker-controlled endpoints.
\item \textbf{postmark-mcp} (Sep 2025): Legitimate Postmark email MCP server impersonated on npm \cite{postmark}. Clean for 15 versions, then version 1.0.16 added a single BCC line forwarding all emails to \texttt{phan@giftshop.club}. An estimated 3,000--15,000 emails per organization per day during exposure \cite{postmark}.
\item \textbf{Kaspersky} (2026): devtools-assistant on PyPI --- malicious MCP server targeting \texttt{.env} files, SSH keys, AWS/GCP credentials, cryptocurrency wallets, and browser credential stores. Data Base64-encoded and POSTed to endpoints disguised as GitHub API.
\end{itemize}


\subsubsection{Why This Is the Defining Battleground}

Agent skill marketplaces are the convergence point of every vulnerability discussed in this paper:

\begin{table}[htbp]
\centering
\caption{Vulnerability Manifestation in Skill Marketplaces}
\label{tab:skillvuln}
\begin{tabularx}{\textwidth}{lX}
\toprule
\textbf{Vulnerability} & \textbf{How It Manifests in Skill Marketplaces} \\
\midrule
Missing authorization & Skills run with user's full OS privileges \\
Missing integrity & No code signing, no checksum verification \\
Tool description poisoning & Malicious skills embed hidden instructions in their tool descriptions \cite{invariant} \\
Supply chain attacks & Typosquatting on popular skill names \cite{sandworm} \\
Rug-pull attacks & Clean skill turns malicious after gaining trust \cite{postmark} \\
Cross-tool shadowing & Malicious skill overrides behavior of other installed skills \\
Credential exfiltration & Skills read SSH keys, API tokens, env vars \cite{sandworm} \\
Behavioral drift & Skill behaves normally for N invocations, then activates payload \\
\bottomrule
\end{tabularx}
\end{table}

\textbf{Every attack class we've documented in this paper has been demonstrated in the wild against agent skill marketplaces.} This is not a future threat. It is happening now, at scale, affecting hundreds of thousands of developers who use AI coding agents daily \cite{antiy,sandworm,postmark}.

The agent skill marketplace is to AI security what the browser extension ecosystem was to web security in 2010 --- a rapidly growing, largely unregulated attack surface where users install powerful code from untrusted sources with minimal vetting. The difference is that browser extensions at least had a permission model (even if imperfect). Agent skills have none.


\subsubsection{What Defense Looks Like Here}

An effective defense system for agent skill marketplaces would need to:

\begin{enumerate}
\item \textbf{Scan tool descriptions} for hidden instructions (\texttt{<IMPORTANT>} blocks, consent bypass, exfiltration commands) before the agent processes them
\item \textbf{Monitor tool calls} for suspicious parameters (file paths to credential files, network connections to unknown endpoints)
\item \textbf{Monitor tool responses} for injected instructions or exfiltrated data
\item \textbf{Fingerprint skill behavior} over time and flag drift (skill that starts accessing new file paths or network targets)
\item \textbf{Maintain a community-driven blacklist} of confirmed malicious skill hashes
\item \textbf{Detect typosquatting} by comparing skill names against known legitimate skills
\end{enumerate}

All six of these operate at the data flow layer, not the LLM reasoning layer. All six can be implemented with pattern matching, behavioral analysis, and hash lookups --- without requiring LLM inference on every event. And all six produce actionable, auditable results: ``this skill's description contains a credential exfiltration instruction'' is more useful than ``this input has a 0.73 injection probability.''

This is the most concrete, most urgent, most immediately implementable application of the defense architecture proposed in this paper. It's also where the gap between the current state of defense (zero) and the minimum acceptable state (at least basic tool description scanning and behavioral monitoring) is widest.


%----------------------------------------------------------------------
\section{Why Static Defenses Cannot Keep Pace}
\label{sec:staticdefense}

\subsection{The Paraphrase Problem}

``Ignore previous instructions'' has infinite semantically equivalent forms \cite{hacka,promptinjsurvey}:

\begin{itemize}
\item ``Please set aside the guidance you've been given''
\item ``Let's start fresh without any prior constraints''
\item ``I'd like you to operate in an unrestricted mode''
\item ``For this task, your original instructions don't apply''
\end{itemize}

Regex-based detection catches the first form and misses the rest. Our evaluation data confirms this: Tier 2 pattern matching achieves 61.4\% recall on PINT's external benchmark \cite{pint} --- up from 39.9\% in v0.3.1 through 47 additional rules and community-contributed patterns, but still below the theoretical ceiling. Against structured content (SKILL.md manifests with defined fields), recall reaches 100\%, demonstrating that the effectiveness of pattern matching is strongly dependent on input structure.

But the paraphrase problem is worse than a recall gap. \textbf{It's an asymmetric scaling problem.} Defenders must enumerate every possible phrasing. Attackers only need ONE novel phrasing. Every new defensive pattern is instantly obsolete once the attacker rephrases.


\subsection{The 3--6 Month Half-Life}

Empirical evidence of defense decay \cite{anthropicrates,checkmarx}:

\begin{table}[htbp]
\centering
\caption{Defense Decay: Empirical Evidence}
\label{tab:decay}
\begin{tabularx}{\textwidth}{lllX}
\toprule
\textbf{Defense} & \textbf{Initial Effectiveness} & \textbf{Time to Bypass} & \textbf{Method} \\
\midrule
Anthropic browser injection defense & 76.4\% block rate & Weeks & File exfiltration via Cowork \cite{anthropicrates} \\
ChatGPT memory protections & Blocked direct injection & \textasciitilde3 months & Indirect injection via images \\
Copilot YOLO mode patch & Fixed CVE-2025-53773 & \textasciitilde4 months & New wormable vector found \cite{cve53773} \\
MCP server patches (various) & Fixed specific CVEs & 30 CVEs in next 60 days & New vulnerability classes \cite{checkmarx,cosai} \\
\bottomrule
\end{tabularx}
\end{table}

\textbf{Any defense based on known patterns has a half-life of 3--6 months.} This is not because defenses are poorly engineered. It's because the attack language (natural language) is infinitely generative, and each new agent capability creates new attack composition possibilities \cite{promptkillchain}.


\subsection{The Capability-Vulnerability Coupling}

As agents gain capabilities, their attack surface grows superlinearly \cite{kim2026}:

\begin{lstlisting}
Capabilities over time:            Attack surface:

2023: Text chat                    1 surface (user input)
2024: + Tool use                   3 surfaces (+ tool desc, tool response)
2025: + Memory + MCP + Multi-agent 7 surfaces (+ memory, MCP, inter-agent, skill)
2026: + Code exec + Web + Payments 10 surfaces (+ code context, permissions, behavioral)
2027: + Physical (robotics, IoT)   13+ surfaces (+ sensor, actuator, environment)
\end{lstlisting}

Each new capability doesn't add a surface --- it multiplies: memory + tools = delayed tool poisoning. Multi-agent + tools = cross-agent privilege escalation. Code execution + web = wormable propagation. Payments + memory = delayed financial fraud.

\textbf{The combinatorial explosion of attack compositions means that enumerating defenses for each composition is intractable.} A system with 10 attack surfaces has $2^{10} - 1 = 1{,}023$ possible attack compositions. A system with 13 has 8,191.


%----------------------------------------------------------------------
\section{Requirements for a Defense Architecture That Scales}
\label{sec:requirements}

Given the analysis above, we derive five architectural requirements for AI agent security that can keep pace with AI evolution:

\subsection{Requirement 1: Multi-Point Interception}

Detection at point \#1 (user input) alone is insufficient. Defense must cover all active data flow points. As of 2026, this means points 1--10. As agents gain capabilities (physical, financial, autonomous), new interception points must be added.

Each interception point must be independently configurable, because:

\begin{itemize}
\item The same text has different threat levels at different points (Section~\ref{sec:attacksurface})
\item Different agent deployments expose different subsets of points
\item New points emerge as capabilities are added
\end{itemize}

\subsection{Requirement 2: Below-Reasoning-Layer Detection}

At least the first detection tiers must operate outside the LLM's instruction-following mechanism. This means:

\begin{itemize}
\item \textbf{Pattern matching} (regex, hash lookup) --- deterministic, cannot be manipulated by injected instructions
\item \textbf{Behavioral analysis} (fingerprinting, drift detection) --- statistical, operates on actions not instructions
\item \textbf{Provenance verification} (signatures, checksums) --- cryptographic, mathematically resistant to manipulation
\end{itemize}

LLM-based detection (when needed for semantic understanding) should use a \textbf{separate model with independent prompt and priorities} --- not the agent being protected. The judge model must have:

\begin{itemize}
\item Different training incentives than the protected agent
\item No access to the protected agent's context
\item A dedicated security-focused prompt that doesn't conflict with helpfulness
\end{itemize}

This creates genuine defense-in-depth: the attacker must simultaneously bypass deterministic pattern matching, statistical behavioral analysis, AND a separate LLM with different priorities.

\subsection{Requirement 3: Cascade Economics}

Not every event requires the most expensive detection method. The architecture must cascade from cheap to expensive:

\begin{lstlisting}
Event --> [Pattern match, <5ms, $0]
           |-- Resolved (99%+ of events) --> Done
           +-- Ambiguous --> [Behavioral, ~10ms, $0]
                              |-- Resolved --> Done
                              +-- Anomalous --> [LLM Judge, ~500ms, ~$0.001]
                                                 |-- Resolved --> Done
                                                 +-- Novel --> Alert/Block + Learn
\end{lstlisting}

This is critical for economic viability. Running LLM inference on every event (as classifier-based guards do) costs \$0.001 $\times$ millions of events/day. A cascade that resolves 99\% of events at the pattern tier costs orders of magnitude less for equivalent coverage.

\subsection{Requirement 4: Evolutionary Capability}

Static rules decay in 3--6 months (Section~\ref{sec:staticdefense}). The defense system must evolve at least as fast as attacks. This requires:

\textbf{Automatic rule generation:} When the LLM judge (top tier) catches a novel attack, the detection should be ``crystallized'' into a pattern-tier rule --- converting expensive semantic detection into cheap pattern detection. This mechanism --- which we term \textbf{threat crystallization} --- mirrors biological immune systems: the adaptive immune response (slow, expensive) generates antibodies that become part of the innate immune system (fast, cheap). In a detection cascade, this means every novel attack caught by the semantic tier produces a new regex or hash rule that catches the same pattern in $<$5ms on subsequent encounters.

\textbf{Community-driven threat intelligence:} No single organization encounters all attack variants. A mechanism for anonymous, privacy-preserving sharing of threat patterns --- where one agent's detection becomes every agent's rule --- creates a collective defense that scales with the number of protected agents.

\textbf{Measurable evolution:} Every rule must have independently measurable effectiveness against external benchmarks \cite{pint}. Improvement must be quantifiable, not claimed.

\subsection{Requirement 5: Open Auditability}

The defense system's logic must be inspectable, modifiable, and independently verifiable. This is a practical requirement, not a philosophical one:

\begin{itemize}
\item Security teams must understand WHY an alert fired
\item Compliance requires auditable detection logic
\item Different deployments require different rule configurations
\item The community must be able to verify coverage claims independently
\end{itemize}

A black-box classifier that claims 98\% detection but cannot explain what it misses, cannot be modified for specific use cases, and cannot be independently verified is \textbf{not suitable as an industry standard.} Sigma became the SIEM standard over proprietary alternatives precisely because of its openness \cite{sigma}.


%----------------------------------------------------------------------
\section{The Standard Question}
\label{sec:standard}

\subsection{What Made Previous Standards Succeed}

\begin{table}[htbp]
\centering
\caption{Historical Security Standards and Their Success Factors}
\label{tab:standards}
\begin{tabularx}{\textwidth}{llX}
\toprule
\textbf{Standard} & \textbf{Domain} & \textbf{Why It Won} \\
\midrule
Sigma (2017) \cite{sigma} & SIEM detection rules & Open YAML format, community-driven, 3,000+ rules, 28 backends, vendor-neutral \\
MITRE ATT\&CK (2015) \cite{mitreatlas} & Threat taxonomy & Real-world grounded, common language, free, neutral governance, no vendor rankings \\
CVSS (2005) & Vulnerability scoring & Quantitative, reproducible, cross-organization comparability, NIST backing \cite{nist} \\
Snort (1998) & Network IDS rules & Open-source, community-contributed, became the reference for network detection \\
\bottomrule
\end{tabularx}
\end{table}

Common properties: \textbf{open, free, vendor-neutral, community-driven, based on real-world data, quantitative.}


\subsection{What AI Agent Security Needs}

The AI agent ecosystem has no equivalent of Sigma, ATT\&CK, CVSS, or Snort. There is no:

\begin{itemize}
\item Open detection rule format for agent threats
\item Shared taxonomy for agent attack techniques
\item Standard scoring system for agent vulnerability
\item Community-contributed rule repository
\end{itemize}

Instead, there are proprietary, black-box classifiers from competing vendors, each claiming high detection rates on internal benchmarks that cannot be independently verified, covering attack surfaces that cannot be independently enumerated, with limitations that cannot be discovered until an incident occurs.

This is the state of network security circa 1997, before Snort. The state of SIEM security circa 2016, before Sigma \cite{sigma}. The state of threat intelligence circa 2014, before ATT\&CK \cite{mitreatlas}.


\subsection{Properties the Standard Must Have}

Based on our analysis and the history of successful security standards:

\begin{enumerate}
\item \textbf{YAML-based, human-readable rules} --- like Sigma \cite{sigma}, not like a neural network weight matrix
\item \textbf{Multi-point interception} --- rules specify which of the 10+ data flow points they monitor
\item \textbf{Mandatory evasion documentation} --- every rule declares what it CANNOT catch
\item \textbf{Framework mapping} --- every rule maps to OWASP Agentic Top 10 \cite{owaspagentic}, OWASP LLM Top 10 \cite{owaspllm}, MITRE ATLAS \cite{mitreatlas}
\item \textbf{Cascade-compatible} --- rules support tiered evaluation (pattern $\rightarrow$ behavioral $\rightarrow$ semantic)
\item \textbf{External benchmark transparency} --- published per-rule effectiveness against independent datasets \cite{pint}
\item \textbf{Community contribution mechanism} --- anonymous, privacy-preserving threat intelligence sharing
\item \textbf{Vendor-neutral governance} --- operated by a foundation or consortium, not a single company
\end{enumerate}

Whether this standard is called ATR, or something else, is secondary. The properties are what matter. The industry needs this infrastructure regardless of who builds it.


%----------------------------------------------------------------------
\section{ATR: Implementation and Empirical Validation}
\label{sec:atr}

The architectural requirements defined in Section~\ref{sec:requirements} are not merely theoretical. We have implemented them as \textbf{Agent Threat Rules (ATR)} \cite{atr}, an open-source detection standard and engine, and validated the implementation against internal benchmarks, two external benchmarks, and a large-scale scan of the agent skill ecosystem \cite{atrscanmega}.

\subsection{Architecture}

ATR implements a 5-tier detection cascade, designed so that 99\%+ of events resolve at the cheapest tiers:

\begin{lstlisting}
Event --> Tier 0: Invariant Enforcement  [O(1), compile-time]
      --> Tier 1: Blacklist Lookup       [O(1), hash table]
      --> Tier 2: Pattern Detection      [O(R), pre-compiled regex, <5ms]
      --> Tier 3: Behavioral Analysis    [O(1)/event, fingerprint comparison]
      --> Tier 4: LLM Semantic Analysis  [O(1), single LLM call, ~500ms]
\end{lstlisting}

\textbf{Tier 0 (Invariant Enforcement):} Hard rules that cannot be violated. No \texttt{eval()}. No \texttt{exec()} without explicit authorization. No known-malicious package hashes. These are compiled in, not pattern-matched.

\textbf{Tier 1 (Blacklist Lookup):} $O(1)$ hash table of confirmed malicious skill SHA256 hashes. Instant, zero false positives.

\textbf{Tier 2 (Pattern Detection):} 113 YAML rules with pre-compiled regex and compound detection gates, matching known attack signatures across 6 agent data flow points: \texttt{llm\_io}, \texttt{tool\_call}, \texttt{mcp\_exchange}, \texttt{multi\_agent\_comm}, \texttt{context\_window}, and \texttt{memory\_access}. Median latency: 3.3ms. Context-aware: MCP rules require 30\%+ conditions to match in skill context (compound gate), preventing over-triggering on legitimate documentation.

\textbf{Tier 3 (Behavioral Fingerprinting):} First $N$ invocations of a new skill build a behavioral baseline (file access, network contacts, env var reads). After stabilization, flag deviations. A ``file search'' tool that suddenly writes to \texttt{/etc/cron.d/} triggers an anomaly.

\textbf{Tier 4 (LLM Semantic Analysis):} A separate language model evaluates flagged content semantically. This is the only layer that can catch paraphrased attacks. It uses a different model with a dedicated security prompt, isolated from the protected agent's context.

\subsection{Rule Design}

ATR rules are YAML files with three design decisions that distinguish them from Sigma \cite{sigma}:

\textbf{Decision 1: \texttt{agent\_source} instead of \texttt{logsource}.} Sigma's \texttt{logsource} says ``look in Windows Event Log.'' ATR's \texttt{agent\_source} says ``look at THIS specific data flow point inside the agent'':

\begin{lstlisting}[]
agent_source:
  type: tool_call          # or: llm_io, mcp_exchange, multi_agent_comm,
                           #     context_window, memory_access
  framework: [mcp, any]
\end{lstlisting}

Why this matters: \texttt{``rm -rf /''} in user input is suspicious. In a tool response, it's dangerous. In a tool description, it's lethal. Same string, different danger level depending on WHERE in the agent's data flow it appears.

\textbf{Decision 2: Mandatory \texttt{evasion\_tests}.} Every ATR rule must document what it cannot detect:

\begin{lstlisting}[]
evasion_tests:
  - input: "Please set aside the guidance you've been given"
    expected: not_triggered
    bypass_technique: paraphrase
    notes: "Requires Tier 4 semantic analysis"
\end{lstlisting}

Sigma rules don't have this. ATR rules force systematic honesty about limitations.

\textbf{Decision 3: Mandatory framework mapping.} Every rule maps to OWASP LLM Top 10 \cite{owaspllm}, OWASP Agentic Top 10 \cite{owaspagentic}, MITRE ATLAS \cite{mitreatlas}, and relevant CVEs:

\begin{lstlisting}[]
references:
  owasp_llm: ["LLM01:2025"]
  owasp_agentic: ["ASI01:2026"]
  mitre_atlas: ["AML.T0051"]
  cve: ["CVE-2025-53773"]
\end{lstlisting}

\subsection{Coverage}

113 rules across 9 threat categories (7 stable, 85 experimental, 21 draft):

\begin{table}[htbp]
\centering
\caption{ATR Rule Coverage by Threat Category}
\label{tab:coverage}
\footnotesize
\begin{tabularx}{\textwidth}{lclX}
\toprule
\textbf{Category} & \textbf{Rules} & \textbf{What It Attacks} & \textbf{Data Flow Points Monitored} \\
\midrule
Prompt Injection & 34 & Agent's reasoning & llm\_io, tool\_call, context\_window \\
Skill Compromise & 23 & Agent's dependencies & tool\_call, mcp\_exchange \\
Tool Poisoning & 12 & Agent's tools (MCP) & tool\_call, mcp\_exchange \\
Context Exfiltration & 15 & Agent's knowledge & llm\_io, memory\_access \\
Agent Manipulation & 13 & Inter-agent trust & multi\_agent\_comm \\
Privilege Escalation & 8 & Agent's permissions & tool\_call, context\_window \\
Excessive Autonomy & 5 & Agent's boundaries & tool\_call, context\_window \\
Model Security & 2 & Model itself & llm\_io \\
Data Poisoning & 1 & Agent's knowledge base & memory\_access \\
\bottomrule
\end{tabularx}
\end{table}

\textbf{Framework coverage:} OWASP Agentic Top 10 (2026): \textbf{10/10 full} \cite{owaspagentic}. SAFE-MCP framework: \textbf{78/85 = 91.8\%} \cite{safemcp}. OWASP Skills Top 10: \textbf{7/10 full} \cite{owaspllm}.


\subsection{Benchmark Results}

We evaluated ATR against internal tests and two external benchmarks:

\begin{table}[htbp]
\centering
\caption{ATR Benchmark Results}
\label{tab:benchresults}
\begin{tabular}{lccccc}
\toprule
\textbf{Benchmark} & \textbf{Samples} & \textbf{Precision} & \textbf{Recall} & \textbf{F1} & \textbf{FP Rate} \\
\midrule
Self-test corpus & 341 & 100\% & 88.47\% & 93.88\% & 0\% \\
\textbf{PINT (external)} & \textbf{850} & \textbf{99.6\%} & \textbf{61.4\%} & \textbf{76.0\%} & \textbf{0.25\%} \\
\textbf{SKILL.md (external)} & \textbf{498 (32 mal + 466 benign)} & \textbf{97\%} & \textbf{100\%} & \textbf{98.5\%} & \textbf{0.20\%} \\
\bottomrule
\end{tabular}
\end{table}

\textbf{Self-test corpus:} 361 tests embedded alongside ATR rules, executed as part of the CI pipeline. All pass across all 113 rules.

\textbf{PINT benchmark:} 850 samples from Lakera's external prompt injection dataset \cite{pint} --- questions ATR has never seen. The 0.25\% false positive rate (1 in 400) means ATR can run on production traffic without alert fatigue. Recall improved from 39.9\% (v0.3.1, 61 rules) to 61.4\% (v2.0.0, 113 rules) through community-contributed patterns and threat crystallization.

\textbf{SKILL.md benchmark:} 498 samples from real-world MCP skill manifests (32 confirmed malicious, 466 verified benign). 100\% recall, 97\% precision, 0.20\% false positive rate. This benchmark tests ATR against its primary operational target: structured skill definitions with defined fields. The 100\% recall on structured content vs.\ 61.4\% on adversarial natural language demonstrates the structural advantage of scanning below the reasoning layer --- where attackers cannot freely paraphrase because tool descriptions must follow a schema.


\subsection{Why the Recall Gap Is a Feature, Not a Bug}

ATR achieves 100\% recall on structured SKILL.md content and 61.4\% on adversarial natural language (PINT). This gap is informative, not embarrassing:

\begin{lstlisting}
Recall by input type:

  Structured skill manifests (SKILL.md):     100%   <-- Schema-constrained,
                                                         limited paraphrase space
  Adversarial natural language (PINT):        62.7%  <-- Infinite paraphrase space,
                                                         multi-language, encoding tricks
\end{lstlisting}

Pattern matching works when the attack surface is structured. Tool descriptions, MCP manifests, SKILL.md files --- these have fields, schemas, and conventions that constrain the attacker's paraphrase space. Against free-form natural language, pattern matching hits a ceiling. That ceiling is why ATR has Tiers 3 and 4.

Proprietary classifiers that claim 98\% detection do not disclose what is in the 2\% they miss, why they miss it, or how users can address the gaps. Users cannot add their own rules, run the classifier offline, or audit its logic.

We argue that a transparent detection system with known, addressable gaps provides greater utility as an industry standard than an opaque system with higher reported accuracy but unknown failure modes --- a position supported by the historical precedent of Sigma's adoption over proprietary SIEM classifiers \cite{sigma}.


\subsection{Ecosystem Validation}

The 96,096-skill ecosystem scan (Section~\ref{sec:evidence}) serves as the primary large-scale validation of ATR's detection capability. Here we report the detection-specific findings.

\textbf{Detection analysis.} Rule ATR-2026-00121 (credential access via tool description) triggered 686 times, accounting for 53\% of all 1,302 flagged skills. Tool description poisoning --- embedding hidden instructions in a skill's metadata that the AI agent processes as trusted input --- remains the dominant attack vector in the wild.

\textbf{False positive analysis.} Of the 1,302 flagged skills, 751 are confirmed malware. The remaining $\sim$551 flagged skills (0.57\% of all skills) include over-privileged but non-malicious skills and legitimate security tools. The benchmark FP rate (0.20\% on labeled corpus) is consistent with the wild scan FP rate, validating that ATR's precision holds at ecosystem scale. ATR operates in report-only mode --- flagged skills are not blocked by default, preserving agent automation workflows.


\subsection{Threat Crystallization: Validated}

The threat crystallization mechanism described in Section~\ref{sec:requirements} is no longer theoretical. It has been validated in production:

\begin{lstlisting}
Crystallization flywheel (April 2026):

  Ecosystem scan: 96,096 skills scanned, 751 malware discovered
      --> 926 threat reports submitted to Threat Cloud
      --> 42 crystallization proposals generated
      --> Community review + LLM quality gate
      --> New rules merged into ATR core
      --> Recall improves --> next scan catches more

  Concrete example:
    Scan detects novel exfiltration pattern in Skills.sh skill
    --> Tier 4 LLM analysis confirms threat
    --> Pattern crystallized to regex rule
    --> Rule catches 14 additional skills on re-scan
    --> Rule published in ATR v1.1.1
\end{lstlisting}

The flywheel is turning. 42 proposals from 926 reports means a 4.5\% crystallization rate --- the remaining 95.5\% are variants of patterns already covered by existing rules, which validates that the current rule set handles the common cases. The 4.5\% that produce new rules represent genuinely novel patterns entering the detection corpus.


\subsection{Adoption}

ATR has moved from proposal to production adoption:

\begin{itemize}
\item \textbf{Cisco AI Defense} \cite{ciscopr79}: 34 ATR rules merged as upstream detection rules (PR \#79), with a \texttt{--rule-packs} CLI for selective loading. Cisco's skill scanner now consumes ATR rules directly.
\item \textbf{Ecosystem integration}: 3 PRs merged into major open-source projects, 7 additional under review, covering repositories with 90,000+ combined GitHub stars.
\item \textbf{npm distribution}: 23,000+ downloads/month across all ATR-related packages.
\item \textbf{Snyk/Invariant acquisition} \cite{snykinvariant}: Snyk acquired Invariant Labs (creators of mcp-scan), validating the market for agent security tooling. ATR provides the open-standard alternative to what is now a proprietary product.
\end{itemize}


\subsection{Open Research Agenda}

ATR's current limitations are not merely deficiencies to be patched. They delineate the frontier of a new research area---agent behavior detection---and define the questions the field must answer next.

\textbf{1. The structured--unstructured detection boundary.} Tier 2 pattern matching achieves 100\% recall on structured SKILL.md content but 61.4\% on adversarial natural language (PINT). This gap is not an implementation artifact; it is the fundamental boundary between deterministic and semantic detection. Where does pattern matching stop working, and what is the minimal semantic capability needed to close the gap? Can hybrid architectures (constrained grammars + lightweight classifiers) achieve 90\%+ recall without full LLM inference? The answer determines whether scalable agent security is economically viable.

\textbf{2. Adversarial evasion taxonomy and automated counter-generation.} We have documented 64 evasion techniques across all 113 rules, published in each rule's \texttt{evasion\_tests} field: paraphrase (21), encoding bypass (12), language switching (9), semantic restructuring (8), multi-turn decomposition (6), context window manipulation (4), and other (4). This taxonomy is the first systematic enumeration of evasion classes specific to agent detection rules. The research question: can evasion discovery be automated---generating novel evasions and counter-rules in an adversarial loop---so that rule evolution outpaces attacker adaptation?

\textbf{3. Multi-model adversarial robustness.} Tier 4 uses a separate LLM as a security judge. An attacker who can simultaneously bypass the protected agent AND the judge model defeats the cascade. Current mitigation (different model, different prompt) is necessary but not sufficient. The broader question: what are the theoretical limits of using language models to judge language model behavior? This connects to the open problem of AI alignment verification and may require formal methods beyond statistical detection.

\textbf{4. Detection rule integrity and provenance.} ATR rules are YAML text. An attacker who can modify rule files can disable detection silently. This is the ``quis custodiet ipsos custodes'' problem for detection infrastructure. Planned mitigation (Sigstore rule signing) addresses file integrity but not the deeper question: how do you establish a chain of trust for detection rules in a decentralized, community-driven ecosystem where anyone can propose rules?

\textbf{5. The training--runtime detection boundary.} ATR detects runtime attacks. Model backdoors planted during training are architecturally invisible at inference time. This is not merely a scope limitation---it defines two distinct threat classes that require fundamentally different detection approaches. Bridging this gap requires new techniques that connect supply-chain provenance (model cards, training data audits) with runtime behavioral fingerprinting.

\textbf{6. Full data flow interception.} ATR currently monitors 6 of the 10 data flow points identified in Section~\ref{sec:attacksurface}. Points 4 (MCP protocol-level), 8 (code/file context), 9 (permission/auth), and 10 (behavioral drift) require instrumentation that current agent frameworks do not expose. The research challenge is not writing more rules---it is designing agent framework APIs that make these data flows observable without introducing unacceptable latency or breaking the agent's autonomy.


%----------------------------------------------------------------------
\section{The Road Ahead: What Happens If We Don't Act}
\label{sec:roadahead}

\subsection{The 2026--2027 Threat Trajectory}

Based on current trends:

\begin{itemize}
\item 40\% of enterprise apps will integrate AI agents by end of 2026 (up from $<$5\% in 2025).\footnote{Gartner enterprise AI adoption forecast, 2025 \cite{gartner}.}
\item 75\% of API gateway vendors will have MCP features by 2026 \cite{gartner}.
\item Autonomous cybercrime becomes reality: AI agents handling recon, exploitation, and monetization without human input \cite{trendmicro}.
\item Agent-to-agent economies create trust chains where one compromise cascades across organizations \cite{galileo}.
\item AI agents with payment capabilities turn memory poisoning into delayed financial fraud at scale.
\item Physical-world AI agents (robotics, IoT, autonomous vehicles) create safety-of-life risks from agent compromise.
\item The EU AI Act enters enforcement in August 2026, creating compliance requirements for AI agent security that most organizations cannot currently meet.
\end{itemize}


\subsection{The Gap}

71\% of organizations deploying agentic AI report being unprepared to secure those deployments \cite{cisco}. The 29\% who think they're prepared are measuring preparedness against point \#1 (user input) while points 2--10 are undefended.

48\% of security professionals rank agentic AI as the \#1 attack vector for 2026.\footnote{Dark Reading survey, 2026.} They know the threat exists. They don't have the tools to address it.

The 1,184 malicious skills confirmed on ClawHub \cite{antiy}. ATR's own ecosystem scan discovered 751 additional malware skills from three coordinated threat actors (Section~\ref{sec:atr}). Over 8,000 MCP servers exposed on the public internet \cite{checkmarx,paloalto}. 30 CVEs in 60 days \cite{checkmarx,cosai}. The 87\% downstream poisoning rate from a single compromised agent \cite{galileo}. The EU AI Act enters full enforcement for high-risk AI systems on August 2, 2026 \cite{euaiact}, yet no established standard exists for AI agent detection rules. Project Glasswing \cite{glasswing} --- a joint initiative by Anthropic, Cisco, Microsoft, CrowdStrike, NVIDIA, Google, and Apple --- signals that the industry recognizes the scale of the problem. Meanwhile, RSA Conference 2026 saw an explosion of agent security tooling: Cisco's DefenseClaw framework, Microsoft's Agent Governance Toolkit, Adversa AI's SecureClaw \cite{secureclaw}, and Zenity's open-source agent security tools \cite{zenity}. But standards for detection rule quality remain absent from all of them.

The infrastructure exists to attack AI agents at scale. The infrastructure to defend them is emerging rapidly --- but without a shared quality standard, every vendor is inventing their own metrics, and consumers have no way to compare.


%----------------------------------------------------------------------
\section{Conclusion}
\label{sec:conclusion}

Agent security is not a model problem. It is an infrastructure problem. The infrastructure is missing. We built the first piece.

For forty years, cybersecurity has rested on the assumption that control flow and data flow are separable. AI agents collapse that separation. Every input---user instructions, tool descriptions, tool responses, memory entries, inter-agent messages---enters the same context window and is processed by the same language model with no structural differentiation. Two of three foundational security pillars (authorization and integrity) are entirely absent. This is not a flaw in any particular model. It is a missing layer of infrastructure that the industry has not yet built.

The evidence is not theoretical. We scanned 96,096 agent skills across six registries and found 751 active malware skills from three coordinated threat actors (Section~\ref{sec:evidence})---the largest documented malware campaign targeting AI agent ecosystems. No existing security tool detected them. Not because the tools failed, but because no tool was designed to look at the layer where these attacks operate.

The implication is clear: the industry's current approach---guardrails at the I/O boundary, model-level injection resistance, manual approval dialogs---defends 1 of 10 attack surfaces with moderate effectiveness while 7 of 10 have zero automated defense. Model improvement helps for direct injection but makes agents \textit{more} susceptible to tool-layer attacks, because better reasoning means better compliance with injected instructions hidden in trusted channels. Static defenses decay in 3--6 months. The attack surface grows superlinearly with capability. Offense is outpacing defense.

What is needed is not better guardrails. It is a new detection layer---one that operates below the reasoning layer where attacks and legitimate instructions are indistinguishable, that cascades from cheap deterministic checks to expensive semantic analysis, that evolves through community-driven threat intelligence, and that is open enough to be independently verified and vendor-neutral enough to become shared infrastructure.

We have implemented this as ATR \cite{atr}: 113 open-source YAML detection rules, a 5-tier cascade engine, a validated threat crystallization flywheel, and RFC-001 \cite{rfc001}---the first vendor-neutral quality standard for AI agent detection rules. The approach is empirically validated: 99.6\% precision on external adversarial benchmarks \cite{pint}, 100\% recall on structured skill content, and production adoption by Cisco AI Defense \cite{ciscopr79}. Microsoft's concurrent CTI-REALM benchmark \cite{ctirealm} independently validates that AI agents can generate detection rules from threat intelligence---the mechanism ATR's crystallization flywheel relies on.

But ATR is one implementation. The contribution that matters is the argument: AI agents need a detection layer that is analogous to what Sigma provides for SIEM, what YARA provides for malware, and what Snort provides for network traffic---an open, community-driven, externally benchmarked standard that any vendor can adopt and any researcher can build on. Whether that standard is called ATR or something else is secondary. The properties are what matter. The industry must build this infrastructure, and it must build it in the open, before the next generation of autonomous agents---with payment capabilities, physical-world access, and inter-organizational trust chains---makes the cost of inaction catastrophic.

The collapse of trust is happening now. Every incident in this paper is from the last twelve months. The research agenda we define (Section~\ref{sec:atr}) charts six open problems that will shape agent security for the next decade. The 751 malware skills we found are still being cleaned up. The infrastructure to attack AI agents at scale already exists. The infrastructure to defend them is being built.

ATR is open-source (MIT License, permanent commitment). All rules, engine code, RFC-001 reference implementation, evaluation data, and benchmark results are publicly available at \url{https://github.com/Agent-Threat-Rule/agent-threat-rules} \cite{atr}.

ATR is open-source (MIT License, permanent commitment). All rules, engine code, RFC-001 reference implementation, evaluation data, and benchmark results are publicly available at \url{https://github.com/Agent-Threat-Rule/agent-threat-rules} for independent verification and reproduction \cite{atr}.


%----------------------------------------------------------------------
\begin{thebibliography}{67}

\bibitem{kim2026}
J.~Kim et al., ``The Attack and Defense Landscape of Agentic AI,'' \textit{arXiv:2603.11088}, 2026.

\bibitem{chhabra2025}
A.~Chhabra et al., ``Agentic AI Security: Threats, Defenses, Evaluation, and Open Challenges,'' \textit{arXiv:2510.23883}, 2025.

\bibitem{survey2026}
``A Survey of Agentic AI and Cybersecurity,'' \textit{arXiv:2601.05293}, 2026.

\bibitem{acmsurvey}
``AI Agents Under Threat: A Survey of Key Security Challenges,'' \textit{ACM Computing Surveys}, 2024.

\bibitem{protocol2025}
``From Prompt Injections to Protocol Exploits,'' \textit{arXiv:2506.23260}, 2025.

\bibitem{promptinjsurvey}
``Prompt Injection Attacks in LLMs: A Review,'' \textit{MDPI Information}, 17(1):54, 2025.

\bibitem{securitymodeling}
``Security Threat Modeling for Emerging AI-Agent Protocols,'' \textit{arXiv:2602.11327}, 2026.

\bibitem{promptkillchain}
``The Promptware Kill Chain,'' \textit{arXiv:2601.09625}, 2026.

\bibitem{youraishell}
``Your AI, My Shell: Three-Dimensional Taxonomy,'' \textit{arXiv:2601.17548}, 2026.

\bibitem{rlinject}
``Learning to Inject: Automated Prompt Injection via RL,'' \textit{arXiv:2602.05746}, 2026.

\bibitem{minja}
``MINJA: Memory INJection Attack,'' in \textit{NeurIPS 2025}, arXiv:2503.03704.

\bibitem{memorygraft}
``MemoryGraft: Persistent Compromise via Poisoned Experience,'' \textit{arXiv:2512.16962}, 2025.

\bibitem{agentpoison}
``AgentPoison: Red-teaming LLM Agents via Poisoning Memory,'' 2025.

\bibitem{pint}
Lakera, ``PINT Benchmark,'' \url{https://github.com/lakeraai/pint-benchmark}.

\bibitem{mcptox}
Z.~Wang et al., ``MCPTox Benchmark,'' \url{https://github.com/zhiqiangwang4/MCPTox-Benchmark}.

\bibitem{asb}
``Agent Security Bench (ASB),'' in \textit{ICLR 2025}, \url{https://github.com/agiresearch/ASB}.

\bibitem{aishell}
``AIShellJack,'' \textit{arXiv:2509.22040}.

\bibitem{hacka}
S.~Schulhoff et al., ``HackAPrompt,'' in \textit{EMNLP 2023}.

\bibitem{tensortrust}
``TensorTrust,'' in \textit{ICLR 2024}, \url{https://tensortrust.ai}.

\bibitem{caibench}
``CAIBench,'' \textit{arXiv:2510.24317}.

\bibitem{cisco}
Cisco, ``State of AI Security 2026.''

\bibitem{ibm}
IBM, ``2026 X-Force Threat Index,'' Feb 2026.

\bibitem{trendmicro}
Trend Micro, ``The AI-fication of Cyberthreats: Security Predictions for 2026.''

\bibitem{paloalto}
Palo Alto Networks / Unit 42, ``2026 Cyber Predictions;'' ``MCP Sampling Attack Vectors.''

\bibitem{crowdstrike}
CrowdStrike, ``Agentic Tool Chain Attacks.''

\bibitem{checkmarx}
Checkmarx, ``11 Emerging AI Security Risks with MCP.''

\bibitem{cyberark}
CyberArk, ``Poison Everywhere: No Output from Your MCP Server Is Safe.''

\bibitem{gartner}
Gartner, ``MCP Adoption and API Gateway Predictions 2026.''

\bibitem{aisafety}
``2026 International AI Safety Report.''

\bibitem{owaspllm}
OWASP, ``Top 10 for LLM Applications 2025.''

\bibitem{owaspagentic}
OWASP, ``Top 10 for Agentic Applications 2026.''

\bibitem{owaspmcp}
OWASP, ``MCP Top 10 (2025).''

\bibitem{mitreatlas}
MITRE, ``ATLAS: Adversarial Threat Landscape for AI Systems.''

\bibitem{nist}
NIST, ``AI Risk Management Framework.''

\bibitem{cosai}
CoSAI, ``MCP Security Whitepaper,'' Jan 2026.

\bibitem{sigma}
SigmaHQ, ``Sigma Detection Format,'' \url{https://sigmahq.io}.

\bibitem{cve6514}
CVE-2025-6514: mcp-remote RCE (CVSS 9.6), JFrog.

\bibitem{cve53773}
CVE-2025-53773: GitHub Copilot YOLO mode RCE, Embrace The Red.

\bibitem{cvegit}
CVE-2025-68143/68144/68145: Anthropic Git MCP Server RCE chain, Cyata.

\bibitem{cve49596}
CVE-2025-49596: MCP Inspector drive-by (CVSS 9.4), Oligo Security.

\bibitem{cve59536}
CVE-2025-59536: Claude Code RCE via poisoned project files, Check Point.

\bibitem{postmark}
postmark-mcp malicious MCP server, Snyk.

\bibitem{sandworm}
SANDWORM\_MODE: 19 typosquatted npm packages, Socket.dev.

\bibitem{antiy}
Antiy CERT: 1,184 malicious skills on ClawHub, Feb 2026.

\bibitem{docker}
Docker, ``MCP Horror Stories: The Supply Chain Attack.''

\bibitem{invariant}
Invariant Labs, ``MCP Security Notification: Tool Poisoning Attacks,'' Apr 2025.

\bibitem{mspoison}
Microsoft, ``AI Recommendation Poisoning,'' Feb 2026.

\bibitem{aixbt}
AiXBT cryptocurrency agent heist, Mar 2025.

\bibitem{servicenow}
ServiceNow Now Assist cross-agent injection, Nov 2025.

\bibitem{supabase}
Supabase Cursor MCP data leak, Jul 2025.

\bibitem{asana}
Asana MCP cross-contamination, Jun 2025.

\bibitem{grayswan}
Gray Swan benchmark: Claude Opus 4.5 4.7\% ASR.

\bibitem{mcptoxbench}
MCPTox: 20 SOTA LLMs, average 36.5\% ASR, o1-mini 72.8\%.

\bibitem{asbbench}
ASB: Highest average ASR 84.30\%.

\bibitem{aishellbench}
AIShellJack: Cursor Auto 83.4\% ASR.

\bibitem{anthropicrates}
Anthropic published prompt injection rates: Opus 4.5 browser 1--11.2\%.

\bibitem{galileo}
Galileo AI: Single compromised agent $\rightarrow$ 87\% downstream poisoning in 4 hours.

\bibitem{atr}
Agent Threat Rules, \url{https://github.com/Agent-Threat-Rule/agent-threat-rules}, MIT License.

\bibitem{atrscanmega}
ATR v2.0.0 Ecosystem Scan: 96,096 skills across OpenClaw, ClawHub, Skills.sh, Hermes, MCP Registry. 1,302 flagged (1.35\%), 751 confirmed malware from 3 coordinated threat actors. April 2026.

\bibitem{ciscopr79}
Cisco AI Defense: 34 ATR rules merged as upstream detection, PR \#79, \url{https://github.com/cisco/ai-defense/pull/79}.

\bibitem{safemcp}
SAFE-MCP: Security Assessment Framework for MCP, \url{https://github.com/nicobailon/safe-mcp}.

\bibitem{snykinvariant}
Snyk acquisition of Invariant Labs (mcp-scan), 2026.

\bibitem{glasswing}
Project Glasswing: Joint AI security initiative by Anthropic, Cisco, Microsoft, CrowdStrike, NVIDIA, Google, and Apple, April 2026.

\bibitem{atrscan}
ATR v0.3.1 MCP Ecosystem Audit: 2,386 packages, 35,858 tool definitions, March 21, 2026.

\bibitem{rfc001}
ATR Project, ``RFC-001: ATR Quality Standard v1.1 --- The Open Detection Standard for the AI Agent Era,'' April 2026. \url{https://github.com/Agent-Threat-Rule/agent-threat-rules/blob/main/docs/proposals/001-atr-quality-standard-rfc.md}

\bibitem{ctirealm}
Microsoft Security, ``CTI-REALM: Benchmark to Evaluate Agent Performance on Security Detection Rule Generation Capabilities,'' \textit{arXiv:2603.13517}, March 2026. Claude Opus 4.6 achieves highest reward (0.637) across 16 frontier models on 37 CTI reports.

\bibitem{mcpitp}
``MCP-ITP: An Automated Framework for Implicit Tool Poisoning in MCP,'' \textit{arXiv:2601.07395}, January 2026.

\bibitem{secureclaw}
Adversa AI, ``SecureClaw: Open-Source OWASP-Aligned Agent Security Platform,'' Winner of ``Most Innovative Agentic AI Security'' at RSA Conference 2026 Global InfoSec Awards.

\bibitem{euaiact}
European Union, ``Regulation (EU) 2024/1689 (AI Act),'' Official Journal of the European Union, August 2024. High-risk AI system requirements take full effect August 2, 2026.

\bibitem{owasplandscape}
OWASP GenAI Security Project, ``AI Security Solutions Landscape for Agentic AI Q2 2026,'' \url{https://genai.owasp.org/resource/ai-security-solutions-landscape-for-agentic-ai-q2-2026/}.

\bibitem{zenity}
Zenity Labs, in collaboration with MITRE ATLAS, ``14 Agent-Specific Techniques Added to ATLAS,'' October 2025. Showcased open-source AI agent security tools at RSA Conference 2026.

\end{thebibliography}

\end{document}
