I almost scrolled past it. This morning's arxiv drop was the usual parade of SWE-bench point-chasing and yet-another-orchestrator papers — and then Skills Are Not Islands stopped me cold. It's the first paper I've seen that treats agent skills — the SKILL.md bundles I install without a second thought — as a software supply chain: transitive dependencies, missing provenance, inherited malware, the works. The thesis I walked away with: the real risk in your skills library isn't the skill you read, it's the three you can't see that it quietly pulls in.
What it does#
Skills Are Not Islands, from Changguo Jia, Tianqi Zhao, Runzhi He, and Minghui Zhou at Peking University's Institute of Software, introduces a formalism the authors call Agent Skill Supply Chains (ASSCs). The premise is that a skill is never self-contained: it depends on other skills, on language packages (npm, PyPI), and on external services (MCP servers, APIs, webhooks). Those three channels form a mixed dependency graph — and, exactly like an npm package with a lockfile, the interesting risk lives in the transitive closure, not the top-level manifest.
To measure it, they build SkillDepAnalyzer, which extracts these dependencies straight from the natural-language skill document, since skills almost never declare dependencies formally. They validate it against SKILL-DEP, a hand-annotated benchmark of 500 skills with 1,586 adjudicated dependency records plus a 100-skill multi-layer set with graphs up to depth five, then run the analyzer across 1,434,046 GitHub-backed skills — 87.4% of a public registry. That's what lifts this above a think-piece: it's a Software Bill of Materials applied at population scale to a corpus almost nobody has looked at this way.
The key result#
The number that made me sit up: 13.40% of skills inherit publicly reported malicious signals purely through transitive dependencies. The skill you audited is clean; its grandchild is the problem. And it compounds across every channel — 98.01% of exposures to a flagged axios version reach skills only transitively, 93.10% of vulnerable-MCP-service exposure is transitive-only, and 60–78% of roots carrying remote-execution-style patterns inherit them from something downstream rather than declaring them directly. Provenance, meanwhile, is a wasteland: a license appears in just 11.25% of skills, a version in 20.12%, and 58.73% share an effective name with at least one other skill — so even naming a dependency unambiguously is often impossible.
Why it matters#
If you build with Claude Code — or any skill-loading agent — you've probably been reasoning about skills the way we once reasoned about copy-pasted Stack Overflow snippets: read it, looks fine, ship it. This paper says that model is already broken. The scariest channel is skill-to-service (22.25% of skills reference one), because an MCP server or webhook is an active runtime capability, not passive text — a skill three hops up your graph can hand a sub-agent a tool you never authorized. The concentration numbers sharpen it: package dependencies show a Gini of 0.944, higher than npm's 0.87, and 30.41% of dependency-bearing skills sit in graphs with cycles (the authors flag a Bitcoin PSBT cluster of 140 mutually-referencing skills). Compromise one popular node and you're not popping one repo — you're popping a cluster.
So what does a builder actually do differently? Stop treating a skill as a document and start treating it as a package that needs a lockfile. Resolve the transitive closure before install, pin versions and services, and refuse skills with no provenance the way you'd refuse an unsigned binary. The stat that reframed my own hygiene: 71.87% of npm packages and 73.33% of PyPI packages enter a skill graph through reuse rather than direct declaration — meaning the package.json scanning I already run is blind to most of what my agent will actually execute. For sub-agent architectures it's a hard design constraint: if you fan out to specialists that each load their own skills, your effective attack surface is the union of every transitive skill graph, and right now essentially nobody computes that union. The authors' prescriptions — typed dependency manifests, first-class cluster management, lockfile-style records, and audit commands for registry maintainers — are exactly the boring supply-chain infrastructure that npm and PyPI took a decade to grow, and skills have none of it yet.
The caveats#
Exposure ≠ compromise. The 13.40% figure inherits "malicious" and "vulnerable" labels from public advisories and heuristics; it measures reachability to a flagged artifact, not a confirmed exploit in a live agent.
One registry, one snapshot. It's a single public registry at a single point in time; enterprise and private skill libraries may have very different hygiene.
Fuzzy ground truth. Extracting dependencies from prose is inherently noisy — SkillDepAnalyzer's 0.95 F1 is strong (vs 0.52 for a DeepSeek baseline and 0.24 for the best conventional SBOM tool), but the ground truth is human-adjudicated on a ~600-skill sample.
Tail drama. The eye-catching 1,754× package amplification is a p99 tail statistic; the median amplification is a modest 0.5×.
The takeaway#
What I'm filing away: the unit of trust for agentic tooling has quietly moved from the prompt I wrote to the dependency graph I imported, and I've been auditing the wrong layer. Starting now I'm treating my skills directory like a node_modules — enumerate the transitive closure, kill anything with no version or license, and never install a skill that reaches an external service I can't name. Reading one SKILL.md and calling it safe is officially over.