NVIDIA SkillSpector: Scanning Agent Skills Before You Install Them

Agent skills are the newest way to extend an AI agent, and they are also an unreviewed supply-chain surface: a skill is instructions, code, and configuration that an agent will execute with real access, often installed from a public repository with no more scrutiny than a copy-paste. NVIDIA SkillSpector is an open-source tool built for exactly that gap - it scans an agent skill for vulnerabilities, malicious patterns, and security risks before you install it. This guide explains what NVIDIA SkillSpector is, what it detects across its 68 patterns, how its two-stage analysis works, how to run it in practice, and - honestly - where its scope ends and runtime governance begins.

If skills are new to you, start with our agent skills security primer; if you are building an approval process around them, the vetting and approving agent skills playbook is the companion piece to this one. The short version of why scanning matters now: skills have moved from novelty to daily use, and a malicious or vulnerable skill can carry hidden payloads that only surface at runtime - the class of problem documented in the USENIX 2026 malicious agent skills research. A scanner that reads a skill before it ever runs is a genuinely useful first line of defense.

What NVIDIA SkillSpector is

NVIDIA SkillSpector is an open-source security scanner, released under the Apache License 2.0, whose stated goal is to detect vulnerabilities, malicious patterns, and security risks before installing agent skills. It targets the skills consumed by coding agents such as Claude Code and the OpenAI Codex CLI, and similar agents that load skills to extend what they can do. In other words, it is a pre-install gate for the skill supply chain.

It is flexible about what you point it at. SkillSpector accepts git repositories, URLs, zip files, directories, single files (including a lone .md file), and local paths. That range matters because skills are distributed in all of those forms - a repo you are considering, a zip someone shared, a directory already on disk - and the scanner can inspect each before it becomes a trusted, installed extension. It does one job and does it at the right moment: content inspection, before install.

What NVIDIA SkillSpector scans and detects

SkillSpector detects 68 vulnerability patterns across 17 categories. The categories read like a threat model for the skill layer, covering everything from the prompt-level tricks that subvert an agent's instructions to the supply-chain and MCP-specific risks that come from what a skill pulls in and what tools it can reach. The table below lists each category with the number of patterns it contributes.

A few of these deserve a nod because they map to threats we track closely. The Supply Chain category (6 patterns) is the skill-layer version of the risks in our AI supply-chain attacks defender's guide, and it is the surface that dependency-takeover attacks like skilljacking exploit. The two MCP categories - MCP Least Privilege (4) and MCP Tool Poisoning (4) - line up with over-broad tool grants (see least privilege for agent skills) and with hidden instructions smuggled into tool definitions, the pattern behind the MCP tool-poisoning campaign. Taken together the 17 categories align well with the OWASP agentic skills Top 10, which is a reasonable way to sanity-check coverage.

How NVIDIA SkillSpector works

SkillSpector runs a two-stage analysis, and understanding the split is the key to using it well.

Stage one is static and fast. It combines regex pattern matching against the skill's text and code, AST-based behavioral analysis that examines what the code structurally does rather than just how it reads, and live CVE lookups against OSV.dev to flag known-vulnerable dependencies. This stage is cheap enough to run on every skill, every time, and it is what powers a CI gate or a pre-install check without a model call in the loop.

Stage two is an optional LLM semantic pass. Where static analysis flags a pattern, the semantic stage evaluates context and intent - is this genuinely malicious, or a false positive that happens to match a signature? It filters noise and produces human-readable explanations of each finding, which turns a raw list of hits into something a reviewer can act on. You run it when you want higher-fidelity triage; you skip it when you want speed. That two-tier design is sensible: fast and deterministic first, expensive and contextual only where it earns its keep.

How to run NVIDIA SkillSpector

SkillSpector is built to slot into real workflows in four ways, from a one-off command to an automated gate.

• CLI. Run it directly against a repo, URL, zip, directory, or file, with a choice of output formats for human reading or machine parsing. This is the fastest way to vet a single skill you are considering.
• CI/CD gate. SkillSpector returns exit codes a pipeline can branch on and can emit SARIF output for code-scanning dashboards, so a build can fail automatically when a skill scores high-risk.
• Pre-install MCP gate. It can register as an MCP server, letting an agent scan a skill at install time and gate it before it is ever loaded - runtime prevention at the moment of installation.
• Python API. A programmatic interface built on a LangGraph workflow lets you embed scanning into your own tooling and orchestrate the two stages yourself.

