AGENT SKILL SUPPLY CHAIN

AI Skill Supply Chain: the 2026 Attack Ledger, Scanner Gaps, and the 7-Layer Install Checklist

Agent skills are not bookmarks — they are a software supply chain. A SKILL.md file travels from a public repo, through a registry, into your agent's context window, where its instructions execute with your terminal's permissions. In 2026 that pipeline was attacked at every stage: Snyk found 13.4% of 3,984 public skills carrying critical issues and confirmed 76 malicious payloads; Trail of Bits bypassed every production skill scanner in under an hour each. This page maps the full attack ledger, what the scanners actually cover, and the seven-layer checklist for installing skills without getting breached.

Are Claude skills safe? The audit evidence Compare skill registries

Why "skill" belongs next to "npm package" in your threat model

The npm/PyPI analogy is exact, not decorative. A package registry ships code that runs with your user's permissions; a skill registry ships instructions that your agent executes with your permissions. Snyk's researchers put it plainly after the first ecosystem-wide audit: "Agent Skills are a software supply chain, and they require the same security rigor we apply to npm, PyPI, and container registries." The payload classes even rhyme — typosquatting, dependency confusion, and install-time code execution all crossed over — plus one class npm does not have: hostile instructions written in plain English inside the file everyone actually reads.

What makes the skill supply chain harder than the package one: the attack surface is natural language plus any scripting language at once. A skill is a Markdown file that may bundle Python, JavaScript, shell scripts, or any combination — scanners must cover every ecosystem simultaneously, and the same instruction can be benign on your machine and malicious on a CI runner. Socket's engineering write-up on their skills.sh integration names this directly: skills are "defined in natural language markdown files that can invoke code in any language," so they run static analysis and LLM behavioral detection together.

And the distribution graph is wider than a package registry: skills arrive from public marketplaces (skills.sh, ClawHub), curated org repos (anthics/skills, trailofbits/skills-curated), project directories cloned from arbitrary repos (.claude/skills/, .agents/skills/), and ZIP uploads to claude.ai and Codex. Every one of those paths injects text into agent context. CSA's May 2026 research note calls the file at the center of it — SKILL.md — the new AI supply-chain attack surface.

The 2026 attack ledger

Every row below is a published, verifiable audit or incident from 2026.

Audit / incident	When	What it established
Snyk ToxicSkills	Feb 2026	First ecosystem-wide audit: 3,984 skills from ClawHub + skills.sh. 13.4% (534) had at least one CRITICAL issue; 36.82% (1,467) had any security flaw; 76 confirmed malicious payloads (credential theft, backdoors, data exfiltration); 8 malicious skills remained live on ClawHub at publication. 91% of confirmed malware combined prompt injection with executable shell payloads — a convergence that slips past both AI safety filters and traditional scanners.
ClawHavoc (Koi Security)	Jan–Feb 2026	Coordinated campaign: 341 malicious skills found in ClawHub's 2,857 then-listed entries, 335 from a single operation — typosquatted names, cross-file logic splitting, credential exfiltration to attacker webhooks. Antiy CERT later attributed 1,184 malicious skills to the campaign family.
Air Security runtime scan	Jun 2026	Scanned 142,836 live skills: 17,822 (~12.4%, carrying 6.7M installs) rested on at least one untrusted external resource — an unpinned dependency that can turn malicious without the skill's own files changing.
Trail of Bits scanner bypass	Jun 2026	Built four overtly malicious skills that passed ClawHub's detector, Cisco's scanner, and all three skills.sh-integrated scanners (Gen, Socket, Snyk). Techniques: payload hidden in a .docx (ZIP/XML) archive, .pyc bytecode scanners never open, and scanner-source-guided prompt injection. Three of four took under an hour. Published as trailofbits/overtly-malicious-skills.
CSA: SKILL.md context poisoning	May 2026	Documented invisible-instruction attacks using Unicode Tag characters (U+E0000–U+E007F) — rendered as whitespace to humans, parsed as content by models. Claude Code added detection in the Feb 10 2026 release. The same note catalogs the context-file CVEs: CVE-2025-59536 (malicious repo hooks, CVSS 8.7) and CVE-2026-21852 (silent API-key harvesting via project config), both patched in Claude Code.
Claude Code context-file CVEs	Oct 2025–Jan 2026	CVE-2025-59536: a repo-controlled .claude/settings.json hook executed attacker shell commands on project open, pre-verification (fixed v1.0.111). CVE-2026-21852: a modified project config routed API traffic through an attacker server, harvesting keys without interaction (fixed v2.0.65). Proof that the attack surface extends beyond marketplaces into any cloned repository.

