Snyk Agent Scan: finding prompt injection in MCP servers and agent skills

The gap Agent Scan targets: agent components nobody inventories

A developer workstation accumulates agent configuration quietly. Claude Code and Claude Desktop, Cursor, Windsurf, Gemini CLI, Amp and Amazon Q each keep their own MCP configuration file, and each file points at stdio servers that will be started on demand. Skills are worse: they are natural-language documents, so a malicious instruction looks like ordinary prose. Agent Scan exists to enumerate those components and then read them the way a model would.

The intended user is a security engineer or a developer who wants an inventory of what is already installed, not a platform team building a pipeline. The README frames the tool as a discovery and scanning CLI, and the enterprise note points larger deployments at Snyk's Evo platform instead. That split is worth taking seriously: the CLI is positioned for local inspection, and the README explicitly says the CLI output may not reflect what the Evo platform shows.

Discovery, execution and the analysis API

The data flow has three stages. First, discovery: Agent Scan walks known agent locations, including Claude, Cursor, Windsurf, Gemini CLI, Amp and Amazon Q, and collects MCP configurations plus skill files. Second, execution: for a stdio MCP server, the scanner starts the process defined in the config so it can retrieve tool descriptions, prompts and resources. Third, analysis: the collected material goes to a Snyk analysis API, and the CLI renders the result.

That second stage is the design decision everything else follows from. Tool descriptions only exist at runtime, so static parsing of a config file would miss poisoned or shadowed tools. The cost is that scanning a config means running whatever command the config names. The README states this plainly and recommends a sandbox, a careful read of the consent prompt, and reserves `--dangerously-run-mcp-servers` for environments where every command has already been verified.

The API version tracks the CLI line. The README says v0.5.x uses the `2025-09-02` analysis API with issue-code output, while v0.6 and later use the `2026-07-10` analysis API with risk-based output. That is a real fork in behaviour, not a cosmetic version bump.

Installing Agent Scan with uvx and running a first scan

There is no npm package. The README offers two routes: `uvx` for the Python package, or a standalone binary from GitHub Releases. Both need a Snyk account and an API token, which the README says to take from the account page under API Token, then set as an environment variable.

export SNYK_TOKEN=your-api-token-here

With `uv` installed, the current line runs through `uvx`. The README pins v0.5.17 as a concrete v0.5.x example, and uses `@latest` for v0.6 and later. Pinning matters here, because the two lines produce different output shapes.

uvx snyk-agent-scan@latest ~/.vscode/mcp.json

That scans one MCP configuration instead of the whole machine. During an interactive run the scanner asks for consent before starting each stdio server, and the prompt shows the command and arguments it is about to execute. Running `uvx snyk-agent-scan@latest` with no path scans the whole machine.

Skills are scanned from a path too. A single skill file and a whole skills directory both work.

uvx snyk-agent-scan@latest ~/path/to/my/SKILL.md
uvx snyk-agent-scan@latest ~/.claude/skills

The README notes that skill analysis can be turned off with `--no-skills` when you only care about MCP servers. The standalone binary route skips Python entirely: download the build for your OS and architecture from the latest release, where the project also publishes an SBOM, checksums and signed checksums.

The output contract is explicitly unstable

This is the limitation to weigh before anything else. The README carries a warning that the raw CLI output, including issue codes, field names, severity labels, risk indicator names, scores and response structure, is experimental and may change without notice between releases. It then says the project does not recommend building production workflows that depend on specific CLI output fields or risk names.

For a scanner, that is an unusual admission, and it changes who the tool is for. A human reading a report is fine. A CI job that greps for a particular issue code is not, because the code can be renamed in a patch release. The deprecation notice for the v0.5.x line compounds it: the issue-code output is planned for deprecation, so anything written against those codes has a known expiry.

The second limitation is the execution model itself. Any scanner that starts MCP servers inherits the risk of the servers it starts. A sandbox is the mitigation the README recommends, and it is the right one, but it also means the tool is awkward to run directly on a developer's primary machine against a config of unknown origin. The third is scope: Agent Scan reads what is installed and reachable, so an agent component that is not in a supported location will not appear in the inventory.

How this differs from MCP-Scan and Tenable's agent scanning

MCP-Scan from Invariant Labs is the closest comparison, and the difference is in what gets collected and where analysis happens. Agent Scan discovers agent components across Claude, Cursor, Windsurf, Gemini CLI, Amp and Amazon Q, and it scans skills as well as MCP servers, sending the collected material to a Snyk analysis API under a Snyk token. MCP-Scan is an MCP-focused scanner; the related searches pair the two names because they answer overlapping questions, but the component coverage is not the same.

Tenable's agent scanning is a different category of product. It is agent-based vulnerability assessment aimed at infrastructure, where a scanner is deployed into an environment to enumerate hosts and software. Agent Scan is not doing host assessment. It reads MCP configs and skill documents, executes stdio servers to get tool descriptions, and asks a Snyk API whether those descriptions contain prompt injection, tool poisoning or hidden payloads. If your question is "which servers and skills are on this laptop, and do their descriptions look hostile", Agent Scan is aimed at that. If your question is "what is installed on this fleet of servers", it is not.

Licence, releases and the cost of keeping up

Agent Scan is Apache-2.0, declared in the repository's LICENSE file and in `pyproject.toml` as `license = {text = "Apache-2.0"}`. That is a permissive licence, but the tool is not self-contained: scans call a Snyk analysis API and require `SNYK_TOKEN`, so the practical terms of use are governed by your Snyk account and the repository's TERMS.md as much as by the licence file. Read both before wiring the CLI into anything that touches client data.

The upgrade cost is higher than the version numbers suggest. The project ships snapshot releases alongside tagged ones, and the README documents two output generations with different analysis API versions. A team that pins `[email protected]` gets issue-code output on the `2025-09-02` API; moving to `@latest` switches to risk-based output on the `2026-07-10` API. That is a migration, not an upgrade. The last push to the repository was on 2026-09-10, the same day v0.6.3 was tagged, so the v0.6 line is where current work is landing. Python 3.10 or later is required, and the dependency list pins `mcp[cli]==1.28.1` along with an override block for transitive packages, which is worth knowing if you vendor the tool into an existing environment.

Editorial conclusion

Adopt Agent Scan if you already hold a Snyk token and want a quick inventory of MCP configs and skills on a developer machine, run inside a container or VM. Skip it if you need a stable machine-readable output contract, since the README states the CLI output is experimental and may change between releases. Before trusting a run, verify the consent prompt against the MCP config yourself, confirm whether you are on the v0.5.x issue-code line or the v0.6 risk-based line, and read SECURITY.md for the execution warning.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. snyk/agent-scan on GitHub