Agent Skill Registries Need Dependency Governance

Every developer understands, at least in theory, that random packages from the internet are risky.

We learned that lesson through npm typosquats, compromised PyPI packages, suspicious install scripts, malicious browser extensions, dependency confusion, protestware, CI marketplace actions, and the long list of other ways software supply chains keep finding new doors.

Now agent skills are walking through the same door.

Except the blast radius is different.

An agent skill is not just “a prompt you install.”

It is workflow context that can shape what an agent notices, what it ignores, what tools it chooses, what scripts it runs, what files it reads, and what external instructions it treats as relevant. In a local coding agent, that skill may sit next to shell access, repository access, browser sessions, tokens, SSH keys, GitHub credentials, Slack or WhatsApp tools, cloud CLIs, and a human who is trying to move fast.

That combination is too powerful to treat like a harmless snippet library.

My take is simple:

public skill registries are useful discovery surfaces, not production trust boundaries.

The warning sign arrived quickly

In August 2026, Zenity Labs reported a campaign involving malicious AI agent skills in public registries. Their research describes skills that evade static inspection, deliver malware, manipulate agent configuration, exfiltrate data, and pull attacker-controlled behavior at runtime.

That last phrase matters: at runtime.

The old mental model is “read the file and decide if it looks safe.”

That is still necessary, but it is no longer enough.

A skill can look boring when reviewed statically and only become dangerous after the agent activates it. It can fetch remote instructions. It can ask the agent to install a package. It can route execution through a generated shell command. It can instruct the agent to persist itself. It can target the agent’s own operating rules instead of only the host machine.

This is the new wrinkle.

Malicious packages attack runtimes.

Malicious skills attack the human-agent workflow.

Skills are not normal dependencies

It is tempting to compare agent skills to npm packages, VS Code extensions, shell scripts, or CI actions.

All of those comparisons are useful.

None of them is complete.

A normal package usually has a concrete execution path. You import it, run it, or trigger its lifecycle scripts. A VS Code extension has declared capabilities and editor APIs. A GitHub Action has a workflow file and a runner context. Those systems have plenty of security problems, but at least the shape of execution is familiar.

A skill is stranger because it lives inside the agent’s decision loop.

It can influence:

• what the agent thinks the task is
• what “done” means
• which files the agent reads
• which commands feel appropriate
• which external URLs are considered authoritative
• which safety checks are skipped as “not relevant”
• which tools the agent chains together
• whether the agent asks the human or keeps going

That is not just code execution.

That is behavior steering.

And behavior steering is exactly where agent systems are fragile. The agent may have deterministic tools around it, but the path between user intent and tool call is still mediated by instructions, context, examples, retrieved files, and policy text.

A malicious skill does not need to exploit a memory corruption bug. It can just persuade the agent to do the wrong useful-looking thing.

The registry pattern is repeating

Vercel’s skills.sh announcement is interesting because it shows where the ecosystem is going: one command to install skills, public discovery, usage stats, popularity, and support across many agent tools. The public repository describes an open agent skills tool, and the related Vercel docs position skills as reusable agent resources.

That is useful.

It is also the classic registry growth pattern.

First comes convenience.

Then discovery.

Then popularity signals.

Then teams start installing whatever gets the job done.

Then attackers notice that the fastest way into a developer workflow is not always a zero-day. Sometimes it is a package name that looks right, a README that feels polished, and an install path that nobody owns.

We have seen this with package registries for years.

Agent skills add three uncomfortable upgrades to the old problem.

First, the permission surface is often bigger. A coding agent may already have access to local repositories, files, shells, GitHub, browsers, messaging channels, and internal docs.

Second, the execution boundary is fuzzier. A skill may not run a binary directly. It may instead change the sequence of decisions that causes the agent to run one.

Third, the review muscle is weak. Most teams do not yet have a normal process for reviewing skills, pinning skill sources, auditing updates, or testing skill behavior in a sandbox.

That gap is where the risk lives.

The bad skill does not have to look bad

The obvious malicious skill is easy to reject.

If a skill says “download this shell script and run it,” most serious engineers will stop.

The harder case is a skill that looks operationally helpful:

• “optimize your Codex setup”
• “make Claude Code faster”
• “install best practices for repository analysis”
• “improve your GitHub issue workflow”
• “add missing dependencies automatically”
• “repair broken agent permissions”
• “keep your agent up to date”

Those are plausible tasks.

Some of them are exactly the sort of thing a power user would want.

The danger is not that all of those ideas are malicious. The danger is that they are close to privileged maintenance workflows. A skill that modifies agent configuration, installs dependencies, rewrites instructions, or changes update behavior is sitting near the control plane.

That deserves a higher bar than “the README looked fine.”

Treat skills like delegated access

The cleanest mental model is this:

installing a skill is closer to delegating work to an automation engineer than importing a text snippet.

The skill may not be a person, obviously. But it can shape what your agent does while carrying your permissions.

So the intake process should look more like access governance than content curation.

For internal teams, I would start with a simple skill intake checklist:

