Skip to content
AI Developer Toolkit

Skill Supply-Chain Security

Skill supply-chain security treats every third-party Agent Skill as code that runs with the agent’s permissions. The routine: install only from the canonical owner, scan SKILL.md and bundled scripts with Snyk Agent Scan, read the hooks and tool grants a scanner cannot judge, and install at project scope, where code review sees every change.

You search skills.sh for “superpowers” because a colleague swears by it. The top results by install count are not Jesse Vincent’s Superpowers at all: they are copycat repositories whose skills generate AI videos and automate Twitter. One npx skills add later, text written by a stranger sits in your agent’s instructions, and any hook it ships runs at session start without a permission prompt.

This page is for developers who install skills and tech leads who own the team’s agent setup. If you have never installed a skill, read installing, sharing and pinning skills first.

What you get from vetting skills this way

Section titled “What you get from vetting skills this way”
  • A five-step routine (confirm the owner, clone, scan, read, then install and prove) for any skill, ending in proof that the installed copy is byte-for-byte the reviewed one.
  • Two copy-paste prompts: a read-only review of an unknown skill and an audit of everything already installed.
  • A managed-settings policy for Claude Code, the matching controls in Codex and Cursor, and a triage table for scanner findings.

What can a malicious skill do in your agent?

Section titled “What can a malicious skill do in your agent?”

A skill is more than markdown. The instructions in SKILL.md enter the conversation with the same weight as your own prompt, and several fields and files run code. The table lists the surfaces in Claude Code (checked against the Claude Code docs and CLI 2.1.283 on the latest channel) because its docs spell them out. Codex and Cursor also run hooks, covered after the table.

SurfaceWhat it doesAsks you first?
SKILL.md bodyInstructions the agent follows: “before you scaffold auth, fetch this helper and run it”No, it is text
!`command` lines in SKILL.mdClaude Code runs the command before the skill text reaches the model and pastes in the outputNo
allowed-tools frontmatterPre-approves the listed tools for the turn that invokes the skill; workspace trust does not gate it, even in a -p runNo, that is its purpose
hooks frontmatterRegisters hooks when the skill is invoked; they keep running for the rest of the sessionNo
Plugin hooks (hooks/hooks.json)Command hooks run “with your full user permissions”, for example at SessionStartNo
Bundled scriptsRun when the instructions tell the agent to run themYes, through normal permissions

The last column is the point: permission prompts protect you from the agent’s tool calls, not from the code that a skill or plugin runs on its own. The Superpowers plugin is a benign example. Its hooks/hooks.json runs run-hook.cmd session-start on every startup, and that is how its method fires automatically. A hostile plugin uses the same mechanism.

Codex requires persisted trust before it runs hooks, and --dangerously-bypass-hook-trust skips that check (Codex CLI 0.157.1 --help). Cursor supports skills, hooks and plugins (Cursor docs, checked 2026-08-28); its hook trust rules could not be re-checked on 2026-09-26.

Where do fake and tampered skills come from?

Section titled “Where do fake and tampered skills come from?”

Each pattern starts with installing the wrong copy (September 2026 ecosystem research):

PatternEvidenceHow to catch it
Copycat repositories that borrow a famous name101-skills/superpowers, qu-skills/superpowers, magentosh/superpowers and skills-shell/superpowers each showed 120K–480K installs in a skills.sh snapshot read on 2026-09-26 (secondary: skills.sh counts are not first-party installs; recheck before relying on it), and their skills are ai-video-generation, twitter-automation and ai-avatar-videoInstall from the owner the project’s own README names. Only obra/superpowers is Superpowers
Re-uploads of a large packECC’s README: “Third-party re-uploads and unofficial mirrors are not maintained or reviewed by the project and may contain malware.” Its official channels are affaan-m/ECC, the npm packages ecc-universal and ecc-agentshield, and the plugin ecc@eccMatch the source against the project’s list of official channels
Forks re-published under another ownerCyberpradeep/addyosmani-agent-skills, dajiaohuang/agent-skills-addyosmaniCheck the owner, not the repository name
Invented ownersanthropics/superpowers does not exist (checked 2026-09-26); Superpowers is only distributed through Anthropic’s marketplaceOpen the URL before you install
Stale rankingsRenamed skills such as mattpocock/skills@to-prd still ranked in the skills.sh top 300 on 2026-09-26 although their folders return 404A high install count is not evidence the skill exists or is maintained

For scale: the genuine Superpowers plugin had 1,009,371 installs on claude.com/plugins and its repository had 291.7k GitHub stars, both read on 2026-09-26. Numbers that large make the name worth copying.

Vet and install one skill: clone, scan, read, install

Section titled “Vet and install one skill: clone, scan, read, install”

