NVIDIA SkillSpector: Scan AI Skills Before Installing — 26% of Skills Contain Vulnerabilities

One evening, you find a skill for Claude Code with a healthy star count on GitHub. The description matches exactly what you need, so you run one install command — and from then on, every time you ask the agent to work, that skill is read, executed, and trusted almost without question.

That is the problem. A skill is not a harmless note. It is a package containing a SKILL.md file, accompanying scripts, and MCP configuration — instructions, code, and tool permissions in one bundle. If it hides an instruction to send environment variables elsewhere, or an MCP tool requests broader permissions than it needs, you will notice nothing until the data has already left your machine.

SkillSpector is NVIDIA’s open-source scanner: it scans an AI skill before you install it, then returns a risk score from 0–100 with a recommendation of SAFE, CAUTION, or DO NOT INSTALL. This article explains how it scans, how to install it and read its results, and when it is enough — and when manual review is still needed.

The opening figure needs its source stated clearly: according to NVIDIA’s research on 31,132 skills, 26.1% contain vulnerabilities and 5.2% show signs of malicious intent. These are figures published by NVIDIA, not independent measurements by this blog.

What Is SkillSpector? A Supply-Chain Scanner for AI Skills

What an AI skill is, and why it is a new attack surface

A skill for Claude Code, Codex, or Gemini CLI is usually just a small folder: a SKILL.md file, a few helper scripts, and possibly MCP configuration. Small as it is, the agent treats it as trusted instruction — reading files, running shell commands, calling APIs — and users rarely read every line before installing.

Common risk vectors include prompt injection, data exfiltration, privilege escalation, supply-chain takeover of a skill repository, MCP tool poisoning, and memory poisoning. None of these requires exploiting an operating-system vulnerability. It is enough for the agent to trust the skill.

A security skill should itself be scanned like any other. The article on Cloudflare’s security audit skill shows how useful a carefully written skill can be. For how skills work in a coding agent’s workflow, see taste-skill and Superpowers.

The exact problem SkillSpector solves

SkillSpector places a checkpoint before installation: instead of detecting an incident after the agent has already run a malicious skill, you scan first, read the score, and decide whether to install. It scans skills for Claude Code, Codex, Gemini CLI, and MCP.

Verified project information as of 2026-11-09: repository NVIDIA/skillspector, Apache-2.0 license, 24,955 stars and 2,181 forks, created on 2026-03-21, latest release v2.13.4 published on 2026-11-04, requires Python 3.12 or later, documentation at docs.nvidia.com/skills/scanning-agent-skills. SkillSpector is one link in the NVIDIA Verified Skills pipeline: skills that meet the standard are scanned, evaluated, signed, and added to NVIDIA’s catalog — a sign it sits inside a maintained process, not a one-off repository.

Who should use it — and who does not need it yet

Use it if you install skills from GitHub frequently, manage many agents as a DevOps engineer or SRE, or are an IT manager responsible for AI agent supply chain. It is not yet a priority if you only use first-party skills, skills you have already reviewed carefully, or if your environment installs no external skills.

SkillSpector Architecture: Two Scan Layers, One Risk Score

The skill-scanning pipeline

flowchart LR
    A["Input\nSkill folder / SKILL.md\nGitHub repo URL / .zip file"] --> B["Ingest & safety limits\nCap 100 MiB, max 10,000 zip members\nFail-closed when limits are exceeded"]
    B --> C["Layer 1 — Static analysis\n71 patterns per README* / 17 categories\nAST, taint tracking, YARA\nMCP least privilege & tool poisoning"]
    C --> D["Layer 2 — LLM semantic review\nDefault nv_build, model z-ai/glm-5.3\nRequires NVIDIA_INFERENCE_KEY, disable with --no-llm"]
    C --> E["CVE lookup via OSV.dev\nRuns in parallel with analysis\nOffline fallback when no network"]
    D --> F["Risk score 0–100\n+ severity labels"]
    E --> F
    F --> G["Recommendation\nSAFE / CAUTION\nDO NOT INSTALL\nTerminal / JSON / Markdown / SARIF"]

Note: the pattern count is 71 per the README, while NVIDIA’s documentation says 68 — it changes between releases, so check the count for your exact version. The LLM layer runs by default when a provider and a valid key are available; disable it with --no-llm. OSV.dev lookup runs in parallel. The final score combines all three sources — static analysis, LLM review, and CVE lookup. The fail-closed gate sits at ingest: if a limit is exceeded, scanning stops instead of producing a partial scan that reports SAFE.

