MCP Skills Library Governance for AI Agent Teams

A platform team that lets AI agents load skills has, often without noticing, started running a software supply chain. A skill is a folder of instructions, and sometimes scripts, that an agent reads before a type of work. It is easy to collect them the way developers once collected shell snippets: copied from a public repository, edited in place, shared in a chat thread. A security study of public skill marketplaces, published as a preprint in January 2026 and described by its authors as the first large-scale analysis of its kind, found that 26.1% of the 31,132 skills it analysed, 8,126 in all, contained at least one vulnerability pattern.

That figure is the reason this guide exists. It is written for the engineering lead or VP Engineering who owns how agents are equipped, and it covers one question: what turns a pile of SKILL.md files into a governed library, one where you can say which instruction an agent ran on a given day, who approved it and what it was allowed to reach. It deliberately does not re-explain how a deny-by-default gateway works, which our guide to AI agent work management already covers, and it leaves EU AI Act record-keeping duties to our post on a work management layer for LangGraph.

This guide is shipped by the team behind Cognibl, from DILR.AI, which provides work management for teams where people and AI agents share one board. Or see DATS, our five-stage AI consulting system for placing agents inside real operations.

What is an MCP skills library?

An MCP skills library is a shared collection of agent skills, each a SKILL.md file with a name, a description and instructions, that AI agents fetch over the Model Context Protocol instead of reading from a local folder. The library becomes the single place a team keeps the instructions its agents run, which means it can carry versions, ownership and access rules that a scattered folder of files cannot.

The format underneath is now an open standard. Agent Skills defines a skill as a folder containing a SKILL.md file, with a name and description at minimum, plus optional scripts, references and assets. Anthropic, which originally developed the format, published it as an open standard in December 2025, updating the October 2025 engineering post that first described it, and the format has since been adopted by a growing number of agent products. Agents load skills by progressive disclosure: they read only the name and description at start-up, pull the full instructions when a task matches, and execute any bundled code only then. That design keeps context small, but it also means the description is the only part an agent always reads, and the instructions arrive at the moment the agent acts.

The Model Context Protocol is the second half of the phrase. MCP is an open protocol for connecting AI applications to external tools and context, and a team that serves its skills through an MCP server gets one controlled doorway rather than files spread across every developer's machine. That is where a library starts to differ from a repository: the doorway can refuse, record and version. For a wider view of how agent tooling fits a delivery operation, our AI developer productivity solution sets out where skills sit beside code review and testing.

Why is an ungoverned skills folder a supply-chain risk?

An ungoverned skills folder is a supply-chain risk because a skill is executable intent: its instructions steer what an agent does, and any bundled script can run with the privileges of the user behind the agent. When skills are copied from public marketplaces without review or version history, a team cannot say which instructions its agents ran, and a single altered file can change agent behaviour across every project that uses it.

The research makes the exposure concrete. The January 2026 study by Liu and colleagues collected 42,447 skills from two major marketplaces and analysed 31,132 of them with a detection framework that combines static analysis with language-model classification. Its findings, which the authors report at 86.7% precision, are detected patterns rather than confirmed attacks, and the paper is a preprint, so treat the rates as a strong signal rather than a census.

Three numbers in that study matter most to a platform team. Data exfiltration patterns appeared in 13.3% of analysed skills and privilege escalation in 11.8%, and 5.2% showed high-severity patterns the authors describe as strongly suggesting malicious intent. Skills that bundle executable scripts were 2.12 times more likely to contain vulnerabilities than instruction-only skills. The authors close by calling for capability-based permission systems and mandatory security vetting, which is a governance problem as much as a scanning one.

A second study sets a floor under the worst case. Researchers analysing 98,380 skills from two registries, in a paper accepted to USENIX Security 2026, combined static pattern matching with dynamic behavioural verification and confirmed 157 skills with malicious behaviour, carrying 632 distinct vulnerabilities across 13 attack techniques. That is a far smaller share than the first study's high-severity rate, and the gap is the point: detected risky patterns are common, while confirmed, deliberate attacks are rare but real. Each malicious skill averaged 4.03 vulnerabilities, over half of the confirmed cases came from a single actor using templated brand impersonation, and the registries removed all 157 after disclosure. The same supply-chain logic applies to any unmanaged AI tooling, which our post on shadow AI governance explores from the inventory side.

Anthropic, which designed the format, is direct about the trust question. Its engineering guidance on Agent Skills warns that malicious skills may direct an agent to exfiltrate data or take unintended actions, and states: "We recommend installing skills only from trusted sources." For a skill from a less-trusted source, the same guidance advises a thorough audit before use, starting with the files bundled inside it. A governed library is how a team turns that recommendation from individual discipline into a property of the system.

