Snyk Agent Scan starts the MCP servers it is scanning

Scanning an MCP config executes the commands inside it

The security warning at the top of the project says that scanning MCP configurations can execute commands or make outbound network requests, and the mechanism is concrete. To retrieve tool descriptions, Agent Scan starts stdio MCP servers by running the commands in the config, and it connects to configured remote MCP server URLs using their configured headers. The tool you point at a configuration is also the thing that launches whatever that configuration launches. The defaults are more careful than that first line suggests. Foreground interactive runs ask for an explicit y/n consent before contacting each discovered server, and the prompt shows the command or the remote URL for that server. Background and push-key scans keep inspecting remote servers automatically for fleet coverage, and they do not start stdio servers unless `--dangerously-run-mcp-servers` is set. The stated advice is to run scans inside a sandbox, a Docker container, a VM or a disposable environment, whenever the config being evaluated is untrusted or third party.

Loopback and private addresses stay reachable, link-local ones do not

Remote MCP requests are filtered by their resolved destination. They refuse link-local addresses and known cloud metadata endpoints, which the project names as 169.254.0.0/16, fe80::/10, fd00:ec2::254 and 100.100.100.200. Loopback and private addresses stay allowed on purpose, because local and internal MCP servers need them. HTTP redirects are not followed, so an allowed destination cannot bounce the request somewhere else afterwards. DNS is validated before each request, and that is exactly where the stated gap sits: resolution happens again at connection time, which leaves a DNS rebinding window open. Treat that as a documented limit of the check rather than a defect report. The filter keeps a scanner from reaching metadata services over a link-local route; it does not turn contacting a third party server into a local operation.

Two output shapes, and the older one is already on a deprecation list

The output contract is versioned and unstable by design. v0.5.x prints issue codes, v0.6 and later print risk indicator names and scores, and both are marked experimental for field names, severity labels and response structure, subject to change without notice between releases. The warning spells out the consequence once per version: do not build production workflows that depend on specific CLI output fields or issue codes, and do not build them on risk names either. The v0.5.x line is additionally flagged as planned for deprecation. There is also a platform gap the CLI cannot close. Enterprise customers using Snyk to manage agent security risk at scale are told the CLI output may not reflect what is sent to and shown in the Evo platform, while the underlying integration, discovery and risk assessment behind those deployments is described as stable and supported. For anything beyond a local check, the account team is the documented route.

There is no npm package, and the cleanup target still deletes one

Agent Scan is not on npm. The note at the top of the file says so and gives two routes instead: run the Python package with `uvx`, or download a standalone binary from GitHub Releases. Both routes need a Snyk account first, and an API token taken from the account page under API Token, KEY, click to show, exported before any scan:

export SNYK_TOKEN=your-api-token-here

Releases publish more than the binary itself: an SBOM named `sbom-<version>.json`, checksum files, signed checksums, and source code archives. The Makefile's clean target quietly contradicts the npm statement, because it deletes `./npm/dist` along with `./dist`, `./agent_scan/agent_scan.egg-info`, `./ame.spec` and `./agent-scan.spec`. The declared build backend is hatchling, which does not write an egg-info directory, and pyinstaller writes the spec files. Those paths are leftovers from an earlier packaging setup, and they are the clearest sign in the tree of a distribution route that was abandoned.

The ci target builds a binary and then tests the binary

The test wiring chooses its runner from a Makefile variable rather than from a flag on the pytest command. `make test` and `make tests` set `AGENT_SCAN_ENVIRONMENT=test` and run pytest with `--runner=uv`. `make coverage` reuses that and adds `--cov=src/agent_scan` with term-missing and html reports. `make ci` is different in kind: it runs `$(MAKE) binary` first, so the packaged artifact must exist before pytest starts, then sets `AGENT_SCAN_ENVIRONMENT=ci` and runs pytest with `--runner=binary`. Continuous integration therefore exercises what a user would download rather than the working tree, at the cost of making the build a precondition for the tests. pytest is configured with `testpaths = ["tests"]`, and the Makefile is declared phony across a long target list that includes `shiv`, `publish-pypi`, `publish`, `reset-uv`, and two dev server installers, one each for Cursor and Windsurf.

Two runtime dependencies are pinned exactly and eight transitives are overridden

Two runtime dependencies are frozen with an exact operator: `rich==14.2.0` and `mcp[cli]==1.28.1`. Everything else floats on a lower bound, from `pydantic>=2.11.2` and `lark>=1.1.9` through `aiohttp`, `rapidfuzz`, `detect-secrets` and `truststore`. One entry is conditional, `tomli>=2.0.0 ; python_version < '3.11'`, because the standard library TOML decoder arrived in 3.11 while `requires-python` is set to `>=3.10`. Separately, the uv configuration declares eight overrides for packages the project does not depend on directly, `click`, `python-multipart`, `pydantic-settings`, `idna`, `starlette`, `pyjwt`, `anyio` and `urllib3`, each with a floor attributed to security fixes. The comment that explains the tomli line names a Codex discoverer in `agents/codex.py`, which is the only mention of Codex anywhere in the project files.

Four scan targets and three different lists of agents

The current version's commands cover four scopes: everything on the machine, one MCP configuration, one skill file, and the Claude skills directory.

# Scan the whole machine
uvx snyk-agent-scan@latest

# Scan a specific MCP configuration
uvx snyk-agent-scan@latest ~/.vscode/mcp.json

# Scan a single agent skill
uvx snyk-agent-scan@latest ~/path/to/my/SKILL.md

# Scan all Claude skills
uvx snyk-agent-scan@latest ~/.claude/skills

The pinned v0.5.x examples repeat the same four shapes against `[email protected]`, and the two lines differ at the service end as well as the version: v0.5.x calls the `2025-09-02` analysis API where v0.6 calls the `2026-07-10` one. Both versions scan MCP servers, tools, prompts, resources and skills, and `--no-skills` turns off the skill analysis. The agent lists are less settled than the commands. The install section names Claude Code and Desktop, Cursor, Gemini CLI and Windsurf. The highlights section adds GitHub Copilot, Amp and Amazon Q. The dependency comment in the manifest names a Codex discoverer. No single place states which of these are always on.

An x86_64 standalone binary can only be built on macOS

The binary target takes an `ARCH` variable, and its x86_64 branch is guarded by an explicit refusal: when the platform string is not Darwin, the target prints `ERROR: ARCH=x86_64 is only supported on macOS (darwin)` and exits. The build then pulls the uv installer from the astral-sh release feed. Two packaging tools sit in the dev extras, `pyinstaller>=6.15.0` and `shiv>=1.0.4`, and the clean target removes a spec file for each, so both distribution shapes are wired even though one platform combination is refused. Checksums and signed checksums ship with each release, which is the verification path the project points at for standalone downloads. The repository was last pushed on 2026-10-02 and is not archived. The newest release is v0.6.8 from 2026-09-29, tagged just under twenty-four minutes after a snapshot build, `v0.6.8-snapshot-a6af81c-1751`, whose name carries a commit hash and a counter.

Editorial conclusion

Snyk Agent Scan is worth running against agent components you did not write, provided you treat the scan itself as untrusted code execution. Check three things before you wire it in. First, whether you can sandbox it, because discovering an MCP server means running it. Second, whether your pipeline can tolerate output that is declared experimental in both the old and the new format, since issue codes and risk names may change between releases. Third, which agents you actually expect to be discovered, since three sections of the project name three different agent lists. Teams evaluating the enterprise path should go through their account team rather than read CLI results as a proxy for what the platform shows.

Frequently asked questions

Official sources

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