Supply-Chain Playbook for Agent Skill Markets

A platform team is evaluating an agent skill marketplace ahead of a company-wide rollout. The marketplace has thousands of skills, a star rating, a search box, and a publisher field that's an unverified email. The team's security review starts with the question they ask of every other dependency source: what's the trust model? The answer comes back as a shrug. There's no signing requirement. There's no Trusted-Publisher-style OIDC path. There's no consumer-pinning enforcement, no capability manifest standard, no publish-time malware scanning that the team can point to. The "trust model" is the marketplace operator's reputation, applied uniformly to every skill regardless of what it does.

This resembles the early trust model of npm and PyPI. Their history shows the likely failure modes — the event-stream incident on npm in 2018, the ctx package takeover on PyPI in 2022, typosquatting waves, and the gradual adoption of mandatory 2FA, provenance attestations, and OIDC trusted publishing. Each predecessor took years of incidents and controls to converge on a stronger playbook. Our earlier analysis cited a report of 1,184 malicious skills on OpenClaw's ClawHub in early 2026 — the exact number matters less than the pattern: agent skill marketplaces are already seeing package-registry-style abuse.

Agent skill marketplaces should plan for supply-chain risks analogous to package registries, plus risks specific to prompts and tool composition. The response cycle does not have to repeat every predecessor incident: Sigstore provenance and OIDC-based trusted publishing have mature reference implementations, while capability manifests and runtime limits still need ecosystem-specific design and validation.

What the predecessors learned, in roughly the order they learned it

The package-registry security playbook was written incrementally, usually after a high-profile incident. Each control closes a class of attack the previous controls didn't see.

Year(s)	Ecosystem	Incident or shift	Control adopted
2018	npm	event-stream — maintainer trust transferred to a malicious actor; Bitcoin-wallet-stealing payload shipped through the popular event-stream package with broad downstream reach	Maintainer trust models tightened; eventual move toward 2FA
2017–2022	PyPI / npm	Typosquatting waves: colourama, AWS-named exfiltrators, @colors variants	Registry-side typosquat detection at publish
2021	npm	ua-parser-js compromise — popular library hijacked via maintainer-account takeover	Account hardening; password+2FA pressure
2021	Industry	Sigstore launched (Google + Linux Foundation): short-lived certs, transparency log	Foundation for ecosystem-wide signing
2022	PyPI	ctx package takeover — maintainer's expired domain enabled email-based account reset	Email-domain controls; 2FA push for top maintainers
2023	npm	Provenance attestations via Sigstore — eligible publishers can attach signed build context	Cryptographic provenance for participating packages
2023	PyPI	Trusted Publishers (OIDC) — participating projects can publish from CI without long-lived API tokens	OIDC-based publishing adds a token-free path
2024	XZ Utils	Multi-year social-engineering attack on a single maintainer	Recognition that maintainer trust is a long-horizon attack surface
2025	npm	Mandatory 2FA for local publishing; classic tokens phased out	Identity becomes a hard requirement, not an optional control

Two patterns repeat. First, every control was a response to a class of incident, not an a-priori design — registries adopted them because users got hurt. Second, the controls converge: by 2026, the leading registries are ending up at roughly the same playbook (identity hardening + provenance attestations + OIDC publishing + automated scanning + ecosystem trust signals), even though they got there by different paths. That convergence is the cheat sheet.

The control set leading package ecosystems are converging on

Stripped down to what each control does, independent of the registry:

1. Verified publisher identity with mandatory 2FA. Email-only signup with a single password is where most attacks start. The fix is identity verification, mandatory 2FA on accounts that can publish, and shrinking the lifetime of any published-from-machine credentials.

2. Provenance attestations cryptographically tying artifact to source. Sigstore-style: participating artifacts carry a signed statement tying the build to source and CI identity, with the signature logged in a transparency log. This establishes origin and build history, not that the artifact is benign. npm and PyPI both added provenance mechanisms between 2023 and 2026.

3. Trusted Publishers / OIDC-based publishing. Long-lived API tokens are credential-theft amplifiers. OIDC-based publishing lets a CI workflow prove its identity to the registry per publish without a static registry token. That removes one credential class from the flow, but CI compromise and identity-policy errors remain possible. PyPI introduced Trusted Publishers in 2023, npm supports the same pattern, and OpenSSF describes the cross-repository model.

4. Typosquat detection at publish time. Registry-side checks block obvious lookalikes before publication. Catch isn't perfect, but it's much better than nothing — npm explicitly blocks typosquat publishes today.

5. Automated malware scanning at publish and update time where possible. Leading registries increasingly use registry-side detection for known malicious patterns, typosquatting, and suspicious behavior. Not a complete defense — novel attacks slip through — but it raises the cost of obvious approaches and gives operators something to alert on.

6. Versioned, immutable releases with consumer-side pinning. Once published, a version doesn't change. If a maintainer wants to update, they cut a new version. Consumers control their own update cadence via lockfiles or pin files. This is the property that makes "rollback to a known-good version" tractable when something goes wrong.