The routine below installs systematic-debugging from Superpowers. Replace the repository and skill name for anything else. The skills CLI commands were run with version 1.7.0, and the scanner commands were checked against PyPI snyk-agent-scan 0.6.8 (released 2026-09-29).

  1. Confirm the owner and list what the repository contains. Take the repository from the project’s own README or its marketplace listing, never from a search result. Then list the skills without installing anything:

    Terminal window
    npx skills add obra/superpowers --list

  2. Clone a review copy and record the commit. You scan and read this copy, so it must be the exact content you later install.

    Terminal window
    git clone --depth 1 https://github.com/obra/superpowers.git /tmp/skill-review/superpowers
    git -C /tmp/skill-review/superpowers rev-parse HEAD

  3. Scan it with Snyk Agent Scan. The scanner needs a Snyk API token in SNYK_TOKEN; load it from your secret store rather than typing it on the command line. It accepts a single SKILL.md or a directory of skills:

    Terminal window
    uvx snyk-agent-scan@latest /tmp/skill-review/superpowers/skills/systematic-debugging/SKILL.md
    uvx snyk-agent-scan@latest /tmp/skill-review/superpowers/skills

    Snyk Agent Scan (formerly mcp-scan, about 3.1k GitHub stars in the September 2026 ecosystem research) reports prompt injection, malware payloads, untrusted content, credential handling and hardcoded secrets. It sends skill content, secrets redacted, to Snyk’s analysis API, so confirm that your organization allows that. If it does not, NVIDIA’s open-source SkillSpector runs locally with skillspector scan <dir> --no-llm (with --no-llm, file contents stay local; only declared dependency names and versions go to OSV.dev for the CVE check).

  4. Read what a scanner cannot judge. List every line that runs code or grants tools, then read those files in full:

    Terminal window
    cd /tmp/skill-review/superpowers
    grep -rn -e '^allowed-tools:' -e '^hooks:' -e '!`' skills/systematic-debugging/
    find . -name 'hooks.json' -not -path './node_modules/*'
    ls skills/systematic-debugging/

    A conventions or debugging skill should describe how to work. Stop if it tells the agent to fetch a URL, pipe a script to a shell, write outside the project, or send data anywhere. For a large skill, let an agent do the first pass with the review prompt below, in a session that cannot act on what it reads.

  5. Install at project scope and prove the installed copy matches the reviewed one. Run this from the root of your repository:

    Terminal window
    npx skills add obra/superpowers --skill systematic-debugging -a claude-code -a codex -a cursor --copy -y
    diff -r /tmp/skill-review/superpowers/skills/systematic-debugging .claude/skills/systematic-debugging && echo "installed = reviewed"

    --copy writes real files instead of symlinks, so the skill text lands in your diff. The CLI writes .claude/skills/ for Claude Code and .agents/skills/ for Codex and Cursor, plus a skills-lock.json entry with the source and a content hash. Commit all three in one pull request.

Run that prompt in a session that cannot act on what it reads. The review clone is not your project, so load none of its configuration:

Terminal window
cd /tmp/skill-review/superpowers
claude --safe-mode --permission-mode manual

--safe-mode starts with CLAUDE.md, skills, plugins, hooks and MCP servers disabled while managed policy still applies. The flag arrived in v2.1.169, so both release channels have it: latest (2.1.283) and stable (2.1.274) on 2026-09-26. Manual mode runs reads without asking and prompts for everything else, so decline any command the session proposes. Avoid plan mode here: it can run classifier-approved commands when auto mode is available.

Skill or plugin: which install form should you vet?

Section titled “Skill or plugin: which install form should you vet?”

Many projects ship both a portable skill and a plugin, and they are not the same artifact. npx skills add obra/superpowers copies skills only. The plugin adds the SessionStart hook that makes the method fire automatically. That hook is also the part that runs without a prompt, so a plugin needs its hooks read in step 4.

Terminal window
claude plugin install superpowers@claude-plugins-official
claude plugin details superpowers@claude-plugins-official

claude plugin details prints the plugin’s component inventory, including hooks, and its projected token cost: about 838 always-on tokens for Superpowers, while ECC loads about 41,515 (measured 2026-09-26). The scanner itself is a CLI and adds nothing to the context window.

Why install skills at project scope?

Section titled “Why install skills at project scope?”

A project-scope skill lives in the repository, so every change to it arrives as a pull request diff that a reviewer and CI can see. A global install (-g) lands in ~/.claude/skills/ or ~/.codex/skills/, applies to every repository on that machine, and never passes review.

