Agent Skills are the next software supply chain, and nobody is signing them

A loaded skill is untrusted instructions the agent runs. That is the same risk shape as unsigned packages, and the fix is the same: govern activation before the skill runs.

AI coding agents no longer ship with a fixed set of abilities. They discover new ones at runtime through an open format called Agent Skills, a shared spec that Claude Code, Cursor, Copilot, Gemini CLI, and a growing list of other agents all read. A skill is just a folder with a markdown file that describes a capability: how to build a detection rule, how to process an invoice, how to run a deployment. The agent reads that file and follows it. This is genuinely useful, and it is spreading fast. It is also, right now, almost completely ungoverned.

The uncomfortable detail is what a skill actually is once you strip away the framing. It is plain text, written by someone you probably do not know, that tells the agent what to do, and the agent does it. "The agent loaded a skill" and "the agent ran instructions from a stranger" are the same sentence. That is the risk this piece is about, and it has a familiar shape.

What a skill really is when the agent loads it

Picture a shared library of community skills. One of them is a security-tooling skill: it helps the agent build detection rules from log data. An engineer installs it because it saves an afternoon. The skill is markdown, and inside that markdown are instructions: install this package, read these files, query this data store, push the result to that system. When the agent loads the skill, it carries out those instructions as if they were its own. No one signed off on the package it installs. No one recorded which files it read. If the text quietly changed between last week and today, nothing announces it.

That is the whole problem in one scene. The skill is trusted for one reason only: the spec said to trust it. There is no check that this skill is the one you think it is, that it has not been altered since you reviewed it, or that this particular agent (run by this particular person) was ever meant to use it. The instructions run, and afterward there is no durable account of what ran or what it touched.

Loading a skill is running code you did not write and did not check. The only thing making that safe today is optimism.

We have seen this movie: it is the package registry, again

The software industry has already lived through this exact risk, one layer down. Before signing and provenance became normal practice, installing a package from a public registry (npm, the Node package registry, is the canonical example) meant trusting that the code you pulled was the code the author published, that no one had slipped something into it in transit, and that the author themselves was not hostile. For years that trust was mostly a hope. Then came the incidents: hijacked accounts, malicious updates pushed to widely used packages, dependencies that quietly exfiltrated data. The response was a shift toward signed packages and verifiable provenance, so that a machine could check an artifact was known and unaltered before running it.

Agent Skills are sitting where packages sat before that shift. They are the dependency system for agent capabilities (the npm of what an agent can do), and today almost every skill in circulation is unsigned text an agent trusts on sight. The libraries are multiplying across every category, on every developer's machine, on every agent platform that reads the spec. The pattern is not subtle. Unsigned, widely shared, automatically executed, and growing fast is precisely the setup that produced the supply-chain incidents of the last decade. The agent-skill version of that incident has not happened at scale yet. The conditions for it are already in place.

Governing activation is the fix that actually fits

The lesson from the package world is not "do not use shared skills." Shared skills are too useful, and banning them just pushes people to ungoverned workarounds. The lesson is that the moment to exercise control is activation (the instant before the skill runs), and the control is a check, not a promise. Govern skill activation and three questions get answered every time, automatically, before the agent acts on the skill:

• Is this skill known? The skill has to be one the deployment recognizes (present in a vetted inventory), not an arbitrary folder that appeared from somewhere. An unrecognized skill is refused rather than silently trusted.
• Is it unaltered? The skill's contents are checked against a cryptographic signature that proves the text has not changed since it was reviewed. If a single character was altered, the check fails and the skill does not run. This is the same idea as a signed package: the signature travels with the artifact and any tampering shows.
• Is this operator permitted to use it? The person or credential running the agent has to actually be allowed to activate this skill. A skill that is fine for one role is refused for another, so a capability cannot be reached by whoever happens to load it.

Only when all three hold does the skill activate. And whether it is allowed or refused, the decision is recorded (which skill, which operator, when, and the outcome), so there is a durable account of every skill the agent ever loaded. That record is the difference between "we think that skill was safe" and "here is proof of what ran, and proof nothing else did."

Proven against attack, not just asserted

A governance claim is only worth the attempts to break it. The way to trust "unknown, tampered, or under-privileged skills are refused" is to have a battery of adversarial scenarios that try each of those routes on every release (present a skill that is not in the inventory, present one whose text was changed after review, present one signed by the wrong author, present one to an operator who should not have it), and require every one of them to be refused before the software ships. Governing activation is not a setting you toggle and hope holds. It is a property you re-verify continuously, the same way the package world learned to treat signing as infrastructure rather than a nicety.

The governance takeaway

Agent Skills turned the agent's abilities into a supply chain, and supply chains fail at the seams where untrusted content is trusted without a check. The teams that will weather the first real skill-supply-chain incident are the ones who decided, before it happened, that a skill has to prove it is known, unaltered, and permitted for this operator before it runs, and that every activation leaves a record. None of that makes an organization certified or compliant on its own; it is not a stamp. It is the concrete mechanism that turns "the agent loaded a skill" back into something you can stand behind: a governed action, verified before it ran and provable after.