What does a governed skills library need?

A governed skills library needs five controls: every skill is a versioned record that is never overwritten, every skill has a named owner, any bundled script is reviewed before use, agents can reach only the skills a project has enabled, and every use is traced. Together these let a team answer, for any past agent run, which instruction ran, who approved it and what it could touch.

The five controls below are our own framework, built from the failure patterns in the research above and from the practice of treating agent instructions as production code. They are not a standard, and a small team can start with two of them.

The first control carries the most weight, because the others depend on it. Without an immutable version, an owner signs off one text and the agent runs another, a review covers a script that later changes, and a trace points at a file name whose contents have moved on. Versioning is what makes the other four mean something.

The second and third controls are organisational. A named owner is a person, not a team alias, who answers for what a skill tells an agent to do. Script review follows the research directly: if bundled scripts more than double the odds of a vulnerability, a library should treat an instruction-only skill and a skill with code as two different risk classes, with a heavier review path for the second. Our AI operating model service is where that RACI usually gets decided, before the tooling.

The fourth and fifth controls are where the library meets the runtime. Scoped access means a project sees only the skills it has turned on. Traced use means each fetch is recorded against the agent that made it. The MCP specification places a consent duty on the host application, which must obtain explicit user consent before invoking any tool, and it states that MCP itself cannot enforce its security principles at the protocol level. A server-side library policy complements that host duty; it does not replace it. How a deny-by-default gateway implements scoped access is covered in our agent work management guide.

How should versioning work for SKILL.md files?

Versioning for SKILL.md files should work like an append-only ledger: every edit creates a new, immutable version, no version is ever overwritten, and retiring a skill archives it rather than deleting it. That way the exact instruction an agent ran months ago can still be retrieved and read, which is what an incident review, a client query or an internal audit actually needs.

A git repository gets part of the way there. It records history, and a pull request gives a review step. The gap is the join between a version and a run. A repository can tell you what the file said at a commit; it cannot, on its own, tell you which commit a particular agent loaded on a particular afternoon, because the agent read whatever was on disk. Teams that try to close that gap usually end up pinning commit hashes in agent configuration by hand, which works until someone edits the file in place on a single machine.

This is the problem Cognibl was built around. On the Cognibl product page, skills and agents are stored in SKILL.md format, frontmatter and markdown, versioned immutably, and items archive rather than delete, so the instruction an agent ran in March is still the instruction you can read in September. Agents reach that library over the Model Context Protocol through a gateway that is deny by default, every call is traced, every write is attributed by key name, and records are append-only and hash-chained. The Cognibl site puts the same idea in plain terms: every edit is a new version, and nothing is deleted.

Three practical rules follow for any team, whichever tool it uses:

• Version on content, not on file name. Two files called the same thing are two different instructions if their text differs, and the record should say so.
• Archive, never delete. A deleted skill makes every past run that used it unexplainable. Archiving keeps it readable while removing it from use.
• Record the version with the run. The trace for an agent's work should carry the version identifier of each skill it loaded, so the link survives later edits.

The same discipline sits behind the DATS five-stage methodology we use when placing agents inside a client's operation: decide what evidence a run must leave before deciding which agent runs it.

How should a team vet a skill from a public repository?

A team should vet a public skill the way it vets a third-party code dependency: read every bundled file, treat any script as executable code needing review, check the description for instructions that reach outside the stated task, and bring the skill into its own library as a pinned copy rather than linking to the public original. Later upstream changes then arrive only as a deliberate update.

Public repositories are useful, and an official one is a sensible reference point. Anthropic's public skills repository holds example skills, each self-contained in its own folder with a SKILL.md file, and it is the natural reference for what a well-formed skill looks like. The confirmed attacks in the second study came from open registries, and over half of them traced to a single actor using templated brand impersonation, so a familiar name on a skill proves nothing on its own.

A short vetting routine covers most of the exposure:

1. Read the description first. At discovery an agent reads only the name and description, so a description that asks for more than the task needs is the earliest warning.
2. Separate instruction-only skills from skills with scripts. The 2.12 times difference in the research justifies a heavier review for any skill that executes code.
3. Look for reach outside the task. Network calls, credential paths and file access beyond the working directory are the places to look first, because data exfiltration and privilege escalation were the two most prevalent categories in the research.
4. Import, do not link. Bring the reviewed text into your own library as a new version you own, so an upstream edit cannot silently change what your agents run.
5. Assign an owner on import. The person who approved the skill is the person who reviews its next change.

