Why the agent skill supply chain breaks (and how KillerSkills fixes it)
Blog · October 27, 2026 · KillerSkills
Platform and AppSec teams know npm, PyPI, and container registries. Those ecosystems have imperfect but mature controls: SBOMs, lockfiles, signatures, and scanners that reason about declared dependencies.
Agent skills and MCP servers are a different supply chain. They do not only add libraries to a build. They add instructions and tools into the agent's runtime — often with install hooks, filesystem access, and network egress — and they can change behavior after you thought you had approved them.
This post briefs engineers evaluating Cursor, Claude Code, or MCP governance: what skills/MCP are, how they fail differently from classic packages, why allowlists and static scans alone fall short, and how KillerSkills approaches the problem.
1. Skills and MCP servers are a new supply chain
An agent skill is a packaged set of instructions and optional code an agent loads to do a job. In Claude Code and similar systems, that often means a SKILL.md (or related instruction files), setup scripts, and hooks that run at install or session start. The agent treats those instructions as part of how it should work — not as inert documentation.
An MCP server (Model Context Protocol) exposes tools, resources, and prompts over a protocol handshake (initialize, tools/list, and so on). The tool surface — names, descriptions, and input schemas — becomes part of what the model sees and can call. A poisoned tool description is not a README comment; it is guidance the agent may follow.
Together they form a supply chain because:
- They ship through public registries and marketplaces (skills.sh, ClawHub, Claude Code plugin marketplaces, npm, PyPI, the Docker MCP Catalog, the official MCP Registry, and similar).
- Install is a privileged moment: dependencies may be fetched, scripts may run, and config may land on the machine before anyone uses the skill for a real task.
- Once loaded, skills and MCP tools sit inside the agent's trust boundary — next to credentials, repos, and memory/instruction files (
MEMORY.md,CLAUDE.md,AGENTS.md, and peers).
Classic package managers still matter (many skills ship as npm or PyPI artifacts). The new risk is not only "what code runs in my CI," but "what instructions and tools does my coding agent now obey."
2. How this fails differently from npm / PyPI
Dependency scanners find known vulnerable libraries, typosquats, and some malicious install scripts. Agent skills fail in ways those tools were not designed to catch.
Prompt injection and tool poisoning. Text in SKILL.md, comments, or MCP tool descriptions can address the agent itself: override prior policy, act silently, or prefer one tool over another. Tool names that shadow another server, or descriptions that instruct the agent rather than document a function, change behavior without looking like a CVE in a lockfile.
Credential-path reads. A skill that "helps with deploys" may open ~/.ssh/id_ed25519, ~/.aws/credentials, ~/.npmrc, ~/.config/gh/hosts.yml, or a project .env. In a normal Node package that is suspicious. In an agent skill it can be framed as "setup," and the agent may be the one that follows the instruction.
Undeclared egress. Skills and MCP servers can phone home. The dangerous case is not traffic to npm during install — registries are expected — but hosts the skill never declared, especially when secrets ride in headers or bodies.
MEMORY.md / instruction tampering. Writes to agent memory or instruction files persist across sessions. A one-time install can leave directives that reload on every future run — closer to persistence than to a one-shot postinstall script.
Drift after install. The version you reviewed is not guaranteed to be what runs next month. Publishers ship new releases; hosted MCP endpoints can change tool names, descriptions, and schemas without a local package bump. Approval of "v1.2.0 last Tuesday" does not cover what the agent loads today.
These failure modes are behavioral and instructional, not only "known bad hash in the advisory DB."
3. Why allowlists alone and static scans are insufficient
Allowlists answer "who is allowed," not "what does this release do." A trusted publisher can ship a bad version. A previously clean skill can grow a new install script or MCP tool description. Allowlists also rarely encode rules like "block credential-path reads plus undeclared egress."
Static scans catch a lot — credential-path patterns, shell interpolation, unpinned deps, obvious override language in instruction files. KillerSkills runs static rules (AST01–AST07, grouped under the OWASP Agent Skills Top 10) on every bundle before anything executes. Static analysis is necessary.
It is not sufficient, because:
- Behavior vs declarations. A skill can declare a narrow purpose and still open SSH keys or POST to an undeclared host when it runs. Declarations are claims; execution is evidence.
- Post-install version drift. A scan of last week's pinned artifact does not see a new release, a mutated remote MCP tool surface, or runtime deviation in a real agent session.
- Pattern-only Blocked decisions are brittle. Benign docs and install instructions can look like malicious ones under regex. A trustworthy pipeline treats static-only results carefully — for example, capping them so text matches alone do not produce the strongest label without a critical finding or a behavior trace.
You need both: static analysis for cheap, explainable findings, and observed behavior for cases that only show up when the skill runs.
4. How KillerSkills approaches it
KillerSkills is a trust layer for agent skills and MCP servers: check at install time, detonate in a honeypot, score against policy, and watch for drift. Free for developers; companies pay for org-wide policy, inventory, approvals, and audit. See killerskills.ai, /docs, /scenarios, and /pricing.
Install-time vet-skills hook
A small CLI hook sits in the agent. On install it resolves the skill or MCP server, checks the current verdict against policy, and can warn, allow, or refuse before the package runs. vet-skills.lock pins the exact bytes that were vetted so later installs can detect substitution.
Honeypot detonation
Every public release runs in an isolated sandbox with a decoy home (tagged SSH keys, cloud and registry credentials, .env — nothing real), a watched MEMORY.md / instruction-file surface, a recording egress proxy, and syscall trace. Scenarios cover install, MCP handshake, task use, and adversarial cases where a skill inserts itself while the agent does something sensitive.
If a decoy secret appears on the wire, the run is attributable and the score collapses. The output is a behavior trace, not a reputation guess. The scenario catalog is public so a verdict can be argued with and reproduced via vet-skills detonate.
Signed DSSE verdicts, lock, and verify
Each verdict is a signed attestation (DSSE, Ed25519) over the bundle's sha256, verifiable offline against /.well-known/killerskills-keys.json. vet-skills verify checks it; CI can refuse anything whose bytes changed since review. Labels are Verified, Caution, or Blocked, with a 0–100 score.
Public homepage figures (verified for this draft): 7,092 skills/MCP servers across 7 registries; 38% of scored skills carry a finding a policy must decide on; 4,807 detonations in the last 24 hours; 2.1 h median publish-to-verdict time (30-day).
Org policy: observe → enforce, plus drift
Teams get versioned YAML policy (minimum score, actions on Caution/unscored, per-behaviour rules, publisher allow/block lists), inventory of what every enrolled agent installed, an approvals queue, and an audit log. Enforcement starts in observe (log only) and switches to enforce when ready. Drift alerts fire when a verdict moves, when a release diffs against the previous one, or when a watched MCP tool surface changes. The hook can also compare real-session behavior to what the sandbox saw.
Verified Publisher ($2,400/year per org) is the publisher-side companion: claim skills, get the badge Team policies can trust by default, see verdicts before they publish, and get drift alerts on your own releases.
5. Practical free-tier starting steps
You can start without a commercial agreement. The Developer plan is $0 forever.
- Install the CLI❯ npm i -g vet-skills
- Hook it into Claude Code (and use the install path your agent already supports). The hook checks before a skill or MCP server runs; personal policy can live in a local file while you learn the labels.
- Add the GitHub Action so PRs that introduce a Blocked skill fail in CI. CI runners enrolled with
vet-skills join --cido not consume Team seats later — the Action stays free at every tier. - Read a few verdict pages for skills your org already uses. Look at the behavior trace, static findings (AST rules), declarations vs observed hosts, and whether the engine version matches /scenarios.
- Move to Team when you need governance, not when you need the CLI. Team is $24 per developer / month, billed annually, 25-seat minimum (first design partners: 50% off year one for a logo and a monthly call). That unlocks org policy, inventory, approvals, drift alerts, SSO, and a signed audit log. Enterprise starts from $60k / year (private registries, air-gapped verdict cache, SIEM, custom scenarios, compliance support). Docs describe a 14-day Team trial with no card required.
Free is for anyone who installs skills. Paid starts when a policy must apply to other people's agents, or when you need an inventory of them.
6. Honest competitive framing
Socket and Snyk Agent Scan (and related AppSec / supply-chain products) address adjacent problems: dependency risk, malware in packages, and broader agent or code-security scanning. Those are real problems, and many teams should keep using them for npm/PyPI/container posture.
KillerSkills is narrower on purpose:
- Skill and MCP behavior before install — honeypot detonation with decoys and a recording proxy, not only static or advisory matching.
- Install-time policy in the agent hook, with lock/verify and signed DSSE verdicts you can check offline.
- Ongoing drift — re-detonation, release diffs, MCP tool-surface snapshots, and alerts when what you run no longer matches what you approved.
If your question is "is this npm package a known malicious dependency?", classic SCA tools are the right first stop. If your question is "what does this agent skill or MCP server do when installed, and has that changed since we allowed it?", that is the KillerSkills lane.
Bottom line
Agent skills and MCP servers put third-party instructions and tools inside the agent's trust boundary. That supply chain breaks through prompt/tool poisoning, credential reads, undeclared egress, instruction-file persistence, and post-install drift — failure modes allowlists and static-only scans only partially cover.
KillerSkills responds with install-time checks, public honeypot methodology, signed verdicts, and org policy that can move from observe to enforce. Start with npm i -g vet-skills, wire the Claude Code hook and the GitHub Action, and graduate to Team when inventory and shared policy become the bottleneck.
Product, docs, scenarios, and pricing: killerskills.ai · /docs · /scenarios · /pricing.