These six are not uniformly implemented everywhere, and they are not a complete answer to supply-chain security. The XZ attack survived all of them because it compromised the maintainer over years before any malicious commit appeared. But they are the direction leading registries are converging toward — and they are the floor against the most common attack classes.

Where agent skill marketplaces sit today

In aggregate — and necessarily generalizing — the agent skill marketplace category in mid-2026 looks roughly like this on each control:

Control	Typical state in agent skill marketplaces (mid-2026)
Verified publisher identity + 2FA	Inconsistent — some marketplaces require it, others accept email-only signup
Provenance attestations (Sigstore-style)	Mostly absent; no ecosystem-wide standard
OIDC trusted publishing	Not yet adopted at scale
Typosquat detection at publish	Inconsistent; varies by marketplace operator
Automated malware/behavior scanning	Some marketplaces scan; coverage and depth vary
Versioned immutable releases + consumer pinning	Patchy — many marketplaces auto-update by default with no pinning story

This isn't a criticism of any specific marketplace — every package registry started here, and the leading ones took years to mature. It's a description of the category position. The agent skill ecosystem is in roughly the same place as npm circa 2015: rapidly growing user base, expanding plugin surface, ad-hoc moderation, no cryptographic provenance, and the first significant supply-chain incidents already starting to land.

The good news is that several building blocks are available off the shelf:

• Sigstore is already production-deployed at npm and PyPI. The cosign toolchain signs anything; an agent skill marketplace can adopt the same primitive without building cryptography.
• Trusted Publishers / OIDC has a published spec via OpenSSF and reference implementations from npm and PyPI. Agent marketplaces can follow the same pattern.
• Typosquat detection is a well-understood pattern — Snyk, npm, and others have published their heuristics.
• Versioned immutable releases is a registry-design choice, not a research problem.

The cost of adopting these now is much smaller than adopting them after a trust-breaking incident. The cost of waiting is paid in user trust, after.

What's specific to agent skills (and not yet in the predecessor playbook)

Even if every agent skill marketplace shipped all six package-registry controls tomorrow, the playbook wouldn't be complete — because skills aren't packages.

A traditional package is mostly code. A skill is code plus prompts plus context plus tool-orchestration logic, and that combination opens attack surface that signing-and-scanning doesn't cover. Three concerns the package playbook never had to handle:

1. Instructions are executable in a softer way than code. A signed skill can still contain a Markdown file that, when parsed by a model, redirects the agent to a malicious tool. The signature is valid; the artifact is unmodified; the behavior is hostile. Static scanning of code doesn't see prompt-injection paths because they aren't code paths.

2. Tool composition multiplies the API surface. A skill that declares read_file and send_email separately may be benign in isolation but harmful when composed — read sensitive file, send to attacker-controlled address. Reviewing each tool independently misses the chain.

3. The capability declaration matters more than the inventory. It's not enough for a skill to declare which tools it uses. Operators need declarations of what data classes the skill touches, what egress destinations it may use, what risk tier its actions sit in. The skill manifest as contract covers this from the consumer side; for it to scale across a marketplace, the manifest format has to be a marketplace requirement, not a per-skill courtesy.

Two additional controls follow that aren't in the package-registry playbook:

7. Mandatory capability manifests. Every skill in the marketplace declares — in a machine-readable, signed-as-part-of-the-attestation, format — what tools it requests, what data classes it accesses, what network destinations it may reach, what filesystem scope it needs, and what risk tier its actions sit at. Without this, capability review at install time is guesswork. The agent skills supply-chain post sketches the manifest fields; the marketplace's job is to require them.

8. Per-consumer runtime blast-radius hooks. A signed manifest tells the consumer what a skill says it does. Runtime enforcement bounds what it actually does in this consumer's environment. The two are complementary: marketplace-side controls keep most attacks out; runtime authority bounds the damage of the ones that get through.

What runtime authority adds at execution time

Marketplace-side controls — identity, signing, scanning, OIDC, manifests — are the publication gate. They reduce the chance of compromised skills reaching consumers and improve attribution and incident response. Provenance establishes where an artifact came from and how it was built; it does not establish that the artifact is safe. These controls do not bound execution.

A mandatory runtime authority boundary adds another layer. As MCP Gateways Are Not Runtime Authority explains, access control and cumulative exposure are separate decisions. The same primitives the local-first runtime post calls out for cross-runtime governance can apply at the per-skill level inside a runtime:

• Capability declarations can become enforceable contracts. A host or handler can compare the proposed tool against an approved manifest before execution. Cycles can separately reserve a caller-assigned budget, but the current server does not maintain the capability manifest or automatically count invocations by action kind.
• Risk-tier classification can assign budget independent of cost. The caller maps each attempted action to RISK_POINTS and makes the reservation mandatory. This is an application policy, not automatic server-side classification.
• The three-way decision is external to prompt content. A dry-run or decide call returns ALLOW, ALLOW_WITH_CAPS, or DENY; a live reservation succeeds with ALLOW or ALLOW_WITH_CAPS, or rejects insufficient budget. The host still has to enforce the result before running the skill.
• Per-runtime, per-skill submitted exposure can be made observable. Live reservations and settlement create the applicable reservation, balance, and audit records, while only selected transitions emit runtime Events. decide and dry-run evaluations create no reservation or balance mutation; denied evaluations emit reservation.denied in the current reference server, but allowed evaluations and external outcomes still require host logging. Retain attempted calls and capability-policy decisions if a security team needs to answer "what did skill X actually try across our fleet last week?"