The CI/CD path is the one most teams standardize on, because it makes vetting non-optional. The gate logic is driven entirely by the exit code:

# Pre-merge gate concept - branch on SkillSpector's exit code
# 0 = safe or caution   1 = high-risk   2 = scan error

scan the skill source with SkillSpector

case exit_code in
  0)  allow the merge, keep the SARIF report as evidence ;;
  1)  block the merge, surface the SARIF findings for review ;;
  2)  fail closed and investigate the error before trusting the result ;;
esac

Failing closed on exit code 2 matters: a scan that errored is not a scan that passed. Wire the SARIF output into wherever your team already triages code-scanning results so skill findings do not live in a silo. For a fuller process around who approves what after the scan runs, see the vetting and approving agent skills playbook.

What NVIDIA SkillSpector does not do

This is not a knock on the tool - it is scope, and being clear about scope is how you build the right layered defense. SkillSpector is a scanner. It answers one question, well: is this skill's content risky before I install it? It reads a skill you hand it, at the moment you hand it over, and reports what it finds.

Three things sit outside that scope by design. First, it does not maintain a fleet inventory of the skills actually installed across your endpoints - it scans what you point it at, not what is already deployed and running on developer laptops and build machines. Second, it has no view of which endpoint runs which skill or which version, so it cannot tell you where an approved skill drifted or where an unscanned one slipped in. Third, it does not enforce policy at runtime; once a skill is installed and executing, the scanner's job is done. A skill that passed a scan last month, then received a malicious update, is exactly the kind of change a scan-time gate is not positioned to catch. Those are runtime and inventory problems, and they need a runtime and inventory tool.

How Anomity complements NVIDIA SkillSpector

The clean way to think about it: SkillSpector is the gate at the door, and Anomity is the floor plan plus the guard on every floor. Scan-time vetting keeps risky skills from being installed in the first place; runtime inventory and governance tell you what is actually deployed and govern what it does. You want both. Anomity's category is agentic endpoint security, and it is built on one principle - you can't govern what you can't see.

A lightweight, unprivileged Endpoint Sensor runs on every managed endpoint (Windows, macOS, and Linux) and discovers and inventories eight AI artifact types, skills among them, alongside AI agents, MCP servers, extensions, plugins, secrets, hooks, and CLIs. That is the fleet inventory a scanner cannot give you: which skills are installed, where, and in what version - see how discovery works. The sensor sends metadata only over HTTPS to the Anomity Cloud; never source code, never prompts, and secrets are redacted on the endpoint.

From there, governance is continuous rather than one-shot. On agents that expose a hook - for example the Claude Code PreToolUse hook - Anomity returns allow, deny, or log before a tool call runs, so a skill that tries something out of policy at runtime can be stopped, not just flagged after the fact. Every skill added, removed, or modified raises a change event, so the malicious-update case that slips past a one-time scan surfaces immediately, and violations route to your SIEM, Slack, email, and Jira - see runtime governance and the outcomes it drives. Every one of those events lands in a queryable 90-day audit trail. Anomity is SOC 2 Type II and complements your EDR and XDR, DLP, network and gateway controls, and GRC program rather than replacing them. For how scan-time and runtime layers line up side by side, see the comparison.

Used together, the flow is straightforward: run SkillSpector to keep bad skills out at install time, and run Anomity to know exactly which skills made it onto your fleet and to govern what they do while they run. Defense in depth is not two tools competing for the same job - it is a gate and a guard doing different jobs on purpose.

You can't govern what you can't see.The Anomity principle

Scanning a skill before install is the right first move, and NVIDIA SkillSpector does it well: 68 patterns, two-stage analysis, and enough integration surface to make vetting automatic. But a scan is a snapshot, and the skills on your fleet are a moving target - installed on machines you do not watch by hand, updated after they were approved, running with access no scanner sees. Pair scan-time vetting with runtime inventory and governance and you close both halves. To see which skills, agents, and MCP servers are actually running across your endpoints - and to govern them at the hook with a 90-day audit trail - start with the Anomity docs or book a 30-minute demo.