A skill is a program you can't see running

Between July 2 and August 2, 2026, look-alikes of popular skills on a major public skills directory showed more than 1.7 million installs on the directory's own counters before they were taken down. Hidden inside them was an instruction to fetch and run code that stole credentials. There was no exploit, and nothing to patch. The skills did what skills do, and that was the attack.

An agent reads a file and does what it says, with whatever access it has. That is the design. Text it reads is text it runs.

A skill is a folder. At its center is a SKILL.md file — a page of Markdown that tells an agent how to do something: how your team writes migrations, which internal API to call, what to check before it opens a pull request. Around it are its supporting files: reference docs, assets, and scripts the agent can run, loaded only when the task needs them. That is where the look-alikes hid that instruction: in a supporting file, the one an agent reads only after it has already chosen the skill.

Skills live in your repos, in folders like .claude/skills/, and they run with your agent's full reach: your files, your credentials, your network. A skill reads like documentation and runs like code: the agent does what the Markdown says, and the scripts do what any script would. It is a program you can't see running.

The discipline we built for code

We spent decades learning not to trust code just because someone published it. A package from a public registry now passes through signing, provenance, a lockfile that pins an exact version, scanners, and human review before it reaches production. None of it is perfect. All of it exists because "someone published it" and "it is safe to run" turned out to be different claims.

Skills arrived with almost none of that discipline. When Snyk's researchers scanned 3,984 skills from two public directories, they put the bar to publish on one of them at "a SKILL.md Markdown file and a GitHub account that's one week old." No signing, no review. They found that 36.82% of those skills carried at least one security flaw, 534 of them at critical severity, and 76 carried malicious payloads. And the file an agent loads runs with everything that agent can reach. That is more reach than most packages you ship, and less scrutiny than any of them.

A cross-vendor standard did arrive. In August 2026, Amazon, Cursor, Microsoft, OpenAI and Vercel shipped Agent Plugins — a common way to package skills and move them between tools, built on the open Agent Skills format. It's a real step. But packaging a skill and governing it are different jobs, and the standard's authors say so themselves. Their own list of future work includes signature verification, attestation back to a source repository, organization-scoped registries with approval workflows, and a standard audit event schema. Settling how a skill travels doesn't settle whether you should run it, or which version. That layer is still open. And no serious organization runs on one tool; a neutral layer across them is the thing a tool vendor can't build.

The skills that matter never came from a registry

Here is the part the malware research tends to skip. The skills a team actually leans on are not downloaded from anywhere. They are the team's own rules: the migration conventions, the endpoint naming, the checklist before a pull request. Those never sit in a public registry. They start life in a Git repo.

And then they scatter. Someone copies a skill into .claude/skills/. Someone else sets it up in Cursor. A third person edits a local copy in the middle of a task and forgets to sync it back. A few weeks later there is not one skill; there are several, each still valid from an agent's point of view, and no one can say which one is approved. Claude Code and Cursor on the same team end up reading two files that share a name and disagree on the contents. The version the team actually wrote stays put, while stale and edited copies do the work in every agent.

This is drift, and it is not a discipline problem. It's what always happens when people copy a file into a dozen places by hand.

One skill in five depends on something outside itself

In September 2026 we measured every published skill in SkillRepo's public catalog, from vendors' own repositories and individual authors alike. One skill in five tells the agent to install a package or pull something from the network with curl, wget or git clone, counting only what the SKILL.md itself says. Most of those instructions are exactly what the skill should do: a vendor's skill installs the vendor's SDK. They are not flaws. They are dependencies the skill relies on but doesn't own, and a team's own skills carry the same ones whenever a checklist says npm install.

That is how a safe skill could go bad without anyone touching it. Let one of those dependencies lapse — an abandoned account, an unregistered package name, an expired domain — and an attacker can claim it and serve their own code in its place; AIR's SkillJacking research found 925 public skills open to exactly that. When the maintainer fixes the skill, the copies that sync get the fix. The copies that drifted keep pulling the attacker's code, and nothing can reach them after the fact.

Grading a skill is necessary, and it is not enough

The first instinct, from vendors and researchers alike, was a good one: grade the skill, scan the skill. Cisco's AI Defense team released an open-source skill scanner. Anyone pulling skills into their work should want it.