The pattern that makes this work is the same one that makes the package-registry playbook work: enforce at the layer where the consequence happens, not at the layer where the artifact happens. Provenance provides evidence about artifact origin and integrity. A mandatory Cycles boundary proves the submitted estimate passed the configured budget checks; host authorization and outcome logs cover whether the action itself was permitted and what happened. These controls are complementary.

Minimum viable marketplace policy

Before approving an agent skill marketplace for company-wide use, security review can ask for at least these:

• Verified publisher identity
• Mandatory 2FA for accounts that can publish
• Immutable, versioned releases
• Consumer-side pinning (lockfile or equivalent)
• Provenance / attestation support, ideally Sigstore-based
• Registry-side malware and typosquat scanning
• Machine-readable capability manifests
• Runtime hooks for per-skill caps and denials in the consumer's environment

A marketplace that has shipped most of these is taking the supply-chain risk seriously. A marketplace with none of them is asking each consumer to manage that risk individually — which is exactly where every other ecosystem started.

A compressed timeline for the agent ecosystem

The package registries took roughly a decade because each control was reactive — a new incident motivated each new measure, and the path from incident to widespread adoption was slow. The agent skill marketplace ecosystem doesn't have to repeat that. The shape of a compressed adoption path:

1. Now: Marketplaces require verified publisher identity and 2FA on accounts that can publish. This is the cheapest control with the largest immediate effect.
2. Next: Adopt Sigstore-based provenance attestations as the default for new publications. Don't reinvent — npm and PyPI's implementations are reference material.
3. Soon: OIDC-based Trusted Publishing for CI workflows. Removes long-lived registry tokens from the normal publish path and narrows that attack surface.
4. In parallel: Typosquat detection and automated malware scanning at publish. These are well-understood; the cost of adoption is integration, not research.
5. As the manifest standard matures: Mandatory capability declarations as part of the published artifact, signed alongside the code.
6. At runtime, for consumers that need hard caps: Mandatory hooks that enforce declared capabilities and reserve caller-assigned budgets. This is a consumer-side control, not a marketplace feature.

The registry controls have working reference implementations in package ecosystems. Applying them to agent skills still requires threat modeling, integration work, and validation, especially for manifests and runtime action boundaries.

The takeaway

Major executable supply chains — packages, containers, CI actions, and OS images — increasingly use overlapping controls after repeated incidents. Agent skill marketplaces can reuse those lessons: signing and provenance, strong publisher identity, fewer long-lived tokens, immutable releases, and consumer pinning. The implementation details still need to fit the agent ecosystem.

The asymmetric thing about the agent layer is that signed-and-scanned isn't enough. A skill is more than its code; the prompts, examples, and context it ships with can change agent behavior in ways static review doesn't catch. Marketplace-side controls reduce the rate of bad skills reaching consumers. Runtime authority bounds the damage when one does anyway. Both layers are necessary, neither is sufficient.

The lowest-regret move for any agent skill marketplace right now is to look at where npm and PyPI are in 2026 and adopt that destination directly. The longer move is to extend the playbook with capability manifests and runtime-authority assumptions, because skills introduce risks the package registries never had to govern. The expensive move is to wait for the equivalent of event-stream to make the case.

Sources

• npm: Details about the event-stream incident — primary post-mortem from npm's security team
• Supply Chain Attacks 2024–2026: XZ, npm, and PyPI Lessons — recent incident analysis across registries
• Introducing npm package provenance — GitHub Blog — Sigstore-based attestations on npm
• Trusted publishing for npm packages — OIDC-based publishing reference
• PyPI digital attestation support — deps.dev — PyPI's parallel adoption of Sigstore attestations
• npm: Threats and Mitigations — current registry-side controls including typosquat detection
• GitHub Changelog: npm classic tokens revoked — npm classic token phaseout (Dec 2025) and session-based auth
• Sigstore — the signing/transparency-log primitive both registries adopted

Related reading

• Agent Skills Are the New Supply Chain — the consumer/operator-side companion to this post; manifest fields, RISK_POINTS, sandboxing, the 8-step adoption model.
• MCP Tool Poisoning — the ClawHub incident referenced in the opening, plus the broader tool-metadata attack surface.
• Why Local-First Agent Runtimes Need Runtime Authority — the category-level argument this post extends to the marketplace layer.
• AI Agent Risk Assessment — the risk-tier framework the runtime-authority section invokes.
• AI Agent Action Control: Hard Limits and Side-Effects — what bounded action authority looks like at runtime.
• Agent Registries Are Not Runtime Governance — the inverse argument: why a registry alone doesn't replace the runtime layer.