
Agent skills are the newest dependency in your software supply chain

Every skill a team installs hands an AI agent new instructions to follow and, often, new code to run. A skill is a set of written instructions, sometimes with scripts and reference files, that an agent loads when a task calls for it: following a review process, querying an internal tool, or formatting a report to the team’s standard. Like a package, a skill is a separate bundle that gets pulled in and run, whether your own team wrote it or someone else did.
People in engineering, operations, analytics, and beyond now write their own skills or pull them from wherever they find them, often with no one outside the team reviewing them. And a skill’s instructions can tell an agent to install packages, so one unreviewed skill can bring in more dependencies.
Teams already govern npm packages and container images through an artifact registry and the packages agents install can go through the same checks today. The skills themselves are the next dependency to bring under that control.
What a skill is and why it behaves like a dependency
An AI agent skill can include several types of files. A SKILL.md holds the skill’s metadata (a required name and description) and the instructions the agent follows. Optional folders hold reference docs, templates, and scripts that can include executable code the agent can run.
Agents typically have access to your repository credentials, internal APIs, production data, and other potentially sensitive information, depending on how you configure them. The agent follows the instructions in the SKILL.md file and runs any bundled scripts as necessary, giving those scripts the same access that the agent has or, where the agent asks for approval, whatever the user approves. A skill that is malicious, changed, or simply wrong can cause an agent to leak data, run harmful commands, or take actions no one intended.
A skill pulled from a public catalog or repository raises the same questions as any open source package: who wrote it, what changed, and whether anyone reviewed it. Skill instructions can tell an agent to install packages, so one unreviewed skill can pull in dependencies nobody chose. We’ve written previously about the need to secure the packages that AI agents install.
Skills spread faster than anyone can track them
Skill usage spreads quickly because anyone, not just developers, can create and share them. With AI assistance, analysts, operations staff, and other non-developers can build and iterate agent skills. And these skills live all over the place: Git repositories, community catalogs, standalone registries, and individual workstations.
Catalogs and Git hosts make skills easy to share and leave governance to whoever pulls them. Skills you develop within your organization may be subject to the Git-based controls in place for general development, providing visibility into review, history, and ownership of individual skills.
Security teams need insight into which version of a skill every agent pulls, what public skills people are downloading and installing, and who within the organization is making these trust decisions, and Git doesn’t tell you that.
Public skill catalogs catch some, but not all, malicious skills
Developers are used to public registries like npm and PyPI. ClawHub, OpenClaw’s public skill registry, plays that role for agent skills. Since February 2026, at least four independent research teams have documented waves of malicious skills on ClawHub. Koi Security alone found 341 among 2,857 skills it audited. Even as ClawHub added scanning capabilities with ClawScan, attackers found routes around it. For example, Unit 42 found one skill padded to exceed scanner size thresholds, which slipped past both ClawScan and VirusTotal until researchers reported it.
Server-side scanning and removing flagged skills help to mitigate the impact of malicious skills. Some users may pull from a centralized catalog like ClawHub, but others install straight from Git repositories, or through catalogs like skills.sh that hand off to Git instead of hosting a reviewed copy. The fragmentation of skills distribution puts the onus on your organization to decide what is allowed to cross its trust boundary.
Visibility lets security make informed decisions about approving skills
A governed control plane would let security teams quickly answer basic questions: which skills exist in the environment, which versions agents pull, and which policies were applied.
Security teams can ban or require manual review of skills, but that creates friction, slows development, and is the type of control that leads to workarounds. Rules set once let security stay in control while teams keep moving.
Start with the packages agents install
Agents install packages the same way developers do, often without anyone reviewing the choice. Route both through Cloudsmith to check every package against your policies before it reaches a laptop or a pipeline. Only packages that pass your vulnerability, malware, and license rules get installed, and every pull lands in the same audit log.
The next step: treat agent skills like any other dependency
Guardrails for what a skill installs are just the start. The skill itself is the next dependency to bring under the same control. Artifact registries have done this job for packages and containers for years, and skills fit the same model. A skill is a bundle of files, like a package. The spec doesn’t require a version, so a skill pulled from Git can change under the same name. A registry that treats skills as packages would pin each release, so you’d know exactly which release every agent pulled.
Routing skills through a registry would give internal teams a place to publish, version, and control access to the skills your organization develops, and a record of which skills and versions every agent pulls.
Give skills the same entry point as everything else
Teams will keep writing and sharing skills, because skills make agents useful. Start with the packages your agents install today, then treat the skills themselves like any other dependency.
Skills will keep changing. When every skill comes through your artifact registry, you see each change as it arrives.
Discover how Cloudsmith solves artifact management challenges.
More articles


Simplify repository structure with connected repositories

Dependency confusion and trust boundaries in modern builds

LLMOps vs DevOps: What LLMOps means for artifact management

Why cloud migrations are the best time to re-evaluate your artifact management