OWASP's Agentic Skills Top 10, an incubator project, is a useful companion list for the review step. None of this needs a dedicated tool on day one. It needs a rule that no skill reaches an agent without passing through it, and a library that can enforce the rule. For teams that want an independent view of where agents are already running before they write that rule, an AI placement diagnostic maps the current estate first.

The same review logic underpins our AI developer productivity work, where coding agents, review queues and skills libraries are designed as one delivery system rather than three separate purchases.

Who should own the skills library?

The skills library should be owned by a platform or engineering enablement team that sets the rules, while the teams whose work each skill encodes author and maintain their own skills, and security reviews any skill with executable code. Ownership splits three ways because no single group holds the domain knowledge, the operating standards and the security judgement at once.

In practice the split looks like this. The platform team owns the library itself: the versioning rule, the import process, which projects can enable which skills, and the trace. A domain team, for example finance operations or customer support, owns the content of the skills that describe its work, because only it can say whether an instruction is correct. Security owns the review of anything that executes, and the authority to block it. A named individual sits behind each of those roles.

Two failure patterns are worth naming. The first is a library owned by nobody, where every engineer adds skills and nobody retires them, so the library grows and its contents drift from how the work is actually done. The second is a library owned only by security, which tends to block everything and push teams back to copying files locally, recreating the ungoverned folder the library was meant to replace. A balanced RACI avoids both, and the AI tool inventory guide shows how the same ownership questions apply across every AI tool a firm runs.

Where a team wants that operating rhythm run alongside it rather than designed and handed over, our AI execution office runs the review cadence and the change log as part of a standing delivery team. For a fuller description of what the DATS consulting system covers across stages, the services page sets out each one, and if you would rather talk the ownership split through with us, contact the team directly.

What is the best way to govern an MCP skills library in 2026?

The best way to govern an MCP skills library in 2026 depends on team size and risk: a small team with a handful of instruction-only skills is well served by a git repository with mandatory review, while a team running many agents across projects needs immutable versioning tied to each run, scoped access per project and a trace. Judge any option on whether it can say which instruction an agent ran.

Four criteria separate the options:

A plain git repository with code review is the honest answer for many teams, and it wins on cost and familiarity. It meets the review criterion well and the version criterion partly, and it falls short on run linkage unless someone builds that join. Anthropic's public repository and the Agent Skills standard are the right starting point for format and examples, but they are references, not governance. Agent frameworks such as LangGraph, CrewAI and the OpenAI Agents SDK orchestrate how agents run. A governed record of which instructions those agents were given is a separate concern, which a team either builds itself or adds as a separate work layer.

Cognibl is one option for teams that want version fidelity and access scope built in, with skills in SKILL.md format versioned immutably and a deny-by-default gateway, alongside a work tracker where a task reaches a done status only once a proof version is attached and the same rule applies to a person and to an agent. The review path stays a team process whichever tool holds the library, and it is a fit when agents already do real delivery work on a shared board. Be clear about its current scope too: the Cognibl site describes it running coding agents on Claude Code and Codex, with connections to other systems read-only for now and only a person able to merge a pull request. Our overview of Cognibl sets out what it does and does not do, and our post on the engineering review queue covers how its done-gate and the merge gate divide the work.

Is a skills library the same as an MCP server?

A skills library is not the same as an MCP server. The library is the governed collection of SKILL.md instructions and their versions, while an MCP server is the doorway through which agents reach tools and context. A library can be served through an MCP server, which is how agents fetch skills in a gateway design, but the server alone says nothing about versions, owners or review.

Does a versioned library remove the need to review skill scripts?

A versioned library does not remove the need to review skill scripts. Versioning records exactly what ran, which makes an incident explainable, but it does nothing to stop a harmful script from running in the first place. Review decides whether a skill is safe to enable, and versioning proves which reviewed version an agent used, so a governed skills library needs both controls working together.

Should a team block all public skills?

A team usually should not block all public skills, because well-made public skills save real work and blanket bans push engineers to copy files locally where nobody can see them. A better rule is that no public skill reaches an agent until it has been read, imported into the team's own library as a pinned version and assigned an owner. That keeps the benefit and removes the silent-update risk.

Want to see this running on a real board? Start with Cognibl agent work management, book an AI placement diagnostic, see how an AI execution office runs it, or read about our approach to placing AI inside enterprise systems. More strategy guides sit in the strategy archive, and the team behind them is introduced on our about page.

Written by the Dilr.ai engineering team, practitioners who ship enterprise AI in production. Follow us on LinkedIn for shipping notes, or subscribe via the RSS feed.