Fake It 'Till You Make It: A Skill In The Wild Impersonated Anthropic To Run Arbitrary Code

Meet douyin

douyin is a single-purpose skill - point it at a Douyin video - China's version of TikTok - and it pulls down the file, no fuss. Thousands have found it worth keeping: it's past 4,400 installations.

To do its job, it leans on a single dependency - Anthropic's nodriver-kit package from github.com/anthropics/nodriver-kit, their GitHub account. A small tool, carrying a name that thousands of people already trust enough to run on their own machines.

douyin had also passed its security audits. Two scanners cleared it outright, and the only objection - just stated the obvious: a skill that downloads Douyin videos browses Douyin. The dependency it actually pulls went unmentioned.

So we looked at the dependency the audits didn't. Follow the link to anthropics/nodriver-kit and GitHub returns a 404 - ^{Anthropic never published a nodriver-kit}. The package pinned in requirements.txt wasn't on PyPI either. ^{None of it was real}.

The dependency the scanners waved through pointed at a repository that didn't exist and a package that had never been published.

Nothing stops this from being intentional. An author ships a skill that impersonates a trusted author; the referenced package is still unclaimed, collects installs off a name people already trust, then registers that package and points it at code of their choosing. Whether or not that was ever the plan, it's a setup that can turn bad in an instant - one push to a name thousands of agents already pull, long after the scanner that cleared it stopped looking.

It Dropped Anthropic's Name; The Audit Took Its Word

So how does a skill built on a nonexistent repository earn a passing grade?
It didn't slip past the audit. The audit looked right at it. Here's what the scanner wrote in its own report:

_{The skill requires 'nodriver-kit' from the 'anthropics' GitHub organization. As this is a trusted organization defined in the [TRUST-SCOPE-RULE], the dependency itself is considered LOW risk.}

Read it twice. The scanner saw the dependency. It saw where it claimed to come from - “the anthropics organization”. And because that name was on its list of trusted sources, it marked the risk down. It never checked whether the repository existed. It didn't need to. The name was enough.

That's the whole trick, and no one had to be clever to pull it off. An audit that grades a skill by the names it cites, instead of the code it actually pulls, can be passed by citing the right name. ^{The trust isn't earned - it's borrowed}.

Why is it dangerous?

^{An unclaimed name on PyPI isn't a dead end - it’s an opening}. And an opening on the install path of an audit-passed skill is a delivery channel waiting for a payload.

Anyone can load it - the author, or a stranger who claims the name first: ship something harmless, collect the installs and the green badge, then push a malicious update later. Every install pulls it, and the audit never looks again.

We've watched both play out: one skill quietly seizing 26,000 agents while the scanners waved it through (The Story of Skills), and 925 skills built on instantly hijackable dependencies reaching 134,000 agents (SkillJacking).

It's Not Just Anthropic

Point a scanner at any trusted name and the same thing happens. We ran the check across the major AI vendors, and the pattern held everywhere we looked - ^{skills citing repositories under Anthropic, OpenAI, Microsoft, Google} that were never real.

In total, skills with over 68,600 installs carry the same evidence: impersonating a trusted name pointing to a resource that doesn't exist.

What Actions Should Security Teams Take?

1. Use a scanner that actually vets dependencies. One that confirms every repository, package, and account a skill references exists and belongs to who it claims - not one that reads the name and moves on. A green check is only worth what the check behind it verified.
2. Use a secured by default marketplace. Skills should reach your agents only through marketplaces that run that verification before they list anything - where a trusted name has to be earned, not just typed.

^{Skill impersonations are being generated faster than anyone can review them}. The only defense that holds is one that verifies every reference, every time - the standard your security program should demand of any scanner it trusts, and the one we hold ours to.

So we ran douyin through ^ScanAir: the repository that doesn't exist, the package no one had claimed - both flagged on sight. See the scan →