Then read what the people who build these tools say about them. Cisco ships its scanner with a warning in plain sight: "No findings ≠ no risk. A scan that returns 'No findings'... does not guarantee that a skill is secure, benign, or free of vulnerabilities." JetBrains gates its own curated skill repository with the same scanner in CI, and still tells users to test each skill themselves before relying on it. Grades are signals, not a certification — always review a skill yourself before running it. And review the whole skill, not the page on top: one skill in eight in that same sample carries a script the agent can run, and the look-alike skills hid their payload in exactly such a file.

There is a limit no scanner can fix, because it is about the reader, not the file. Saha, Faghih and Feizi, who studied skill registries, call a SKILL.md "not passive documentation but operational text". In their study they took 100 real skills and made a copy of each that did exactly the same thing. Only one sentence of the description changed: a claim of trustworthiness, a note that it was recently maintained, a more assertive tone. Across four models and 2,000 trials each, agents picked the copy over the original 77.6% of the time. Nothing in the copies was malicious. The choice was made on the description, and the description is whatever its author wrote.

A grade has a second limit that has nothing to do with how good it is: it looks at one skill, once. It cannot see the drift behind it — the stale copy, the edited version, the two same-named files your agents disagree on. And it cannot see the reach: which agents have the skill at all, and which of them ever needed it. The questions that decide whether your organization is safe are different: which version is every agent running, does each agent hold only the skills its work needs, and if one goes bad, can you pull it back?

What governing a skill takes

Most teams cannot answer those questions. The tools they have grade a skill or list it, and a pinned commit holds one repo to one version. Nothing keeps every agent, across every tool, on the approved version, limits each to the skills its work needs, or pulls a bad version back. Skill governance is control over who approved a skill, which version each repo runs, what has drifted, and what to recall. It is one half of a pair. Skill distribution is getting the current, approved version of a skill into the path every agent already reads — and keeping it current there. Governance is the record and control on top. Neither replaces a scanner. Grading tells you whether to trust a skill today. Distribution and governance keep that decision true across every agent tomorrow, and let you undo it when it stops being true.

Strip it to requirements. The machinery for governing a dependency already exists; it was just never pointed at this one. Applied to skills, the list is short:

• One approved version of each skill, reaching every agent that needs it and staying current there, so nobody is quietly running the three-week-old copy.
• Scope, so each repo gets only the skills its work needs, not the whole library. A smaller set is fewer things that can go wrong.
• Provenance on what you pull: which repository a skill came from and which commit it was synced from, attributed to the identity that owns it.
• A pin, so a given repo runs the approved version on purpose, not whatever synced most recently.
• Drift in plain sight, so when a copy diverges from the approved one, someone can see it — including the copy an engineer edited deliberately.
• Recall with a fallback, so when a version goes bad you can pull it back across the organization in one action, and the last known-good version serves in its place when an earlier one exists.

Recall is worth stating precisely, because it is easy to oversell. It works like distribution, not like a lock, and only for a skill your team already distributes through that shared channel. For those, it serves the last good version to every agent on its next sync and retires the bad one; when there is no earlier version, the skill simply stops being served. It does not un-run a skill that already executed; nothing can. Without recall, pulling a bad skill means messaging every engineer and hoping each one deletes the right folder. Recall is one action through the same channel that delivered it.

Where SkillRepo fits

SkillRepo is the open distribution and governance layer for AI agent skills.

Distribution comes first, because it removes drift at the source. Connect the GitHub repository where your skills already live. Every agent on the team then pulls the same approved version through the open Agent Skills standard into the path it already reads on disk, in Claude Code, Cursor, Windsurf, Copilot and the rest, and the sync keeps that copy current. Fix a skill in one place and the next sync carries everyone forward together. The hand copy that used to drift is no longer the source of truth; the synced version is.

Trust travels with each skill you pull: an A–F grade, a signal rather than a certification, and provenance naming the repository it came from, the commit it was synced from, and the GitHub identity it is attributed to. Your own skills stay private by default and are never listed, served, or synced to another account. Every version is analyzed before it is served.

Governance rides on top of distribution. A lead composes the set of skills the team has approved — a skillset — and each repository names the one it uses in a committed skillrepo.json. From then on, the sync delivers to anyone working in that repo exactly those skills, at the versions the lead approved, and nothing else. Drift from the approved set is visible per repo and per person, and every sync and every change to the set is recorded. A bad version can be recalled across every repo on each machine's next sync, with a known-good version served in its place when an earlier one exists.

You can't stop an agent from doing what it reads. You can only decide which version it reads, and pull it back when it turns bad.