Teams usually assume the hard part of governing agent skills is the detection problem: can you tell a malicious skill from a benign one. In the rollouts we've sat in on, that's rarely what stalls things. The technical layer is tractable. What holds a program up is almost always one of three organisational gaps, and all three tend to surface in the first week.

1. Nobody owns the decision

Ask who approves a new agent skill and you often get a pause. Not because the organisation is careless, but because the artifact type is new enough that it never got assigned. Code has an owner. Dependencies have an owner. Cloud infrastructure has an owner. Agent skills tend to fall between AppSec, platform engineering, and whoever happens to be closest to the developers using them.

Until that ownership is written down somewhere, the effective policy is whatever each individual developer decides, one install at a time. That isn't a failure of process so much as an absence of one, and it's usually fixable in a single meeting once someone names it out loud.

2. The inventory doesn't exist yet

The second gap is more concrete: most teams cannot produce a list of what's actually installed. They can produce one for code dependencies immediately, because that infrastructure has existed for years. For agent skills, the honest answer is usually an estimate.

This matters more than it first appears, because every downstream decision depends on it. You can't tier by provenance if you don't know where things came from. You can't scope a review process if you don't know the volume. Teams that try to write policy before establishing this almost always end up rewriting it once the first real inventory lands and the numbers don't match the assumptions.

The most common sequencing mistake we see is writing the policy first. An inventory takes far less time than most teams expect, and it changes what the policy should say.

3. The policy gets written for the wrong population

The third pattern follows from the second. A team drafts a review process built around the assumption that most skills come from a handful of curated, official sources. The first inventory then shows a meaningful share arriving from open third-party marketplaces instead, which is exactly the population that warrants the most scrutiny and the least likely to have had any.

The resulting policy is either too heavy for the low-risk internal skills, too light for the marketplace ones, or applied uniformly to both, which manages to be simultaneously burdensome and insufficient. Provenance-based tiering solves this, but only if you know the provenance first.

What tends to unblock it

The rollouts that move fastest tend to invert the usual order: name an owner, produce an inventory, then write the policy against what the inventory actually shows. That sequence takes less calendar time than drafting policy in the abstract, and it produces a document the team can defend, because every line in it traces back to something observed rather than assumed.

FAQ

Is this specific to agent skills, or does it apply to AI artifacts generally? The pattern generalises. Models, datasets, and MCP configurations run into the same three gaps, usually a little later, because agent skills are the most visible and fastest-growing category right now.

How long does the inventory step actually take? Far less than most teams budget for it, particularly where visibility can come from source control or existing endpoint tooling rather than requiring new agents to be deployed. The delay is usually in deciding to start, not in the work itself.

Who should own this if there's no obvious candidate? In most organisations the least disruptive answer is whoever already owns software supply chain policy for code, with scope explicitly extended to cover AI artifacts. The trust boundary problem is the same one; only the artifact type has changed.

Related reading: "10 Questions Every Security Team Should Ask About Agent Skill Risk," "Trust Tiers: A Governance Framework for Agent Skill Allowlisting"