· 8 min read

A Fake Skill Passed Every Scanner and Reached 26,000 Agents. The Two Signals You Use to Vet a Skill — Stars and a Clean Scan — Are Theater.

A security firm called AIR built a malicious agent skill, pushed it through a popular skill marketplace, paid for an Instagram ad, and reported that it reached roughly 26,000 agents, some of them on corporate accounts. Every skill security scanner the firm tested marked the thing safe. The payload was harmless on purpose, collecting only the user's email address, but the foothold it opened could have read files, moved data, or reached internal systems.

The interesting part isn't that a scanner missed something. Scanners miss things every day. The interesting part is how it missed, because the technique attacks an assumption baked into the entire way solo operators vet the tools they install.

The trick is that the scan happens once

The skill was called brand-landingpage, and it claimed to build a landing page using Google's Stitch design tool. It was aimed squarely at non-technical users: the exact audience installing skills they don't read.

Here's the mechanism. The skill instructed the agent to install a "Stitch SDK" by following the setup docs at an external link: stitch-design.ai. That domain is not Google's. It belongs to AIR. At scan time, the link resolved to the genuine Stitch documentation, so every scanner saw a clean package pointing at a plausible, legitimate-looking setup page and waved it through. The catch is that the page a skill points to can be rewritten at any moment after the scan clears. The verdict is a snapshot. The instruction is live.

That's the whole game. A scanner evaluates a skill as a fixed object. But a skill that says "go to this URL and do what it tells you" isn't a fixed object: it's a pointer to something the author controls and can change the instant the green checkmark is issued. Static analysis of a dynamic instruction is theater. It looks like security and provides none.

They didn't just exploit the scanner: they farmed the trust signals

What makes this worth your attention is that AIR didn't stop at slipping past the scan. They deliberately manufactured the two signals you, personally, use to decide a skill is safe.

The first is a clean scanner result, which they already had. The second is social proof. To get it, AIR opened a pull request against a skill marketplace repository with around 36,000 GitHub stars and 156 skills. Getting your skill into a repo that popular borrows the repo's credibility: the same way a malicious npm package looks legitimate because it sits next to packages everyone trusts. Stars on the parent repo become implied trust for everything inside it.

Stack those together (a green scan, a listing inside a 36,000-star marketplace, and a paid ad driving installs) and you have a skill that looks vetted from every angle a normal person checks. None of those angles actually inspected what the skill does when it runs.

You've seen this movie, it just had different actors

If this feels familiar, it should. This is the npm install-scripts problem wearing new clothes. For years the supply-chain attack pattern was: publish a package that looks fine, hide the malice in a lifecycle hook or a postinstall script that runs code the moment you install, and ride the trust of the registry. The whole industry spent the last year turning install scripts off by default precisely because "the package looked clean" was never the same as "the package is clean."

Agent skills reopened the exact same hole, with a worse twist. An npm package's malicious code at least ships inside the package, where a determined reviewer could find it. A skill that points at an external URL keeps the malice off-package entirely. There's nothing in the artifact to find, because the dangerous instruction lives on a server the author updates whenever they like. You can read the entire skill, top to bottom, and learn nothing about what it will actually tell your agent to do tomorrow.

I keep coming back to one number: 26,000. These weren't careless people. Some were corporate accounts, which means there were procurement steps and security reviews somewhere in the chain, and the skill cleared them anyway, because the review checked the artifact and the artifact was clean.

What I'd actually do

Stop treating a clean scan and a popular marketplace as evidence of anything. They're evidence that the skill passed an automated check and got listed somewhere busy. Neither tells you what the skill does at runtime.

Three concrete moves. First, read what a skill fetches and executes, not what it claims to do. If a skill instructs your agent to pull setup instructions from an external URL and follow them, that's the whole risk surface, and a scanner cannot evaluate it. Treat "follow the docs at this link" as the equivalent of curl | bash, because functionally that's what it is.

Second, sandbox the agent that runs untrusted skills. Don't give the thing that executes a stranger's instructions standing access to your credentials, your filesystem, and your internal network at the same time. The payload in this case grabbed an email. The next one won't be a security firm being polite. Run skills with the narrowest permissions that let them work, and run them somewhere a bad instruction can't reach anything that matters.

Third, pin and review. If a skill points at an external domain, that domain is part of your trust boundary whether you decided that or not. Either vendor the setup it needs into something you control, or don't install it. "It was clean when I scanned it" is going to be the "it worked on my machine" of the agent era, and it's going to cost people a lot more than a broken build.

The honest counter-take: AIR is a security firm running a demonstration, the payload was deliberately benign, and "reached 26,000 agents" is their reported figure, not an independently audited install count. It's possible the real-world blast radius of a weaponized version would be smaller, because a genuinely malicious skill drawing attention might get pulled faster than a quiet research probe. But the mechanism is the part that's real and reproducible, and the mechanism doesn't care whether the firm running it had good intentions. The scan-once-trust-forever model is broken for anything that points at a URL. Build like it's already being used against you, because the only thing separating the demo from the attack is which email address ends up in the payload.

Author

Sources

Stay in the Loop

Get new posts delivered to your inbox. No spam, unsubscribe anytime.

Newsletter coming soon. Set PUBLIC_CONVERTKIT_FORM_ID in .env to activate.

Related Posts