Between September and December 2025, a worm nicknamed Shai-Hulud became the first self-propagating supply-chain attack against npm: stolen maintainer credentials — traced back to the earlier s1ngularity/Nx compromise — let malware auto-publish trojanized versions of any package a stolen token could reach, then harvest new tokens from each victim to keep spreading. A second wave in November 2025, tracked by Wiz, Unit 42, Microsoft, Sysdig, and Sonatype, touched roughly 25,000 GitHub repositories across some 350 unique accounts. npm's own answer, arriving years earlier but validated by exactly this kind of incident, was Sigstore-based provenance attestations — keyless signing bound to CI identity, published to a public transparency log — which moved from public beta in April 2023 to general availability after more than 3,800 projects and 134 high-impact packages covering 500 million-plus downloads adopted it. PyPI ran the same playbook after its own phishing and typosquat incidents, shipping OIDC-based Trusted Publishing and PEP 740 attestations. AI agent skill registries — the marketplaces now distributing tool definitions, MCP servers, and autonomous-agent "skills" — are at the stage npm and PyPI were in roughly 2018: open publishing, mutable metadata, and no cryptographic link between a skill and the identity that built it. Here's what they should adopt before their own Shai-Hulud moment.
Why is an unsigned skill registry more dangerous than an unsigned package registry?
An unsigned skill registry is more dangerous because a skill doesn't just execute code once at install time — it's re-invoked by an autonomous agent on every task, often with access to file systems, credentials, and other tools the agent has been granted, and the agent decides when to trust the skill's instructions as if they were part of its own reasoning. A malicious npm package needs a build script or an imported function to trigger; a malicious skill only needs text in its description or invocation output that an LLM will read and act on, a pattern security researchers have documented as prompt injection via tool output since at least 2023. Skill registries today largely mirror npm's pre-2023 posture: publishers self-attest, versions are mutable by whoever holds the account, and there is no equivalent of an SLSA provenance predicate saying which commit, which CI job, and which reviewer produced a given skill version. That gap means an agent has no way to distinguish "this skill was built by the maintainer's CI from the reviewed source" from "this skill was pushed from a compromised laptop."
What does npm's provenance model prove, and how does it map to a skill?
npm's provenance model proves three things cryptographically: which source repository and commit produced the artifact, which CI workload built it, and that the built artifact matches what was published — all without a long-lived signing key an attacker could steal. Sigstore's Fulcio issues a short-lived certificate to the CI job itself, bound to its OIDC workload identity (GitHub Actions, GitLab CI, and similar), the artifact is signed with a single-use keypair discarded immediately after, and the resulting in-toto-formatted SLSA provenance predicate is published to Rekor, Sigstore's public append-only transparency log. Mapped onto a skill registry, the same three facts should be published alongside a skill's manifest: the exact source commit, the CI identity that packaged it, and a transparency-log entry any downstream agent runtime can query before loading the skill. Because the signing key is ephemeral and workload-bound, stealing a registry account's publish token — the exact vector Shai-Hulud used — no longer lets an attacker forge a matching build identity.
What should a minimum signing standard for skill registries require?
A minimum standard should require four things before a skill is publishable at all: keyless signing via a Sigstore-compatible OIDC identity (or an X.509/Notation chain to an organization's own CA for regulated environments), an in-toto attestation covering build provenance at SLSA Level 1 at minimum, a machine-readable manifest of every capability and external call the skill can make, and publication of the signature to a transparency log the registry doesn't control unilaterally. SLSA's own level ladder is instructive here: Level 1 only requires that provenance exist, Level 2 requires a tamper-resistant build service, and Level 3 requires an isolated, parameterless build — a skill registry could reasonably gate "verified publisher" status on Level 2 the way npm gates its provenance badge on CI-originated builds, without demanding every hobbyist skill hit Level 3 on day one. The point isn't maximal rigor everywhere; it's that today most skill registries require zero of these four, which is strictly worse than where npm sat before 2023.
Why does capability declaration matter as much as build provenance?
Capability declaration matters as much as build provenance because a perfectly signed skill can still be malicious by design — signing proves who built it, not what it's allowed to do. A skill that legitimately needs read access to a calendar has no reason to also request outbound network calls to an arbitrary URL, and today most skill manifests don't distinguish those cases in a way a runtime can enforce automatically. PyPI's PEP 740 attestations point at the right shape: a structured, signed statement about the artifact's properties, not just its checksum. A skill-registry equivalent would attest to a declared capability set — filesystem scope, network egress targets, credential access — signed alongside the build provenance, so an agent runtime can deny-by-default anything outside the declared set rather than trusting the skill's own prose description of what it does.
How should agent runtimes verify a skill before invoking it, not just before installing it?
Agent runtimes should verify at invocation time, not only at install time, because a skill fetched from a registry can be updated after an agent first pulled it, and a compromised publisher account can push a new malicious version between an agent's install and its next use — the identical window Shai-Hulud exploited by pushing malicious versions the moment a token was stolen. The check should mirror what Safeguard's own design for container-workload admission control specifies: confirm the artifact digest matches a signed attestation, confirm the signer identity is on an allow-list scoped to that registry or organization, and confirm the attested SLSA level meets policy — denying invocation, not just flagging a warning, when any check fails. Safeguard has specified exactly this pattern for build artifacts — Sigstore keyless signing, in-toto attestations covering SLSA provenance and SBOM, and a Kubernetes admission control path that denies deployment when signer identity or SLSA level doesn't meet policy — as the blueprint for its own artifact-verification work. A skill-registry runtime check is the same logic applied to a different artifact type, and it's a smaller lift than it sounds — the cryptographic primitives npm and PyPI already proved out at hundreds-of-millions-of-downloads scale.
What would a minimum-viable rollout actually look like for a registry operator?
A minimum-viable rollout looks like npm's own phased approach: ship optional provenance first, badge it visibly, then make it a prerequisite for any "verified" or featured placement, and only later consider requiring it registry-wide. npm ran a five-month public beta before general availability and still didn't mandate provenance for every package — adoption climbed because verified badges became a visible trust signal buyers filtered on, not because publishing was blocked outright. A skill registry can follow the same sequence: add Sigstore signing support and a transparency-log query endpoint, surface a "provenance verified" badge in search results, then require it for any skill requesting filesystem or network capabilities beyond a minimal default. That ordering avoids the adoption cliff of an unenforced mandate while still closing the gap that let Shai-Hulud's second wave reach tens of thousands of repositories before the ecosystem had a way to see it coming.