We Scanned 96,096 AI Agent Skills. 751 Were Malicious. Here Is What They Did.

I scanned 96,096 AI agent skills across six public registries and found 751 confirmed malicious. That is roughly 8 in every 1,000 skills you could install today carrying code designed to steal secrets, run remote payloads, or phone home to an attacker. None of them announced themselves. They looked like ordinary skills that do a useful thing, and they did that useful thing, plus one more.

This is a study of what those 751 actually did. The short version: the damage happens at install time, not at runtime. A skill's code runs when you install it, wire it into your agent, or first invoke it. By the time a runtime guard is watching an agent's tool calls, a malicious installer has already read your .env, decoded a base64 blob, and opened a socket to a hardcoded IP. The leverage point is scanning the artifact before it lands.

What is an AI agent skill and why is it a supply chain?

A skill (or an MCP server) is a package that extends an agent: a set of tools, instructions, and executable code that an agent like Claude Code, Cursor, or Windsurf loads and can invoke. You install it the same way you install any dependency. That is the problem. It is npm-shaped distribution with none of npm's decade of supply chain scar tissue, aimed at a runtime that holds your API keys, your shell, and your file system.

The registries are open. Anyone can publish. The install step frequently runs arbitrary code. And the thing consuming the skill is an autonomous agent with broad permissions, which is exactly the target profile an attacker wants. The six public registries in this scan span the major skill and MCP ecosystems, and 751 malicious artifacts across 96,096 is not a rounding error. It is a baseline infection rate.

What did the 751 malicious skills actually do?

The malicious behaviors fell into five recurring patterns. Most bad skills used more than one.

• ●Environment and secret exfiltration. The most common pattern by far. The skill reads process environment variables, .env files, or credential stores and ships them out. This is where your ANTHROPIC_API_KEY, cloud tokens, and database URLs leave the building. It is quiet because reading environment variables is a normal thing for legitimate code to do. The tell is what happens to the values next.
• ●Base64-encoded remote code execution. A payload is stored as a base64 (or similarly encoded) string, decoded at install or first run, and executed. Encoding defeats a human skimming the source and defeats naive keyword grep. eval(atob(...)) and its shell equivalents showed up repeatedly.
• ●Hardcoded suspicious IPs and callback hosts. Literal IP addresses and unfamiliar domains baked into the code, used as exfiltration endpoints or command-and-control callbacks. A skill that claims to format text has no business holding a raw IP and a socket call.
• ●Obfuscation. Minified one-liners, string-splitting, hex escapes, and layered encoding whose only purpose is to make the code unreadable to a reviewer. Obfuscation is not itself the attack. It is the wrapper that hides the four other patterns, and its mere presence in a small skill is a strong signal.
• ●Delayed and conditional backdoors. Logic that stays dormant until a condition is met: a date, an environment check, an Nth invocation. The skill behaves perfectly during your evaluation and turns hostile later. This is the pattern that beats manual review most reliably, because the review window and the attack window do not overlap.

Why is install-time scanning the leverage point?

Because the attack fires before runtime monitoring is even in the loop. Consider the real incidents already on record. The postmark-mcp server was a trusted, working MCP server that silently BCC'd between 3,000 and 15,000 emails a day to an attacker for fifteen versions before anyone noticed. MCPJam Inspector shipped a default 0.0.0.0 binding (CVE-2026-23744) that turned one HTTP request into remote code execution in every version before v1.4.3. Azure MCP Server had an SSRF (CVE-2026-26118) that stole managed-identity tokens. Claude Code itself had hooks and MCP config abused (CVE-2025-59536, CVE-2026-21852) for arbitrary shell execution and API key theft.

Every one of these is an artifact-level problem. The malicious behavior lives in the code you installed, and in several cases it ran or was reachable the moment you wired the thing in. A runtime guard that watches tool calls is necessary but it is second. The first line of defense is refusing to install the artifact in the first place.

That is the case for scanning at install time. You inspect the skill or MCP server as a static artifact: read its code, decode its encoded strings, resolve its network endpoints, flag its obfuscation, and match its behavior against known attack patterns. All of that is possible before the code ever runs, because the tells are in the source.

How do you scan a skill before you install it?

This is the problem ATR (Agent Threat Rules) exists to solve. ATR is an independent, open, MIT-licensed detection standard, the same way Sigma is an open standard for SIEM rules. It is a corpus of deterministic rules that encode agent-specific attack patterns: secret exfiltration, encoded payloads, suspicious callbacks, obfuscation signatures, and the rest. The corpus is 680+ rules across 10 categories as of July 2026, mapped to the OWASP Agentic Top 10 (all ten categories covered) and to MITRE ATLAS (34 of 101 techniques).

On the SKILL.md corpus of 498 real-world samples, ATR's Layer 1 deterministic rules hit 100% recall at 97% precision with a 0.2% false-positive rate. That is the exact shape of the install-time problem: real skills, scanned statically, before they run. Deterministic rules are the right tool here because they execute in milliseconds and give the same answer every time, which is what you need at an install gate.

PanGuard is the free, MIT-licensed tool built on and operating the ATR standard. Install it and scan a skill before you install that skill:

npm install -g @panguard-ai/panguard
pga up
pga scan <target>

pga scan inspects a skill or MCP server as a static artifact and reports which ATR rules it trips, before you ever wire it into your agent. Guard then handles runtime detection for what gets through. The whole thing is free and open source. Community is the complete product, no paywall.

What should you take away from 751 in 96,096?

Two things. First, the malicious skill is not a hypothetical. At roughly 8 per 1,000, if you have installed a couple hundred skills across your team you have very likely installed one. Second, the defense that matters most is the one that runs before the code does. Runtime monitoring catches the delayed backdoor eventually. Install-time scanning catches the whole taxonomy at the one moment when nothing has executed yet and every tell is still sitting in the source.

FAQ

How many malicious skills did the scan find, and out of how many?

751 confirmed malicious out of 96,096 AI agent skills scanned across six public registries. That is a baseline infection rate of roughly 8 per 1,000.

What was the most common malicious behavior?

Environment and secret exfiltration: reading .env files and process environment variables to steal API keys and cloud tokens, then shipping them to an attacker. It is common because reading environment variables looks legitimate on its own.

Why isn't runtime monitoring enough on its own?

Because a skill's code often runs at install or first invocation, before a runtime guard is watching. Real incidents like postmark-mcp and the MCPJam Inspector RCE (CVE-2026-23744) were artifact-level problems that fired before or independent of runtime tool-call monitoring.

Can I scan a skill before installing it, for free?

Yes. Install PanGuard (npm install -g @panguard-ai/panguard && pga up) and run pga scan <target> against the skill or MCP server. It is free and MIT-licensed, built on the open ATR standard, and Community is the complete product with no paywall.

Next step: before you install your next skill or MCP server, scan it. pga scan <target> takes seconds and reads the artifact against the open ATR rule corpus, which is the one check that runs before the code does.