What the static layer can do — and the limits of pattern matching

The static layer scans a skill with 71 patterns across 17 categories according to the README — NVIDIA’s documentation says 68, and the number changes between releases: prompt injection, data exfiltration, privilege escalation, supply chain, excessive agency, output handling, system prompt leakage, memory poisoning, tool misuse, rogue agent, anti-refusal, trigger abuse, dangerous code, taint tracking, YARA, MCP least privilege, and MCP tool poisoning. Examples: a hidden shell command in SKILL.md that reads a credential file and sends it out, or an MCP tool requesting file-write permission when its job only requires reading.

The tool does more than match strings: AST analysis looks at code structure, taint tracking follows sensitive data from source to destination, YARA signatures catch known dangerous code patterns, and the MCP least-privilege check compares requested permissions against what the job needs. The limit: patterns only catch what is already known or clearly suspicious — a cleverly written malicious skill can still slip through, so a clean score is not a safety certificate.

The optional LLM layer — when to enable it, when to turn it off

The LLM layer evaluates the semantic meaning of a skill: it catches malicious instructions in natural language that rigid patterns miss. The cost is that skill content is sent to an LLM provider, configured through SKILLSPECTOR_PROVIDER, supporting OpenAI, Anthropic, AWS Bedrock, Gemini, Azure OpenAI, Ollama, and NVIDIA’s build endpoint. By default, the provider is nv_build with the model z-ai/glm-5.3 on build.nvidia.com, requiring NVIDIA_INFERENCE_KEY. It runs by default when a provider and a valid key are available — it is not opt-in. To turn it off, add --no-llm.

If you are scanning an internal skill that contains secrets, or you have no API key and do not want content sent out, add --no-llm. Static scanning still runs in full, and in my view this is the right choice for most cases.

The 0–100 risk score and three recommendations — how to read them

The risk score is a combined heuristic, not a probability of being attacked. Do not read 20/100 as a “20% chance of being hacked”. Read it through the recommendation: DO NOT INSTALL is a hard block — do not install it, and do not look for a way around it; CAUTION means mandatory manual review — open the skill, understand each finding, then decide; SAFE means no issue was found within the scope of the scan, and you should still keep the habit of periodic checks. A report consists of a list of findings, the severity of each finding, and an overall recommendation.

Installing SkillSpector and Scanning Your First Skill

Before installing

You need Python 3.12 or later and uv — the Python management tool recommended by the documentation. You need Git if installing from source, and Docker to scan fully isolated from the host machine. The LLM layer is on by default, so it needs a key: the default provider nv_build uses NVIDIA_INFERENCE_KEY; a static scan with --no-llm needs no key. Note: SkillSpector is currently not on PyPI per the current documentation. Do not run pip install skillspector, and do not install some same-named package from PyPI thinking it is this tool.

Installation — three ways

Option 1, recommended, with uv:

uv tool install git+https://github.com/NVIDIA/skillspector.git

For the MCP feature, install the variant with the mcp extra:

uv tool install 'skillspector[mcp] @ git+https://github.com/NVIDIA/skillspector.git'

Option 2, from source, when you want to inspect the code or contribute:

git clone https://github.com/NVIDIA/skillspector.git
cd skillspector
uv venv .venv && source .venv/bin/activate
make install

Option 3, Docker, when you want to scan a skill you do not trust without touching the host machine:

make docker-build
docker run --rm -v "$PWD:/scan" skillspector scan ./my-skill/ --no-llm

Verify the installation with skillspector --help — if it shows help with the scan subcommand, the tool is ready. The latest version checked is v2.13.4 (2026-11-04) — when consulting the documentation, note the version you are running, as pattern counts and behaviour may differ between releases.

Scanning a skill — input types and sample commands

skillspector scan ./my-skill/
skillspector scan ./SKILL.md
skillspector scan https://github.com/user/my-skill
skillspector scan ./my-skill.zip
skillspector scan ./my-skill/ --no-llm
skillspector scan ./my-skill/ --format json --output report.json

Besides JSON, the tool supports terminal, Markdown, and SARIF output. SARIF is useful when you want to feed findings into GitHub code scanning, since it is the standard format GitHub already understands.

Reading the report and common errors

Read a report in this order: the overall recommendation first, then the highest-severity finding, then the details. If the result is DO NOT INSTALL, stop. If it is CAUTION, open each finding and check the file and line for each finding, and check whether the behavior has a legitimate reason — a valid skill is sometimes flagged simply because it genuinely runs shell commands or reads sensitive files. If it is SAFE, save the report for comparison when the skill is updated.