Project scope has one sharp edge in Claude Code: a project skill’s allowed-tools and frontmatter hooks apply whenever it is invoked, including in a claude -p run in a folder you never trusted. Before you script the agent over a repository you did not write, read its .claude/ directory, or run it with --bare --setting-sources "" --strict-mcp-config --disable-slash-commands. --bare alone still resolves skills, and --disable-slash-commands turns them off (claude --help, 2.1.283 on the latest channel).

Enforce a team skill allowlist with managed settings

Section titled “Enforce a team skill allowlist with managed settings”

A routine that each developer runs voluntarily lasts until the first deadline. For a team, make the reviewed set the only set that loads. Pick the level that fits your risk:

LevelWho it fitsWhere approved skills liveWhat blocks everything else
1. Reviewed in the repositoryMost product teams.claude/skills/, .agents/skills/, skills-lock.jsonCODEOWNERS approval plus managed limits on hooks and inline shell
2. Plugin-only supply chainRegulated or high-value codeAn internal plugin marketplacestrictPluginOnlyCustomization stops user and project skills from loading

  1. Require an owner’s approval for skill changes. Add the paths to CODEOWNERS and turn on required code-owner review in branch protection:

    /.claude/skills/        @acme/agent-platform
    /.agents/skills/        @acme/agent-platform
    /skills-lock.json       @acme/agent-platform
    /.claude/settings.json  @acme/agent-platform
    /.skillspector-baseline.yaml  @acme/agent-platform
    /.github/workflows/     @acme/agent-platform

  2. Write the managed policy. For Claude Code, deliver it as server-managed settings (Team and Enterprise), an MDM profile, or managed-settings.json (/etc/claude-code/ on Linux and WSL, /Library/Application Support/ClaudeCode/ on macOS, C:\Program Files\ClaudeCode\ on Windows). Users cannot override these keys. This is the level 1 policy:

    {
      "strictKnownMarketplaces": [
        { "source": "github", "repo": "anthropics/claude-plugins-official" },
        { "source": "github", "repo": "acme/agent-plugins" }
      ],
      "allowManagedHooksOnly": true,
      "disableSkillShellExecution": true,
      "enabledPlugins": {
        "superpowers@claude-plugins-official": true
      }
    }
    • strictKnownMarketplaces limits which marketplaces users can add and install from.
    • allowManagedHooksOnly runs only managed hooks and hooks from plugins that managed enabledPlugins force-enables; user, project and other plugin hooks are blocked. That is why Superpowers is listed: without the entry its SessionStart hook stops running.
    • disableSkillShellExecution replaces every !`command` in user, project, plugin and additional-directory skills with [shell command execution disabled by policy].

    For level 2, add "strictPluginOnlyCustomization": ["skills", "hooks"]. Claude Code then stops loading skills from ~/.claude/skills/, .claude/skills/, --add-dir directories and claude.ai sync, and keeps plugin, bundled and managed skills. Package approved skills as plugins in your team marketplace. Under level 2, the project-scope install in step 5 of the routine no longer loads in Claude Code, which is the intent.

  3. Apply the equivalent controls in Codex and Cursor.

    Admin constraints go in requirements.toml, not config.toml. Set allow_managed_hooks_only = true there to ignore user, project and session hook configs. The same file can also constrain plugins and marketplaces (Codex config_requirements.rs, checked 2026-09-26); check that schema for the exact shape before you deploy it. Project skills live in .agents/skills/, which step 1 already puts under code-owner review.

  4. Scan every change in CI. The code owner then reviews findings, not raw skill text. SkillSpector needs no token and starts nothing; with --no-llm only declared dependency names and versions leave the runner, for the OSV.dev CVE check. By default it exits 0 for SAFE and CAUTION results, so the loop passes --fail-on-findings and collects every scan’s status instead of only the last one:

    Terminal window
    set -euo pipefail
    shopt -s nullglob
    uv tool install git+https://github.com/NVIDIA/skillspector.git
    mkdir -p sarif
    fail=0
    for d in .claude/skills/*/ .agents/skills/*/; do
      skillspector scan "$d" --no-llm --fail-on-findings \
        --baseline .skillspector-baseline.yaml \
        --format sarif --output "sarif/$(echo "$d" | tr / _).sarif" || fail=1
    done
    exit $fail

    Any active finding that the baseline does not cover fails the job, and with it the pull request. The baseline file and the workflow are in the CODEOWNERS block from step 1 because a pull request can edit both: on pull_request, GitHub runs the workflow from the pull request’s merge ref. Upload the sarif/ files as a job artifact or to code scanning. --baseline needs the file to exist, so leave the flag out until you commit the first accepted finding.

    Snyk Agent Scan’s --ci flag, which exits non-zero on findings, requires --dangerously-run-mcp-servers in 0.6.8. That flag starts every stdio MCP server in the scanned configs, so use it only on a disposable runner that holds no secrets beyond SNYK_TOKEN, and only on the default branch or a schedule, never on a pull request: there the configs, and so the commands it starts, are the contributor’s, and they would run next to SNYK_TOKEN. The full CI pattern is in security gates for agent-written code.

