Why skills need the same governance as MCP servers

A knowledge worker on a claims-processing team finds a skill a colleague mentioned in passing. It promises to reformat intake forms automatically. She drops it into the AI assistant she uses every day, and it works. A few weeks later, half the team is running it. Nobody on the security team approved it, nobody can say what it actually does under the hood, and nobody would know to look, because from where they sit, nothing changed. The assistant just got better.

That pattern is becoming the normal way skills spread inside large organizations, and it is a supply-chain problem wearing a productivity costume. A skill is code that changes what an agent can do and how it behaves, and right now, in most enterprises, it moves from person to person with less scrutiny than a browser extension.

Should skills be ingested through a GitHub repository, or a registry?

The sustainable answer is a registry, not a GitHub repository, because a repository gives you a place to find things, while a registry gives you the centralized approval, versioning, and revocation an enterprise actually needs once skill distribution reaches a few hundred people. A GitHub repository answers “where do I get it.” It does not answer “who approved it,” “which version is everyone actually running,” or “how do I pull it back the moment something in it turns out to be unsafe.” Those three questions are exactly the ones a security team is left unable to answer once skill adoption spreads past the engineers who introduced it.

This is not a new problem in shape, only in name. It is the same problem organizations already worked through with MCP servers: unmanaged proliferation, no shared inventory, no consistent approval step, and no way to revoke something after the fact. Stacklok’s own registry model for MCP servers, a curated catalog with provenance attestation, exists because “clone it from wherever you found it” turned out not to be a workable trust model for infrastructure that agents act through. Skills are the same category of risk, arriving a year or two behind, and the organizations asking about this now are asking before the first bad skill causes an incident, not after.

Are skills meant for developers, or for every knowledge worker?

Both, but not through the same discovery path. A developer comparing two skills that do similar things can read the code, check the permissions it requests, and make an informed call. A knowledge worker in finance or legal cannot, and framing the decision as theirs to make isn’t governance, it’s a disclaimer. The two audiences need two different front doors into the same underlying catalog: an unrestricted, searchable view for technical users who can evaluate a skill directly, and a curated, pre-approved set for everyone else, where the evaluation already happened upstream and the only decision left is whether to turn it on.

Collapsing those two audiences into one flat list is how an unreviewed skill ends up running across an entire department. It looks like efficient distribution. It is actually the absence of a decision point.

Why “it’s just a skill” undersells what’s at stake

Shadow AI discussions tend to focus on unsanctioned MCP servers and unmanaged agent sprawl, and both are real. Skills deserve the same seriousness for a specific reason: they are smaller, faster to write, and easier to share informally than a full MCP server integration, which means they will outpace any governance program built only around heavier-weight tools. A ten-line skill that quietly widens what an agent is allowed to touch is no less consequential than a misconfigured connector, and it is considerably easier to pass around without anyone noticing.

The blast radius question that matters for a kill switch or an audit trail applies here just as directly: if a skill turns out to leak data, overreach its intended scope, or simply behave differently than advertised, can you name every person and every agent currently running it, and can you turn it off everywhere at once? Most organizations cannot answer that today, because nothing is tracking skill distribution as a single, governed inventory in the first place.

What a governed skill catalog actually needs

Three things, in order. First, provenance: where a skill came from, who published it, and whether that source is one the organization has decided to trust, the same attestation model that makes a curated MCP registry meaningfully different from an open folder of scripts. Second, versioning: which version is live, which is deprecated, and whether everyone currently running a skill is running the version that was actually approved, not a stale copy someone downloaded three revisions ago. Third, revocation: the ability to pull a skill back from every agent and every user running it, in one action, the moment it needs to come down, rather than chasing individual installs one at a time.

Without those three, a skills program is just informal distribution with a friendlier name. With them, skill adoption can scale past the team that introduced it without the organization losing track of what is actually running inside its agents.

What to do this quarter

1. Inventory which skills are currently in active use across your organization, and who introduced each one. Most organizations have never written this list down, and it tends to be longer than expected.
2. Decide now, before adoption scales further, whether skill distribution runs through a curated, approved catalog or through informal sharing, because retrofitting governance after a thousand people have skills installed is a materially harder project than building the catalog first.
3. Separate your developer and non-developer discovery paths. Technical users can evaluate a skill directly; everyone else needs the evaluation to have already happened before the skill appears as an option.
4. Confirm you can answer, for any skill in use, where it came from and who approved it. If the honest answer is “we’d have to ask around,” that is this quarter’s gap to close.
5. Build a revocation path before you need one. Test what it actually takes to pull a specific skill back from every agent and user running it, and fix whatever step turns out to be manual or slow.

The same instinct that made organizations curate and attest their MCP server registry applies to skills: a catalog with provenance, versioning, and revocation is not a constraint on adoption, it’s what makes fast adoption safe to allow in the first place. Extending that same governance model to agent and skill access, through the Kubernetes infrastructure teams already operate, is the difference between skill distribution that scales and skill distribution that eventually becomes an incident report.