I have not run SkillSpector myself, so there is no sample terminal output or specific score for a real skill here; the commands above were checked against the official documentation only.

Common errors: Python below 3.12 — check python3 --version before installing. Missing uv — install uv following uv’s official guide, then retry. Scanning a private repository without access — clone it locally first, then scan the local folder. Exceeding the ingest limits, a zip over 100 MiB or with more than 10,000 zip members — the tool blocks outright by fail-closed design; narrow the scan scope, do not work around the limit. Running without --no-llm with no NVIDIA_INFERENCE_KEY for the default nv_build provider — add --no-llm or set the key.

Adding SkillSpector to CI

A scanner with machine-readable output can be wired into CI: every pull request that adds or changes a skill must pass a scan; DO NOT INSTALL blocks the merge; CAUTION requires manual review with a note, not a blind merge. SARIF brings findings into GitHub code scanning, and a baseline keeps the team from being blocked by findings already accepted.

Exit codes make this gate feasible without parsing output yourself. Per the documentation, skillspector scan returns 0 when the risk score is ≤ 50 (SAFE or CAUTION) and no strict gate is violated; 1 when the score exceeds 50 or a blocking flag is violated; and 2 on error. The blocking flags are --fail-on-findings (block when any finding exists), --fail-on-incomplete (block when a scan does not complete), and --min-coverage (block when analysis coverage is below the threshold). A minimal CI step:

- name: Scan new skills
  run: skillspector scan ./skills/ --no-llm --fail-on-findings --fail-on-incomplete

The --no-llm flag keeps the CI step free of LLM keys and avoids sending skill content outside. Before production CI, test it on a test repository first, then finalize the threshold. SkillSpector complements Heldkeys (permissions after installation), iFixAi (auditing a deployed agent), and Shannon (pentesting web apps and APIs): it blocks at the door, before a skill ever gets to run.

Removing a skill and recovering after an incident

Removing a skill does not recover data that has already leaked. If a malicious skill has already run, revoke exposed credentials, review agent logs and related systems, and check which tools it called and where it sent data. Scanning before installation is prevention, not remediation.

Technical Assessment: Where SkillSpector Is Strong, Where It Is Weak

Strengths

It is free, open source under Apache-2.0, and from NVIDIA — a trustworthy publisher with a dense update cadence, going from v2.13.1 to v2.13.4 in about 12 days. It covers 17 categories across Claude Code, Codex, and MCP skills, hitting exactly the blind spot access checks like Heldkeys do not cover. It runs offline at the static layer with --no-llm, without sending code to a third-party LLM, and Docker is available for isolated scanning. Its machine-readable JSON and SARIF output can be wired into CI, not just run by hand.

Weaknesses and technical limits

Pattern-based detection is the biggest limit: the tool cannot prove a skill is safe, and a new, cleverly written malicious skill can still get through. The LLM layer is a double-edged sword: it costs money, sends skill content out, and the LLM itself has false positives and false negatives; by default it uses the nv_build provider with the model z-ai/glm-5.3 and requires NVIDIA_INFERENCE_KEY, so scanning without a key means remembering --no-llm. The tool does not replace manual review for internal skills containing secrets, or a sandbox or runtime monitoring after installation. Installing from GitHub via uv, with no PyPI package, is a small barrier for anyone used to pip install.

Security and operations

When scanning a skill you do not trust, run it in Docker or on a separate machine — do not scan on a machine holding credentials and then ignore the warnings. Use --no-llm for sensitive internal skills, and configure the LLM provider explicitly; do not let NVIDIA_INFERENCE_KEY or any other LLM key leak into a repository or CI logs. Fail-closed ingest is an operational plus: when a limit is exceeded, scanning stops instead of producing a partial scan that reports SAFE. No performance figures are given here: no independent benchmark has been verified, and social-media anecdotes about scan times or a specific skill’s score are unverified.

Comparing SkillSpector With Alternatives in the Same Scope

Criteria: scan scope, method, offline support, machine-readable output and CI integration, cost, and publisher. Do not invent competitor features or assign scores to tools that were not measured.

In short: SkillSpector is a cheap pre-install gate — free, with offline static scanning and machine-readable output for CI, without extra infrastructure. The other options cover different layers — permissions, post-deployment audit, runtime behavior — so they stack rather than replace each other. Manual review is still the baseline every team has, and what you return to for CAUTION.