How a skill becomes a supply-chain attack

1. Publish

Anyone can publish from any public GitHub repo. skills.sh indexes 60,000+ skills with no account system; ClawHub accepts open uploads. Registration is not review — the listing exists the moment the repo does.

2. The scan gap

Skills.sh audits fire only after a skill's first install, and partner scanners are static: they see the files shipped today, not the repo next week. Trail of Bits proved all five production scanners can be passed with standard tricks; Snyk's own data shows the curated top-100 still carries 9% third-party-content exposure and 5% credential-handling findings.

3. Install

One command — npx skills add owner/repo — places files into .agents/skills/ (symlinked into .claude/skills/). No lockfile entry, no diff anyone reviews, no build output. The install looks like bookmarking and behaves like dependency admission.

4. Execution

When a task matches the trigger description, the agent reads SKILL.md as high-trust configuration — not as untrusted web content. Whatever the session can do (read files, run shell, make network requests), the skill's instructions can direct. The documented payload families: credential exfiltration instructions, second-stage fetch-and-execute scripts, data-routing to attacker endpoints, and persistence that rewrites other context files.

Attack family	Mechanism
SKILL.md prompt injection	Hostile directives buried in the instruction body — e.g. a line telling the agent to append environment variables as query parameters on every external request. Invisible to anyone who skims; loads whenever the description matches.
Bundled-script payloads	SKILL.md is the part people read; the scripts are the part that runs. curl\|bash installers, second-stage fetches, and executables needing elevated privileges ride along as "setup."
Typosquatting	Skill names mimicking popular ones ("polymarket"-style clones were the ClawHavoc signature; Snyk confirmed the same pattern in confirmed-malicious samples).
Dependency confusion	A nested requirements.txt or package.json pulls a typosquatted package carrying the real payload — the classic open-source vector, reborn inside a skill folder.
Unicode Tag invisibles	Instructions encoded in U+E0000–U+E007F render as whitespace in every editor but parse as directives for the model. Claude Code refuses them since Feb 10, 2026; older agents and other tools may not.
Cross-file logic splitting	Payload split across files (or across the .docx-as-ZIP trick) so no single file looks malicious — the packaging attack that passed skills.sh "with flying colors" in the Trail of Bits test.
Runtime dependency rot	12.4% of live skills sit on unpinned external resources — the skill you audited in March can serve different instructions in June without its repo changing.

What the scanners actually cover — and what they miss

Skills.sh ships a security-audit layer: five partner scanners (Gen Agent Trust Hub, Socket, Snyk, Runlayer, ZeroLeaks) produce per-skill verdicts — pass / warn / fail with risk levels NONE through CRITICAL — exposed both on the skill's security page and programmatically at GET /api/v1/skills/audit/{source}/{skill}. Three things the API docs make explicit that most coverage skips: (1) audits are generated automatically after a skill is installed for the first time — the endpoint 404s until then; (2) verdicts are normalized summaries, not raw reports; (3) there is a documented install-detection use — teams can poll the API to detect whether a skill they pinned is already installed elsewhere. Socket's engine posts the strongest published numbers: tested against 382 known-malicious and 355 benign skills, 94.5% precision, 98.7% recall, 96.7% F1 — and continuous rescans catch skills that turn malicious after listing.

Layer	Catches	Documented miss
skills.sh partner audits (5 scanners)	Obvious prompt injection, malicious code patterns, suspicious downloads, hardcoded secrets	All three skills.sh-integrated scanners passed the Trail of Bits docx-archive payload, .pyc bytecode payload, and a source-guided injection — in under an hour of attack effort
Socket continuous scanning	Multi-language static analysis + LLM behavior detection; rescans on update; blocks malicious skills from future installs	Socket was one of the engines bypassed in the same disclosure; 94.5% precision means ~1 in 18 flags is noise and 98.7% recall means ~1 in 80 malicious skills passes
Install-count leaderboards	None — popularity is not review. skills.sh's own docs caveat that it "cannot guarantee the quality or security of every listed skill"	Snyk's curated top-100 scan still found 9% with third-party-content exposure and 5% with credential-handling issues
Curated / first-party repos	Maintainer review, Git history, org accountability — the strongest published signal (anthics/skills, trailofbits/skills-curated)	Coverage is tiny by design; a curated set trades breadth for trust and goes stale slower but goes stale
You, reading the files	Everything above — the only layer that sees intent in context	Does not scale to hundreds of skills, which is exactly why layering matters (below)

