Agent skills are a supply chain risk. Scan them like it matters.

Agent skills are the new npm packages — except a package's install script is code you can statically analyze, and a SKILL.md is a natural-language program your agent reads and obeys. That difference changes everything about how you should treat them.

The Agent Skills standard went open in December and 70+ platforms now load the same folder format. Marketplaces popped up within weeks. Meanwhile a security-audit skill from a major CDN vendor sat at the top of GitHub trending — the ecosystem is clearly hungry for "skills". What almost nobody is talking about: installing a third-party skill is a supply-chain decision.

What a skill can actually ask for

Strip away the branding and a skill grants its author three channels into your session:

1. Instructions the model treats as authoritative. The description alone steers when the skill activates. Prompt-injection isn't a hypothetical here — it's the native instruction format.
2. Tool permissions. allowed-tools lines decide whether the skill may read files, run shell commands, or hit the network during its "workflow steps".
3. Bundled scripts. Many skills ship helper scripts the agent is told to execute at step N. That's arbitrary code execution with your working directory as the blast radius.

None of this is a flaw in the standard — it's the feature. But it means "try this cool skill I found" is closer to curl | bash than to installing a browser extension.

The pre-install checklist I run now

I run real security-audit pipelines with agent skills daily, and this is the discipline that survived contact with reality:

1. Scan before install. Cisco's open-source skill-scanner catches the low-effort malicious stuff — credential reads, destructive deletes, known injection patterns. No findings ≠ safe, but it clears the floor.

2. Read the SKILL.md like an attacker. Where does it ask the agent to send data? Which URLs? What "verification steps" involve executing bundled binaries? A five-minute read beats a post-incident forensics month.

3. Check allowed-tools against the actual need. A transcription skill does not need shell access. A report formatter does not need network. Scope mismatch is the loudest signal.

4. Keep a provenance manifest. Every install recorded: version, source repo, license, how you verified it. When the next supply-chain incident drops, "was I exposed?" becomes a one-line lookup instead of archaeology.

5. Refuse with reasons, in writing. My manifest records plugins I refused — safety-policy bypasses, third-party account pools. The refusal reasons are knowledge too; they stop you re-litigating the same decision in three months.

The same lens, pointed at your own code

That discipline scales up. Once you treat "what can this input reach?" as the core question, code review becomes a taint walk: entry points → sources → sinks, with an explicit verdict on every sanitizer in between. I packed that method into a skill as well — a taint-analysis code-audit skill with a 0–10 severity rubric and a hard output contract: every finding ships with file:line, the taint path, and the minimal request that proves it. No walkable path means it goes in the hardening appendix, never inflated to a "vulnerability".

It's live as a free tool edition on Swarms Marketplace, and the governance tooling I use to keep my own installs honest is open source: dsh-plugin-hub (routing table, health checks, the provenance manifest itself).

The uncomfortable summary

We spent a decade teaching developers not to curl | bash. Then we built a format whose entire value proposition is "the model will follow these instructions" — and started collecting them from strangers. Skills are worth it. Install them like it matters.

What's your pre-install routine for third-party skills — or are we all still at curl | bash stage? Comments very welcome.