By Nolan Sullivan, Founding Growth Engineerskills governance
Skills governance is the set of controls that keep a live record of every agent skill in an organization: which file it is, who owns it, which agents load it, whether it is sanctioned, and what tools it tells those agents to call.
Skills governance exists because the files that steer coding agents never pass through the systems that track software. Alice’s Cursor is an approved application, deployed through MDM and present in the asset register like anything else IT installs. The SKILL.md in her project directory that tells the agent to copy production database records into a personal Claude project appears in no register at all. Neither does the “incident triage” skill she copied from a teammate, which pages the wrong Slack channel and finishes by calling create_refund. Both files change what an approved agent does with production access, and neither shows up as software, because a skill is never installed. It lives next to the source code and is loaded by the agent harness at runtime.
The artifact has a specific shape. In Claude Code, a skill is a directory whose required entrypoint is a SKILL.md file: YAML frontmatter that declares a name and a description, followed by markdown instructions the agent follows when the skill runs. Claude Code implements the Agent Skills open standard, and skills load from the personal ~/.claude/skills/ directory, a project’s .claude/skills/, or a plugin. A skill teaches an agent how to do a job: a deploy playbook, a review checklist, an incident runbook. It holds no credentials, exposes no endpoint, and executes nothing itself. The agent it instructs does all of that.
The governance problem is the one the Cloud Security Alliance put at the center of its April 2026 research note, The AI Agent Governance Gap: What CISOs Need Now: organizations cannot govern what they cannot see. The note cites a survey of 235 large-enterprise CISOs and CIOs in which 92% said they lack full visibility into their AI agent identities. Skills sit one layer below the agents in that statistic. They are the instructions those agents follow, and most organizations cannot produce a list of them, let alone say who owns each one.
Why does a skill never show up in a software inventory?
A CMDB and a software asset register record installations, and a skill is not one. An unsanctioned Model Context Protocol (MCP) server at least leaves marks that discovery tooling has learned to look for: a JSON entry in a config file such as ~/.cursor/mcp.json, a running process, traffic to a server. A skill leaves less: it is a markdown file that arrives by git clone, by copy and paste, or inside a plugin, and nothing about its arrival fires a procurement event, an install log, or an endpoint alert. The shadow AI reference covers this detection problem across both surfaces; the short version is that the threat models most endpoint tools were built on predate agents taking instructions from files in the repo.
The gap also differs in kind from the agent visibility gap. An agent inventory records principals, meaning the agents that authenticate and act. A skill is an artifact one of those principals loads. Governing it means tracking a file’s provenance and reach rather than an identity’s permissions.
Why are skills a prompt injection vector?
Invisibility is only half the problem. A skill’s entire function is to place instructions in a model’s context, where the model reads them with the same authority as its system prompt, and that is exactly the property prompt injection exploits. A poisoned skill never has to smuggle instructions past a defense, because the delivery mechanism hands them to the model as designed. In the taxonomy of injection types, it is a stored injection: the payload is written once, sits at rest as clean-looking documentation, and fires in every future session that loads the file. It is the skill-shaped sibling of MCP tool poisoning, where the same trick rides in a tool description instead of an instruction file.
Researchers flagged the exposure within weeks of skills shipping in October 2025. The paper Agent Skills Enable a New Class of Realistic and Trivially Simple Prompt Injections showed that a few lines of malicious instruction placed in a skill, or in the reference files a skill links to, steer an agent without any jailbreak, and that the frontmatter description a person reads before installing says nothing about what the rest of the file tells the agent to do.
By early 2026 the attacks were live at marketplace scale:
- Koi Security’s ClawHavoc audit of ClawHub, the skill marketplace for the OpenClaw agent, found 341 malicious skills out of 2,857 in February 2026, 335 of them traced to a single campaign delivering the Atomic macOS Stealer, which harvests browser credentials, keychain passwords, SSH keys, and crypto wallets. A follow-up two weeks later, after the registry had grown past 10,700 skills, put the count at 824.
- Snyk’s ToxicSkills study scanned 3,984 skills across ClawHub and skills.sh in the same month and flagged 1,467 of them (36.82%) for at least one security issue, most involving prompt injection techniques, with 76 confirmed malicious payloads still live at scan time. In one documented case, three lines of markdown in a
SKILL.mdwere enough to instruct an agent to read a developer’s SSH keys and exfiltrate them.
Those campaigns centered on one agent’s marketplace, but nothing in the technique is specific to it. Skills are an open standard that Claude Code and Cursor both load, Snyk reported flagged skills targeting OpenClaw, Claude Code, and Cursor users alike, and a skill that arrives by git clone or copy and paste never touches a marketplace scanner at all.
This is why two fields in the governance record are security controls rather than bookkeeping. Sanctioned status has to mean someone read the whole file and every file it links, not the description at the top. And content version has to mean an edited copy is a new, unreviewed artifact, whatever its name says, because a payload added after approval is the skill equivalent of the MCP rug pull.
What belongs in a skills governance record?
The record is shorter than the one an agent inventory keeps, because a skill has no identity of its own. It never authenticates, so there are no credentials or delegated permissions to track. Six fields cover it:
- Identity. The skill’s name, the path it loads from, and a version of its content. The name alone is not enough, because two files named
deployin different directories are two different sets of instructions, and an edited copy is a new version, not the same record. - Owner. The person who answers for the instructions, approves changes, and can retire the skill. This is the field that makes revocation and offboarding work.
- Loading surface. The agents and harnesses that load the skill: whose Claude Code, which project’s Cursor sessions, which plugin distributes it.
- Instructed tools. The MCP tools, shell commands, and endpoints the instructions tell agents to call. This field connects a text file to blast radius, and it points into the tools register described in the next section.
- Sanctioned status. Whether the organization has reviewed and approved the skill, or whether discovery surfaced it unreviewed.
- Last seen. When a harness last loaded the skill. A record with no recent activations is a candidate for retirement.
How do skills, MCP servers, and shadow skills differ?
These terms get conflated because they travel together in the same governance conversations. They are different objects.
| Object | What it is | The governance question it raises |
|---|---|---|
| Skill | A static instruction file that tells an agent how to do a job | Who approved these instructions, and what do they tell agents to call? |
| MCP server | A live service that exposes tools to agents behind authentication | Which tools does it expose, and what credentials sit behind them? |
| Shadow skill | An instruction file agents load that nobody has reviewed | What is steering our agents that security has never read? |
| Poisoned skill | An instruction file carrying an embedded prompt injection | Which of the files steering our agents did an attacker write? |
A skill instructs, and an MCP server executes. The server side of the register is its own discipline, covered in what is an MCP inventory, and the sanctioned path to those servers usually runs through an MCP gateway. Shadow skills are one population of shadow AI, alongside unsanctioned MCP servers, and both surface through the same agent discovery program. Poisoned skills hide most easily inside the shadow population, since a file nobody reviewed is a file whose instructions nobody read, but the ClawHavoc campaign put hundreds of them in a public marketplace where installation was the sanctioned path. Whether a given job belongs in a skill or behind an MCP server is an architecture decision rather than a governance one, and skills vs MCP works through that choice. Governance has to track both, wherever a team draws the line.
Why is a git repo of approved skills not governance?
The common first attempt is a repository named something like approved-skills: every skill reviewed in a pull request, versioned in git, and cloned by developers. That repo is a good distribution point and a poor record of what agents actually load, because three mechanics break the link between the two.
- Copies drift. A developer copies a useful skill into
~/.claude/skills/so it applies to every project. The copy stops tracking the repository the moment it lands, and every local edit widens the gap. - Precedence hides substitutions. In Claude Code, a personal skill takes precedence over a project skill with the same name, so the reviewed
deployin the repo can be displaced by an edited personal copy without any visible change in how the agent is invoked. - Edits apply live. Claude Code picks up changes to skill files within the current session, without a restart, so the file that was reviewed in the morning and the file that runs at noon can differ under the same name. Skills also arrive from outside the organization entirely, since public collections such as the Speakeasy agent skills for OpenAPI work install with a single command.
The repository records intent, and the harness decides what loads. Discovery therefore has to observe the harness itself. Agent hooks fire inside coding agents on every prompt and tool call, which lets them report the skills and MCP servers a session is actually wired to, including the files that never passed review. Agent discovery covers that program end to end.
What does skills governance make possible?
The register pays for itself the first time something goes wrong, and three controls follow directly from it:
- Revocation becomes an action instead of an email. A skill found to carry an injection, exfiltrate data, or page the wrong on-call can be retired everywhere it was distributed, because the record says which agents load it. When the ClawHavoc skills were identified, the organizations that could answer “which of our machines loaded one of these?” had a register; the rest had a search problem.
- Containment reaches past the file. When a skill instructs agents to call an MCP server nobody sanctioned, the instructed-tools field ties the instruction to live traffic, and policy can block the call even on machines where the file survives.
- Offboarding stops orphaning runbooks. When the owner of a skill leaves, the owner field finds their skills and reassigns or retires them, instead of leaving instructions that agents keep following with nobody accountable for the outcome.
How does the Speakeasy AI Control Plane govern skills?
Everything above is process an organization could run by hand. The Speakeasy AI Control Plane ships it as a system, and the register maintains itself from how skills are distributed and used rather than from a survey:
- The registry is versioned. The platform records every skill with an immutable, content-addressed version history: side-by-side diffs between any two versions, rollback to a known-good one, and a manifest view that shows exactly what agents load.
- Discovery fills in the unsanctioned half. The platform discovers the MCP servers and skills wired up outside the sanctioned path, and skills observed in use on developer machines enter the registry with full version tracking, so the register covers what exists rather than only what was submitted.
- Instructions get scanned. The platform analyzes tool call results for prompt injection while a skill is active and flags findings on the skill’s record, which catches the instruction file that quietly redirects an agent.
- Revocation is one action. Archiving a skill removes it from the catalog and revokes its plugin distributions, and drift tracking shows how many machines run the distributed version and how many have moved to another one.
- Unsanctioned calls are caught downstream. When a shadow skill tells an agent to call a server nobody approved, shadow MCP detection classifies the call from its provenance, and a blocking policy stops it whether or not the file has been found yet.
The CSA framing applies to skills the same way it applies to agents. The organization that can produce the register governs the population, and the one that cannot has a folder of markdown files it has never read. To see the record the platform keeps for the skills your agents already load, talk to us.