Trail of Bits' conclusion is the honest one: "No amount of scanning or LLM analysis can reliably detect malicious content in agent skills." Scanners raise the cost of attacks; they do not close the supply chain. Their own guidance — curate sources, pin versions, control who can add or update dependencies, keep the attack surface small — is the same playbook npm security matured over a decade. The difference is the ecosystem has had one year.

The 7-layer install checklist

Layers 1–3 are the ten-minute human pass; 4–7 are the automation and policy layers most teams skip.

Layer 1 — Read SKILL.md end to end

Every line, including HTML comments. Every instruction must serve the stated purpose; a code-style skill has no business mentioning credentials, network calls, or other files' contents. Then check for invisible content: paste the file through a Unicode audit or search for characters in the U+E0000–U+E007F range.

Layer 2 — Read every bundled file

List the full tree. SKILL.md is the part people read; scripts are the part that runs. Read any bundled script before running anything, and treat archives (.docx, .zip) as opaque containers that need opening — the exact gap the Trail of Bits docx attack lived in.

Layer 3 — Scope the capabilities

Check allowed-tools / permission requests: a reading skill asking for Bash, Edit, and Write is doing more than reading. Check the trigger description for prompts you don't intend to fire it on. Source reputation: first-party org > established author > random repo.

Layer 4 — Run the scanners, then discount them

Pull the audit endpoint (/api/v1/skills/audit/{source}/{skill}) and read the per-partner verdicts; a warn from any partner is a stop. Then remember the demonstrated bypasses: a fail-safe verdict is evidence, not clearance.

Layer 5 — Sandbox the first install

Install project-level in a throwaway container or VM, never user-level on your daily driver. Run one trivial task, watch what the session touches (shell history, network requests, file writes), and only then promote it.

Layer 6 — Pin source and version

