Why AI agent skills are the next software supply chain risk.

What just got proven at Black Hat

Black Hat USA closed this week, and the AI agent security research presented there moved a risk that consultants like us had been describing as emerging into something with a body count. Zenity Labs disclosed an active credential-stealing campaign distributed through Vercel's skills.sh, a marketplace for the reusable "skills" that let AI agents perform specialized tasks. One affected skill family had amassed more than 1.7 million aggregate installs before it was caught. Nearly a third of the 121 briefings at the conference, 35 in total, addressed AI security directly, and agent skill supply chain risk was one of the sharpest threads running through them.

If you have not been tracking this closely, the short version is that "skills," the packaged, installable capabilities that extend what an AI agent can do, are having their npm moment. Every ecosystem that lets developers install and run someone else's code with minimal friction eventually gets targeted by someone who wants to run their code on your infrastructure instead. Skills marketplaces are that pattern again, except the thing installing and running the package is an autonomous agent with broad tool access, not a human reading a README first.

The install-and-run trust model, and why it fails

Most agent skill marketplaces today work the same way early npm did: a developer finds a skill through search or a trending list, installs it with a single command, and it runs with the agent's full privileges the next time that capability is invoked. There is typically no formal review, no code signing, and no declared capability manifest that would let a host say "this skill may read files but should never make an outbound network call." The skill is usually just markdown and code that the agent interprets and executes.

That model is convenient, which is exactly why it spread so fast, and it is also why it failed so predictably. A crawl of one major open registry earlier this year found that 80 percent of published skills showed at least one mismatch between what they declared they would do and what they actually did once running. That gap is not always malicious. Plenty of it is sloppy documentation. But it means the marketplace cannot tell you, and often the developer installing the skill cannot tell either, what a skill is actually capable of until it has already run.

Three campaigns, one pattern

The Zenity disclosure was not an isolated incident. Look at the last six months of research and a consistent playbook emerges across three separate ecosystems.

• Vercel's skills.sh (Zenity Labs, August 2026). Attackers cloned existing, legitimate skills and published typosquatted lookalikes that did nothing malicious at first. The fake skills sat clean, accumulated installs and trust, and only after building a real download count did the operators quietly slip in instructions telling the agent to exfiltrate SSH keys, cloud credentials, git and package manager tokens, Kubernetes and Docker configs, database credentials, infrastructure-as-code secrets, and environment files.
• OpenClaw's ClawHub (multiple researchers, early 2026). Bitdefender Labs found roughly 17 percent of skills carried malicious payloads in the platform's first weeks. Koi Security later audited all 2,857 skills on the registry and confirmed 341 as malicious. A separate campaign, tracked as ClawHavoc, planted more than 1,200 malicious skills that deployed the AMOS credential stealer directly to developer workstations.
• MCP server marketplaces (OX Security, April 2026). A systemic vulnerability class in Model Context Protocol SDKs affected an estimated 200,000 servers and 150 million downloads. When researchers submitted proof-of-concept malicious entries to eleven MCP marketplaces as a test, nine accepted them with no review at all.

The technical details differ, but the shape is identical every time: a low-friction publishing model, no meaningful review gate, a trust signal (install count, trending placement, a clean track record) that is trivially gameable, and a payload that runs with far more privilege than anyone examining the marketplace listing would assume.

Why the delayed-payload trick works so well

The build-trust-then-pivot pattern deserves its own callout because it defeats the one control most teams already believe they have: "we checked it before we installed it." A skill that is genuinely clean for its first thousand installs will pass any spot check, any manual code read, any one-time security review. The malicious behavior only exists in a version published weeks later, often shipped as a routine-looking update. Static, point-in-time review catches none of this. Only continuous, runtime-aware monitoring does.

Why this is structurally different from a bad npm package

Software supply chain security is not a new discipline, and it is tempting to reach for the same playbook that worked for dependency scanning. Two things make agent skills a materially different problem rather than the same problem in a new outfit.

• The blast radius is the agent's blast radius, not the package's. A compromised npm package can only do what the code path that imports it allows. A compromised skill inherits whatever tool access, credentials, and system reach the agent itself has been granted, which in most production deployments is considerably broader than a single library's import surface.
• The exploit target can be the reasoning, not just the code. Research presented at the same conference, Check Point's work on post-injection exploitation across agent frameworks, reframed the attack surface as the framework's decision-making logic rather than the tools it calls. A malicious skill does not need a classic vulnerability. It can just tell the agent to do something harmful in language the agent will follow, and the agent will comply exactly as designed.

A practical vetting and containment framework

None of this means avoiding skill ecosystems. The productivity gain is real and teams are not going to stop using them. It means treating a skill install the way you would treat granting a new employee production access, not the way you treat adding a utility library.

• Run new and updated skills through dynamic analysis before trusting them. Execute the skill in a contained environment and observe its actual runtime behavior, network calls, file access, credential reads, rather than relying on what it claims to do. This is the exact gap Zenity's own AI Total tool was built to close, and the pattern is worth adopting even if you build the sandbox yourself.
• Re-check on every update, not just on first install. The delayed-payload pattern means your review has to repeat every time a skill's version changes, not once at onboarding. Pin skill versions and require the same scrutiny for a version bump as for a new install.
• Scope agent credentials as if a skill will eventually be hostile. The agent's own access is the real ceiling on what any compromised skill can do, so apply least privilege at the agent identity level, not just at the skill level, and give every credential an expiry.
• Prefer marketplaces and registries with an actual review gate. The nine-out-of-eleven acceptance rate for planted malicious entries in MCP marketplaces is a usable due diligence question to ask any vendor or registry before your team standardizes on it: what is your review process, and can you show it catching something.
• Maintain an internal allowlist, not an open marketplace default. Let engineers request a skill be reviewed and added to an approved internal list rather than installing directly from a public registry, the same posture most mature orgs already apply to browser extensions and VS Code plugins.

What to do this month

If your team has adopted agent skills, MCP servers, or any comparable plugin ecosystem in the last year, the useful next step is not a policy document, it is an inventory. Most teams we talk to cannot currently list every skill installed across their engineering org, which credentials the hosting agent can reach, or when each skill was last updated. That inventory is the prerequisite for everything else on this list, and it usually takes less time to build than people expect once someone actually owns the task.

This is the same lesson the software industry already learned once with open source dependencies, arriving faster and with higher stakes because the thing running the untrusted code now has agency of its own. If you are standing up agent skill or MCP adoption at scale and want an outside audit of what is actually installed and what it can reach, that kind of review is core to the AI consultancy work we do for engineering teams moving past the pilot stage. Start with the inventory, then the credential scoping. Everything else gets easier once you know what is actually running.

Keep reading

• How to review AI-generated code for security risks before it ships AI-generated code passes security review only 56% of the time. A practical review gate to catch vulnerable patterns and hallucinated packages before they ship.
• Securing MCP servers before they reach production A practical guide to running Model Context Protocol servers in production: blast radius, authentication, gateways, untrusted tool output, and audit.
• AI agent identity management: securing non-human access before it scales Why AI agents need their own scoped, ephemeral identities, the four failure modes we keep finding, and how to build a registry that survives an audit.
• The keyv npm supply chain attack: what happened, and how to respond A compromised maintainer account turned keyv and cacheable into a worm-scale npm attack with valid signed provenance. What happened, and the pipeline changes that actually help.