• Where did this skill come from?
• Who owns it internally?
• Which agent runtimes will load it?
• What tools can those agents use?
• Does the skill reference extra files?
• Does it fetch instructions from remote URLs?
• Does it tell the agent to run commands?
• Does it install packages?
• Does it modify agent config, prompts, memory, hooks, or other skills?
• Does it touch credentials, browsers, shells, cloud CLIs, messaging tools, or repositories?
• How are updates reviewed?
• Can we disable it quickly?

That is not bureaucracy for its own sake.

That is dependency management adapted to a world where dependencies can influence autonomous behavior.

Pin sources and review the whole skill, not just SKILL.md

A skill is rarely only one file.

Many systems use progressive disclosure: a short skill file points the agent toward scripts, references, templates, assets, or follow-up instructions only when needed. That is a good design pattern for context efficiency.

It is also a supply-chain hiding place.

If your review stops at the top-level SKILL.md, you have not reviewed the skill.

You need to inspect the referenced files too:

• scripts
• templates
• examples
• bundled binaries
• package manifests
• remote URLs
• install hooks
• update logic
• generated command snippets

The same goes for source pinning.

“Install the latest version from a public directory” is not a trust strategy. It is a convenience strategy.

For production-like agent environments, pin the exact source. Prefer internal mirrors or allowlisted repositories. Review updates like dependency bumps. Keep a changelog. Make the agent’s effective skill set observable.

This does not mean nobody can experiment.

It means experimentation and production delegation should not share the same trust boundary.

Static review is necessary, dynamic testing is better

Zenity’s research is useful because it emphasizes runtime behavior. Their AI Total approach is basically a detonation chamber for agent skills: run the skill with an agent inside a contained environment and observe what it actually does.

That is the right direction.

For teams that cannot build a full detonation system, a lightweight version is still better than nothing:

• load the skill in a disposable agent profile
• use a sandboxed filesystem
• seed fake credentials and fake repositories
• block or log network access
• record every tool call
• inspect files written by the agent
• inspect packages installed by the agent
• compare claimed behavior with observed behavior

The goal is not to prove the skill is safe forever.

The goal is to stop pretending that a text review catches runtime deception.

The practical policy I would use

If I were responsible for agent skills inside an engineering organization, I would split them into four tiers.

Personal experiments can be installed by developers in isolated local profiles with no privileged credentials and no access to production-adjacent systems.

Team-approved skills require code review by someone who understands both the task domain and the agent runtime. They can be used for normal development work but not privileged operations.

Privileged workflow skills need stronger review, pinned sources, dynamic testing, audit logs, rollback paths, and explicit ownership. These are skills that can influence infrastructure, security, release, incident, repository, or dependency workflows.

Forbidden skills include anything that self-updates without review, fetches remote instructions without an allowlist, modifies agent safety rules, hides tool calls, persists after removal, handles secrets unnecessarily, or tells the agent to install unverified executable dependencies.

That is enough to start.

The important part is not the exact tier names. The important part is admitting that not every skill deserves the same trust.

Popularity is not assurance

Registry leaderboards are useful for discovery, but popularity is a terrible security control.

Package ecosystems already proved this. Widely installed things can be compromised. Popular names can be spoofed. Maintainers can be phished. Old packages can be transferred. Install counts can lag behind reality. Attackers can optimize for trust signals because trust signals are part of the attack surface.

Agent skills make that worse because the “package” may influence judgment, not only execution.

Do not ask:

Is this skill popular?

Ask:

What authority does this skill get when my agent loads it?

That is the real question.

This is another platform engineering problem

The uncomfortable truth is that agent skills will be useful.

Teams will want them.

They should want them.

Reusable workflows are exactly how organizations turn one person’s hard-earned operational knowledge into something the whole team can use. A good skill can encode how to triage incidents, prepare releases, review pull requests, inspect repositories, generate docs, publish posts, debug flaky tests, or operate internal tools.

That is powerful.

But useful shared automation always becomes platform work.

The platform has to answer:

• where skills live
• how they are reviewed
• how they are installed
• how they are updated
• how agents are sandboxed
• what tool calls are logged
• which skills can run in which environments
• who owns the rollback button

That is not an AI novelty. That is internal platform governance wearing a new jacket.

The punchline

Agent skills are going to become part of the software supply chain.

Not later.

Now.

And the teams that treat public skill directories like harmless prompt galleries are going to repeat the package-registry trust mistake with a bigger permission surface.

The right posture is not panic. Skills are useful, and public registries can help the ecosystem grow.

But discovery is not trust.

Before a skill gets loaded into an agent with access to real repositories, shells, browser sessions, credentials, messaging tools, or internal systems, it deserves the same seriousness we already learned to apply to packages, extensions, CI actions, and infrastructure modules.

Review it.

Pin it.

Test it dynamically.

Observe what it does.

Give it only the authority it needs.

And never confuse “easy to install” with “safe to delegate.”

To test my projects, I use Railway. If you want $20 USD to get started, use this link.