Skills are Git-versioned text — pin the commit, and read the diff of every update before accepting it (that's the pull-review discipline from package management). Unpinned external resources inside a skill are the 12.4% problem: audit on install is not enough if the skill fetches at runtime.

Layer 7 — Make it policy, not memory

CSA's guidance for teams extends software supply-chain controls to context files explicitly: restrict which registries skills may come from, require hash verification before production loads, and run skill additions through the same approval process as new dependencies. Audit which context files already exist in your repos (CLAUDE.md, SKILL.md, AGENTS.md, .claude/settings.json) and patch agents to current versions — the two CVEs above were both fixed by version upgrades, not by reading skills harder.

The economic layer: why paid, vetted marketplaces change the math

Registry malware is partly an incentive problem: on free, anonymous registries the only payoff for a malicious skill is stealing from the people who install it. A marketplace where verified creators earn real revenue gives the same skills a legitimate path to monetize — which is the design bet behind the VibeFuse marketplace: creators sell widgets, skills, and styling packs at an 80% revenue share with creator-set pricing, buyers preview a widget running before they pay, and identity plus payment rails (Stripe Connect) make "author" a traceable thing instead of a throwaway account. Trail of Bits' prescription — use curated marketplaces for sensitive contexts — is the same shape: accountability over anonymity.

The audit discipline is unchanged either way: the same SKILL.md standard loads in VibeFuse, so read before you run. What changes is where honest work pays better than theft — inside the first ever free widget-based AI harness, with local/offline processing, working in any app.

AI Skill Supply Chain FAQ

What is the AI skill supply chain?

The pipeline a SKILL.md file travels from a public GitHub repo through a registry (skills.sh, ClawHub, curated org repos, or a cloned project's .claude/skills/ folder) into your agent's context window, where its instructions execute with your terminal's permissions. Snyk's researchers state it directly: agent skills are a software supply chain requiring the same rigor as npm, PyPI, and container registries. The difference: the payload can be natural language plus any scripting language at once, and the 'install' step looks like bookmarking while behaving like dependency admission.

How many AI agent skills are malicious?

The 2026 audits give a range by corpus and method. Snyk's ToxicSkills scan of 3,984 skills (ClawHub + skills.sh top listings, February 2026): 13.4% had at least one CRITICAL issue, 36.82% had any security flaw, and 76 confirmed malicious payloads were verified by human review - 91% of them combining prompt injection with executable shell code. Koi Security's ClawHavoc audit found 341 malicious skills in ClawHub's 2,857 then-listed entries, with Antiy CERT later attributing 1,184 to the campaign family. Air Security's June 2026 scan of 142,836 live skills found 12.4% (17,822 skills, 6.7M installs) resting on at least one untrusted external resource.

Can skill scanners be bypassed?

Yes - demonstrated, not theoretical. Trail of Bits (June 2026) built four overtly malicious skills that passed ClawHub's malicious-skill detector, Cisco's agent skill scanner, and all three skills.sh-integrated scanners (Gen, Socket, Snyk). Three of the four took under an hour: a payload hidden in a .docx archive (a ZIP of XML), .pyc bytecode the static analyzers never opened, and a prompt injection tuned against the scanner's own source. Their conclusion: static scanners raise attack cost but cannot reliably detect malicious content in agent skills, because the attack surface is natural language plus arbitrary code.

Does skills.sh have a security API?

Yes. skills.sh exposes per-skill security audits at GET /api/v1/skills/audit/{source}/{skill} - an array of partner audits (Gen Agent Trust Hub, Socket, Snyk, Runlayer, ZeroLeaks), each with a normalized verdict (pass / warn / fail), a risk level NONE through CRITICAL, a one-line summary, and an auditedAt timestamp. The endpoint returns 404 until a partner has audited the skill, and audits are generated automatically after a skill's first install. The catalog, leaderboard (all-time / trending / hot views), and semantic search are also API-exposed under /api/v1/. Authentication is via Vercel OIDC tokens.

How do I audit an AI skill before installing it?

Seven layers. (1) Read SKILL.md end to end, checking for Unicode Tag characters (U+E0000-U+E007F) that render as whitespace but parse as instructions. (2) Read every bundled file - scripts are the part that runs; open archives like .docx/.zip. (3) Scope capabilities: allowed-tools wider than the skill's purpose is a stop. (4) Pull the security-audit API endpoint and discount any pass - the bypass research showed scanners miss docx payloads, bytecode, and tuned injections. (5) First-install in a throwaway container, never user-level on your daily driver. (6) Pin the source commit and read the diff on every update - 12.4% of live skills sit on unpinned external resources that can change without the skill changing. (7) Make it team policy: registry allowlists, hash verification, dependency-style approval for new skills.

What is the SKILL.md prompt injection attack?

A skill is prompt content carrying full trust: the agent treats installed instructions as configuration from you, not as untrusted input like a web page. Injection hides hostile directives inside an otherwise legitimate skill body - a buried line telling the agent to read the project .env and embed its contents in a code comment, weaken a security setting, or route output to an attacker endpoint. Snyk confirmed 36% of ClawHub skills carry detectable prompt injection, and 91% of confirmed malware pairs it with executable payloads. CSA's research note frames SKILL.md itself as the new AI supply-chain attack surface.

Are skills more dangerous than npm packages?

Different surface, similar stakes. npm ships code that runs; a skill ships instructions your agent executes with your permissions, so the blast radius is your files, shell, and network - the same as a bad dependency. Skills add attack classes npm lacks: plain-English injection in the file everyone reads, invisible Unicode instructions, and cross-file logic splitting. npm has a decade of mature tooling (lockfiles, provenance, SBOMs); the skill ecosystem has had one year, and the Trail of Bits bypass research suggests it shows. Treat public skill registries as untrusted code and lean on curated sources for sensitive contexts.

How does VibeFuse reduce skill supply-chain risk?

Two mechanisms. First, architecture: VibeFuse runs the portable SKILL.md standard locally on your Windows machine - local/offline processing, code never uploads, works in any app - so exfiltration paths shrink to what your own session permits. Second, economics: the open-source marketplace lets verified creators sell widgets, skills, and styling packs at an 80% revenue share via Stripe Connect with creator-set pricing and live previews before purchase. Registry malware is partly an incentive problem - anonymous free registries reward theft; a marketplace where honest work pays better, with traceable authorship, changes the math. The read-before-you-run discipline still applies to every skill.

Build where creators get paid and code stays local

Download VibeFuse free, register for a free license key, and run the real agent CLIs as canvas widgets on your own Windows machine — then publish widgets, skills, and styling packs to the open marketplace at an 80% revenue share.

Download VibeFuse free Browse the marketplace