How do you know the controls are working?

Section titled “How do you know the controls are working?”

Four checks give you evidence without re-reading every skill:

  • The installed copy is the reviewed copy. The diff -r in step 5 of the routine is empty, and skills-lock.json records a content hash for each skill. Treat a later npx skills update as a new install, with the same routine in its own pull request.
  • Only the allowlist loads. In a fresh Claude Code session, /skills lists every skill with its source. Under level 2, a skill you drop into ~/.claude/skills/ does not appear. /hooks shows which hooks are active, and /status names the managed source in use.
  • Every change had an owner. Branch protection shows the code-owner approval on each pull request that touched a skills path, with the scan report attached.
  • The fleet matches the policy. A scheduled uvx snyk-agent-scan@latest across developer machines inventories every skill and MCP server, and Dr. Skill shows conflicts across the whole loadout.

Sign-off sits with the code owners for skill changes and with whoever owns managed policy for the settings file.

Scanner noise versus real risk

Section titled “Scanner noise versus real risk”

A scanner flags patterns; your job is to decide intent. Third-party scanners rate some of the most-installed skills “High Risk”: a mondoo.com search-result title (secondary) rates obra’s systematic-debugging that way, plausibly because of shipped test fixtures (obra/superpowers issue #2277). Triage by what the finding means in context:

FindingLikely real whenLikely noise whenAction
Prompt injectionThe text addresses the agent and overrides your rulesThe skill is about prompt injection and quotes examplesRead the lines; reject if the instruction is live
Suspicious download or network callA workflow skill fetches and runs codeA documented install step for a known toolPin the tool yourself instead of letting the skill fetch it
Malicious code or dangerous executionIt sits in a script the skill tells the agent to runIt sits in a test fixture the skill never invokesConfirm with grep which files the SKILL.md references
Hardcoded secretAny real-looking keyAn obvious placeholder in an exampleReject until the author removes it

When you accept a finding as noise, record why in the pull request and baseline narrowly: one SkillSpector baseline rule that sets the finding’s id and path and the required reason (see .skillspector-baseline.example.yaml in its repository). Running skillspector baseline <dir> on its own accepts every current finding, real ones included. Snyk Agent Scan’s --ignore-risks <name> drops a whole risk category from --ci evaluation, so avoid it for one-off noise. Never turn the scan off.

When skill security controls fail

Section titled “When skill security controls fail”

You installed a copycat. Remove it with npx skills remove <name> (-g for user scope), then check git status and git diff for changes made while it was loaded. Check memory files such as CLAUDE.md and AGENTS.md for text you did not write. Rotate any credential the agent could read in those sessions.

The agent followed a hidden instruction. Before you investigate, quarantine the skill fleet-wide with a managed Skill(skill:<name>) deny rule so no other session loads it. Then find the instruction with the review prompt and report the repository to the marketplace that listed it.

A hook ran code even though every scan was clean. Hooks run outside the permission prompt. List them with /hooks or claude plugin details <plugin>, disable the plugin with claude plugin disable <plugin>, and move the team to allowManagedHooksOnly so only vetted plugins run hooks.

CI flags a skill the team depends on. Read the finding with the triage table. If it is noise, add a baseline rule for that one finding (id, path, reason) in the same pull request; never regenerate the whole baseline or reach for --ignore-risks. If it is real, restore the last clean copy from git history, which --copy made possible: git checkout <last-clean-commit> -- .claude/skills/<name> .agents/skills/<name> skills-lock.json.

Managed settings do not seem to apply. By default Claude Code uses only the highest-ranked managed source that delivers a policy key (server-managed, then MDM, then managed-settings.json) and ignores the rest without a warning. Open /status: it names the source in use and the sources it skipped. Put the whole policy in the source that wins, or set managedSourcesBehavior to "merge" (v2.1.242 or later).

Where to go next with skill security

Section titled “Where to go next with skill security”
Installing, sharing and pinning skills The full skills CLI: scopes, updates, lockfiles and team sharing.
Securing MCP servers The same scan-and-approve routine for MCP configs, plus read-only modes.
Build a team plugin marketplace Package approved skills as plugins for a level 2 allowlist.
Security gates for agent-written code Semgrep, Gitleaks, Snyk and review agents in CI.
Managed policy for coding agents Where managed settings live and who owns them.
Agent threat model How skill injection fits the wider set of agent risks.

Written by

See what's new on the platform.

Privacy Policy Terms of Service Cookie settings