Using SkillSpector in Practice — 4 Scenarios

Individual developer: scan before every install from GitHub. Download the skill, run skillspector scan ./my-skill/ --no-llm, read the recommendation, and install only when it is SAFE or after reviewing a CAUTION. Done consistently, this builds the habit of never installing a skill blind — like never running an unfamiliar script unread.

DevOps/SRE: gate skills in the CI of your agent repository. Every PR that adds or changes a skill must pass a scan. DO NOT INSTALL blocks the merge. CAUTION requires manual review with a reviewer note. Over time, a baseline lets the team focus only on new findings.

IT manager / sysadmin: standardize an approved skill catalog. Scan every skill in use and build an allowlist of skills that have passed inspection. A new skill outside the allowlist must pass a scan and approval before shared use. Combine this with Heldkeys to check permissions after installation — SkillSpector blocks at the door, Heldkeys checks what has already got inside.

Homelab: scan skills for an agent running on a home machine. Use Docker plus --no-llm for isolated scanning, without sending skill content anywhere. This works for self-written and community skills, and fits a home machine holding personal data you do not want to send to an unfamiliar LLM provider.

Conclusion — Who SkillSpector Fits, and Who It Does Not

SkillSpector fits people who install external skills often, teams managing many agents, and organizations starting to worry about AI supply chain without a gate at the installation step. It is cheap, runs offline at the static layer, and can be wired into CI — enough to turn “should I trust this skill?” from a gut feeling into a decision with a score and a hard block.

It does not fit anyone who needs an absolute safety guarantee — no scanner provides that — or a team that needs runtime control or a sandbox, because SkillSpector only looks at a skill in its static state before it runs. That team needs additional layers: permission limits, a sandbox, and post-deployment audits.

Next step: install it via uv or Docker, run skillspector scan ./my-skill/ --no-llm on a skill you already use, read the score and recommendation, then decide whether to add it to CI. One real scan of a real skill teaches more than ten introductions.

Lessons Learned

1. An AI skill runs with the agent’s implicit trust — scanning before install is cheaper than handling an incident after the agent has run a malicious skill.
2. A SAFE score is not a safety certificate: SkillSpector catches known patterns, and a cleverly written malicious skill can still slip through — manual review is still needed for CAUTION and sensitive skills.
3. --no-llm is the right default for internal or untrusted skills: static scanning blocks most obvious risks without sending content out.
4. The pattern count changes between releases, 71 per the README and 68 per NVIDIA’s documentation — always check the count for the version you run, and do not quote an absolute pattern number.
5. One scanner covers only one layer: SkillSpector blocks at the door, while Heldkeys-style permission checks, iFixAi-style audits, and runtime sandboxing are other layers to stack.
6. Fail-closed beats fail-open: when an ingest limit is exceeded, block outright instead of accepting a partial scan that reports SAFE.

Verification Scope

Check date: 2026-11-09. Verified from the README and GitHub API: project name, Apache-2.0 license, stars and forks, creation and latest push dates, release v2.13.4, Python 3.12+ requirement, install and scan commands, 71 patterns across 17 categories per the README (NVIDIA’s documentation says 68), the 0–100 risk score and three recommendation levels, and membership in the NVIDIA Verified Skills pipeline.

The 26.1% and 5.2% figures are NVIDIA’s research numbers on 31,132 skills, quoted from the source, not independent measurements by this blog. Not verified: the absolute pattern count, 71 versus 68; scan performance; any timing benchmark. SkillSpector was not installed, run, or benchmarked while writing this article — the install and scan commands were checked against the official documentation only, with no real sample output; the exit codes and CI blocking flags come from the official documentation and were not measured on the blog’s machine. No claim is made that SkillSpector catches any specific real-world malicious skill. Default behavior: the static layer always runs; the LLM layer is on by default when a provider and a valid key are available — the default provider is nv_build with the model z-ai/glm-5.3 on build.nvidia.com, requiring NVIDIA_INFERENCE_KEY — and is turned off with --no-llm; CVE lookup via OSV.dev has an offline fallback. The 100 MiB limit and 10,000 zip members are ingest configuration, not benchmarks.

References

• NVIDIA SkillSpector — GitHub: https://github.com/NVIDIA/skillspector
• NVIDIA Docs — Scanning agent skills: https://docs.nvidia.com/skills/scanning-agent-skills
• NVIDIA Skills catalog: https://github.com/NVIDIA/skills
• OSV.dev — CVE lookup: https://osv.dev/