· Security
30 ClawHub Skills Turned AI Agents Into a Crypto Swarm
Nine thousand eight hundred downloads, no malware, no exploit. Just skill files telling agents to register with a server and upload their own wallet keys.
TL;DR: Manifold Security's Ax Sharma uncovered 30 ClawHub skills that silently enrolled AI agents into a crypto-mining swarm called ClawSwarm. 9,800 downloads. No malware. No exploits. Just SKILL.md files telling agents to register with external servers, report capabilities, generate wallets, and accept remote tasks. The user never approved a single step. This is the npm leftpad moment for AI agent marketplaces. And the authorization industry is still building dashboards instead of door locks.
The first time an agent gets drafted
Imagine you install a VS Code extension that looks helpful. A cron helper, maybe, or a system monitor. It seems to work fine. Meanwhile, it's forwarding your terminal history to a server in another country.
That's what happened on ClawHub. Except it wasn't a human reading the terminal. It was an AI agent.
On April 29, 2026, Manifold Security published research identifying 30 ClawHub skills published by a single author (username "imaflytok") that collectively scored 9,800 downloads. These skills had innocuous names: a cron helper (903 downloads), an Agent Security skill (685 downloads), a whale watcher (347 downloads), a cross-platform poster (292 downloads). They looked like any other skill in the registry.
But after installation, the AI agent silently registered itself at a site called onlyflies.buzz. It reported its name, installed skills, and capabilities. Then it generated a Hedera crypto wallet and uploaded the private key to the same server. Every four hours, it checked back in for new instructions.
The Register covered the story in detail, and Manifold's full report walks through the entire attack chain. Sharma makes an important distinction: "ClawSwarm isn't a vulnerability disclosure. There's no flaw to patch and nothing covert about the infrastructure. It's an open source project on GitHub with public docs, a Telegram group, and a token on a public chain."
No flaw. No exploit. Just a system designed to let agents do whatever their skill files tell them to do.
This is a feature gap, not a bug
Here's what makes the ClawSwarm case different from everything before it.
The ClawHavoc campaign earlier this year involved actual malware: skills that installed keyloggers and information stealers. IBM X-Force counted over 1,100 malicious skills uploaded to ClawHub. That's bad, but it's a known problem: don't install untrusted binaries.
ClawSwarm is different. There's no binary. No exploit. Nothing that traditional antivirus would catch.
The skill files (SKILL.md documents) gave the AI agent instructions. The agent, being an autonomous system designed to follow instructions, followed them. It registered with an external server. It reported system state. It generated cryptographic keys. It saved them to disk.
At no point did the user approve any of this. At no point did the system ask: "Hey, is it okay if I create a crypto wallet and upload the private key to onlyflies.buzz?"
Manifold's Sharma put it plainly: "Whether ClawSwarm instances are a legitimate experiment in agent economics or a recruitment funnel for speculative crypto, the result for the user is the same: their agent is doing things they didn't ask it to do, for someone they don't know, with keys they didn't authorize."
Agent auth tools log that this happened. They don't stop it from happening.
The npm analogy that keeps me up at night
Security people love the npm leftpad analogy, so I'll lean in.
In 2016, a developer unpublished 11 lines of code called leftpad from npm. Thousands of projects broke. The JavaScript ecosystem learned that depending on a package you don't control means trusting it implicitly. The response was better tooling: npm audit, lockfiles, package signing, scoped packages.
But none of those tools prevent a package from executing malicious code once installed. They prevent you from accidentally depending on it. Once it's in your node_modules, it can run whatever it wants.
AI agent skills are the same, except worse. A malicious npm package can drain your wallet or exfiltrate your .env file. A malicious agent skill can register your agent as a node in a global botnet that generates cryptocurrency and makes network calls you can't see.
And here's the kicker: npm packages run in a sandboxed runtime. Agent skills run with the full permissions of the agent (file system, shell execution, network, browsers). IBM's analysis calls this the "lethal trifecta": deep private data access, interaction with untrusted external content, and the ability to communicate outward.
The npm ecosystem had 10 years to build tooling. Agent marketplaces have had about 10 weeks.
What pre-action authorization would have caught
Let me walk through the ClawSwarm attack chain and flag the exact moment where a pre-action authorization system stops it.
| Step | What happens | Auth check would catch |
|---|---|---|
| 1 | Skill installs, SKILL.md tells agent to reach onlyflies.buzz | DNS resolution to unknown domain needs approval |
| 2 | Agent reports its name and capabilities | Outbound data transfer needs approval |
| 3 | Agent generates Hedera wallet | Crypto wallet creation needs explicit policy |
| 4 | Agent uploads private key to server | Key upload to remote host is a clear policy violation |
| 5 | Agent checks in every 4 hours | Recurring outbound check-in needs approval |
Every step is something a human would say "wait, I didn't ask for that" to. Yet none of them trigger a prompt, a warning, or a policy check in the current architecture.
The agent security tools shipping today focus on auditing and observing. They tell you after the fact that your agent did something unexpected. That's useful for forensics. It's useless for prevention.
A pre-action authorization system, whether implemented as a passport model, a check-before-execution hook, or a policy gateway, would block step 1. The agent tries to resolve onlyflies.buzz. The system doesn't have a policy allowing this domain. It stops. Or it asks the user.
I wrote about pre-action authorization in detail earlier in this series, and the pattern hasn't changed: verify the action before the tool executes. Not after.
The hard truth: nobody wants to build this
Ask a platform how it prevents an installed skill from making unauthorized network calls and the answer is usually some form of "we audit agent actions and alert on anomalies." Ask how it stops the action before it happens and the answer is a product decision that has not been made.
The reluctance is understandable. Pre-action authorization slows down agents. It generates friction. It requires defining policies for actions that might not have clear allow/deny boundaries.
But here's what ClawSwarm proves: the user already doesn't know what their agent is doing. The only difference between "agent operating normally" and "agent running a crypto swarm" is whether someone with a keyboard decided to exploit the trust gap.
Manifold flagged this exact tension: "The mechanism is identical regardless of intent: an AI agent silently registering with a third party server, reporting its capabilities, generating crypto keys, and accepting remote tasks."
The mechanism doesn't know if it's a crypto experiment or a botnet. Neither does the agent. Neither does the user. The only thing that changes is intent, and intent is invisible to the runtime.
What marketplaces need to learn from this
Three things need to change, and they need to change before the next ClawSwarm variant ships.
Capability declarations for skills. Every skill should declare its required permissions: network access, file system write, wallet generation, browser automation. The agent runtime should enforce these boundaries, not trust the skill to be honest.
Pre-execution policy gates. Every tool call should pass through a policy evaluation layer before execution. The policy can be strict (always ask), granular (only allow on known domains), or learned (anomaly-based). But there must be a gate between instruction and action.
User-facing consent for privileged operations. Wallet generation should require user approval. Connecting to a new external host should require approval. Uploading private keys should require approval. This isn't unreasonable. Your phone asks you every time an app wants your location.
OX Security's analysis of the broader MCP supply chain shows that the STDIO interface passes arbitrary commands to execution with zero sanitization. ClawSwarm didn't exploit MCP directly, but the same architectural assumption underlies both problems: the system trusts the instruction source.
The window is closing
The ClawSwarm campaign scored 9,800 downloads. That's 9,800 agents that silently enrolled themselves in someone else's network. The next campaign might not be about crypto farming.
AI agent marketplaces are growing fast. OpenClaw hit 135,000 GitHub stars in weeks. Censys counted 21,639 exposed OpenClaw instances as of January 31, 2026. The skills ecosystem is expanding to match.
The npm leftpad incident cost millions in downtime and forced an industry-wide reckoning with supply chain trust. It took years to build the tooling that exists today. AI agents don't have years. The adoption curve is too steep and the attack surface is too broad.
We need authorization built into the architecture, not bolted on after the breach report. We need systems that stop the bad thing before it happens, not ones that log it for the post-mortem.
And we need to stop pretending that "we can audit it later" is an acceptable security posture for systems that can execute code, call APIs, and spend money without asking permission.
APort's pre-action authorization pattern is one approach. The Open Agent Passport vault lets you test whether your guardrails actually work. The important thing isn't the specific implementation. It's the architectural commitment: verify before execute, not after.
The obvious objection
"But my agent needs to make decisions autonomously. Pre-authorization defeats the purpose." Fair point. Let me ask a question back.
Would you install a VS Code extension that could silently generate crypto wallets and upload private keys to a server, with no prompt, no log you'd notice, and no way to stop it mid-operation?
If the answer is no, then your agent shouldn't be able to do that either. The autonomy you want for your agent should be constrained by policy, not by hoping nobody exploits the trust gap.
The market is going to settle this one way or another. Either platform builders ship authorization gates, or regulators will mandate them after the first major AI agent supply chain breach makes national news.