Field Note 05 / AI Security

Nearly 4,000 AI Skills Scanned, 76 Were Malware. Who's Responsible?

Research Note 00 audited roughly 200 pre-built trading strategies and found public metrics repackaged behind paid interfaces. That was an economic audit. A newer audit asks a sharper question about the same marketplace model: not whether the code is worth paying for, but whether it is safe to run at all.

The numbers

A technical report posted to arXiv in May 2026 analyzed 3,984 AI agent skills across ClawHub and skills.sh. Its authors manually confirmed 76 unique malicious skill identities carrying credential theft, backdoor installation, data exfiltration, and other harmful behavior. The malicious logic appeared in instructions, scripts, and code—not in markdown alone.

The wider automated scan found 534 skills, or 13.4%, with at least one critical-level issue. That is not the same as saying 13.4% were confirmed malware: the critical category also included suspicious downloads and prompt-injection patterns requiring interpretation. At the time of the report, at least eight of the 76 manually confirmed malicious skills were still publicly available. Submission volume had accelerated from fewer than 50 skills a day in mid-January to more than 500 a day in early February.

Source: Beurer-Kellner et al., “Technical Report: Exploring the Emerging Threats of the Agent Skill Ecosystem” →.

A separate industry scan by Airia examined 46,316 skills collected from ClawHub and public GitHub repositories. It reported that 4,956, or 10.7%, failed its basic review. The failures clustered around two distinct problems: packages that shipped malicious behavior and packages that exposed live production credentials. This was a company-published scan rather than a peer-reviewed study, but its scale makes the result difficult to dismiss as a handful of isolated submissions.

Source: Airia, “Skills are the new supply chain. The marketplace is not ready.” →.

A badge is not an audit

The late-January ClawHavoc campaign placed hundreds of malicious packages into ClawHub. Later, researchers demonstrated a second problem: passing a scanner does not prove safe behavior. In a controlled experiment reported by CSO Online, AIR Security published a deliberately weaponized test skill that passed several static checks and reached more than 26,000 users. The researchers limited the payload and did not harm users, but the distribution result was real.

SkillCloak pushed the same point further. Researchers repackaged known malicious skills so their operational behavior stayed intact while static scanners increasingly classified them as clean. Obfuscation is not a theoretical edge case when the package can mix natural-language instructions, executable code, remote downloads, and configuration.

Sources: CSO Online — the 26,000-user controlled experiment →; Help Net Security — SkillCloak and scanner evasion →.

Who is actually checking?

Responsibility is fragmented. The publisher controls what ships. A marketplace controls admission, labeling, takedowns, and whether “verified” describes identity, functionality, or security. The agent vendor controls permission boundaries and warnings. The organization installing the skill controls access to files, credentials, networks, and production systems.

Those layers are not interchangeable. Anthropic, for example, says it reviews connectors against listing criteria before adding them to its directory, but does not security-audit or manage the underlying MCP servers. That statement is specifically about MCP servers, not every third-party skill marketplace. The practical trust boundary is still instructive: a listing is not a transfer of security responsibility.

Source: Anthropic, Claude Code security documentation →.

What this means practically

None of this is a reason to avoid skills and plugins altogether; this project uses them too. It is a reason to treat a skill like a third-party software dependency rather than a feature toggle.

Before installing one, verify who published it and whether that identity is meaningful. Compare requested permissions with the stated task. Read the instructions and bundled scripts. Check for remote downloads and undeclared network calls. Prefer marketplaces that publish their review methodology, not just a badge. Grant the smallest practical access, isolate execution when the data is sensitive, and assume an update can change the package after the first review.

A skill's markdown instructions deserve the same suspicion as executable code because, to the agent interpreting them, they can determine which tools are called and what data is touched. The scanner is one control. Permission boundaries, provenance, runtime isolation, monitoring, and human review are separate controls.

The pattern is the same one this series keeps returning to in trading strategies. A green backtest and a verified badge can both be literally true while creating a materially false impression. The useful question is not whether the label exists. It is what, exactly, was tested.