Snyk Agent Scan: a scanner that starts your MCP servers to inspect them
Security scanner for AI agents, MCP servers and agent skills.
At a glance
- What is it?
- Agent Scan discovers MCP configs, agent skills and harnesses on a machine and sends them to Snyk's analysis API for risk scoring. The catch is that scanning a stdio MCP server means executing the command in its config, and the CLI output format is explicitly experimental.
- Who is it for?
- Adopt Agent Scan if you already hold a Snyk token and want a second opinion on MCP configs and skill files you did not write, and run it inside a container or VM because scanning a stdio server executes the command in its config. Do not adopt it if you need a stable machine-readable output contract for CI: the README states that field names, issue codes and risk names may change without notice between releases, and v0.5.x is planned for deprecation.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap Agent Scan is aimed at: components nobody inventories
Most teams can list their dependencies. Very few can list the MCP servers configured on a developer laptop, the skills sitting in ~/.claude/skills, or the tools and prompts those servers expose once they start. Agent Scan exists to close that gap. The README describes it as a tool to discover and scan agent components on your machine for prompt injections and vulnerabilities, naming agents, MCP servers and skills as the three categories. The problem it targets is not a vulnerable library version. It is natural-language content: tool descriptions, prompts, skill instructions. That content can carry a prompt injection, a malware payload written as prose, or instructions that move credentials somewhere unexpected. A conventional SCA scanner has nothing to match against here, because there is no package manifest to resolve. The audience is therefore narrow but real: security engineers and platform teams who have already allowed MCP servers onto developer machines and now need to know what those servers actually declare. It is less useful for a solo developer with one hand-written MCP config, who can read the file faster than they can install a scanner.
What happens when you point it at an MCP config
The mechanism has two halves, and the first half is the one that matters. Agent Scan walks the machine looking for supported agent configurations. The README names Claude Code, Claude Desktop, Cursor, Gemini CLI and Windsurf as auto-discovered, with Amp and Amazon Q listed among the agents it scans. For each MCP configuration it finds, it reads the server definitions. Then, for stdio servers, it starts them. The README is explicit: scanning an MCP configuration file executes the commands and arguments specified in that config, and the reason given is that this is necessary to retrieve tool descriptions and perform security analysis. In other words, the scanner cannot see what a server exposes without running it, because MCP tool descriptions are served at runtime rather than declared statically. The second half is remote. Findings are submitted to Snyk's analysis API, which is why the tool needs SNYK_TOKEN before any scan will run. The API version is tied to the CLI line: v0.5.x uses the 2025-09-02 analysis API, and v0.6 and later use 2026-07-10. That version pairing is worth noting when you pin a release, because the output shape changes with it. The v0.5.x line produces issue codes such as E001 for prompt injection and tool poisoning, E002 for tool shadowing, E004 for skill prompt injection, E006 for malware payloads, W007 for credential handling and W011 for untrusted content. The v0.6 line replaces issue codes with named risk indicators and scores.
Running it: uvx, a token, and one flag you should think twice about
There is no npm package. The README states that installation is either through uvx or as a standalone binary from GitHub Releases, which also publish an SBOM, checksums, signed checksums and source archives. The Python path assumes uv is installed. You need a Snyk account and an API token from the account page, exported before any scan runs. The README gives the export as SNYK_TOKEN=your-api-token-here. From there the invocations are short. Scanning the whole machine is uvx snyk-agent-scan@latest with no argument. Scanning one MCP configuration is uvx snyk-agent-scan@latest ~/.vscode/mcp.json. Scanning a single skill is uvx snyk-agent-scan@latest ~/path/to/my/SKILL.md, and scanning all Claude skills is uvx snyk-agent-scan@latest ~/.claude/skills. The README pins v0.5.17 as a concrete v0.5.x example, so the same commands work with uvx snyk-agent-scan@0.5.17 if you are staying on the older line. Two flags control behaviour. --no-skills disables skill analysis, which is the switch you want when you only care about MCP servers. --dangerously-run-mcp-servers skips the consent step. By default, interactive runs require a y/n confirmation before each stdio server starts, and the prompt shows the exact command and arguments that will execute. The flag name is honest about what it does. The README recommends it only in trusted environments where every MCP server command has already been verified, and recommends running scans inside a Docker container, VM or disposable environment when the configs are untrusted or third-party.
The execution model is the limitation, not a footnote
Any scanner that runs the thing it is inspecting inherits the risk of the thing it is inspecting. If a third-party MCP config points at a command that does something unpleasant on startup, Agent Scan will start it. The consent prompt is the mitigation, and it is a reasonable one for interactive use: you see the command and arguments before they run. It is not a mitigation for unattended use. The moment you wrap this in automation, the prompt either blocks or you pass --dangerously-run-mcp-servers, and at that point the sandbox is the only boundary left. That is a structural property of the approach, not a bug, but it changes where the tool belongs in a pipeline. It fits a manual or containerized review step. It fits poorly as a pre-commit hook or a CI job that runs on a shared runner with credentials attached. There is a second limitation that is more mundane and probably more annoying. The README states plainly that CLI output is experimental and subject to change, and repeats it for both lines: issue codes, field names, severity labels and response structure for v0.5.x, and risk indicator names, scores, field names and response structure for v0.6 and later. It goes further and says the project does not recommend building production workflows that depend on specific CLI output fields or risk names. For a security tool, that is an unusual admission, and it should shape how you use it. Parse the output for a human to read, not for a gate to enforce. A third constraint is scope: the scanner sees agent components on the machine it runs on. It does not know about MCP servers your colleagues configured, and it does not inventory anything deployed server-side.
Where the CLI stops and the Evo platform starts
The README draws a line that is easy to miss. Enterprise customers using Snyk to manage agent security at scale are told that the CLI output may not reflect what is sent to and shown in the Evo platform. The underlying integration, discovery and risk assessment that powers enterprise deployments is described as stable and supported, with changes communicated through standard Snyk product practices. The CLI, by contrast, is the unstable surface. Read together, those two statements say something specific about the product: the analysis pipeline is the durable part, and the local rendering of it is not. If your organisation already runs Snyk at scale, the sensible reading is that the platform is the intended consumption path and the CLI is a local convenience for inspecting one machine. If you do not have a Snyk account, the CLI is the whole product, and you are accepting an experimental output contract in exchange for a free local scan. That is a fair trade for occasional use and a poor one for anything you intend to depend on.
What it is not: a replacement for static config review
The obvious alternative for many teams is reading the MCP configuration yourself plus a general-purpose prompt-injection scanner, and the difference in approach is worth being precise about. A static review of ~/.vscode/mcp.json tells you which commands are configured and where they come from. It cannot tell you what tool descriptions those servers return at runtime, because those descriptions do not exist until the server starts. Agent Scan's decision to execute the server is what buys it that visibility, and it is the same decision that creates the sandbox requirement. A prompt-injection scanner pointed at skill files takes the opposite trade: it reads text without executing anything, which is safe on any file, but it has no view of MCP server behaviour at all. The two are complementary rather than competing. Agent Scan covers the runtime-declared surface (MCP tools, prompts, resources) and the file-based surface (skills), which is a wider net than either a config linter or a text scanner alone. What it does not do is resolve the supply chain behind those servers. It will tell you a server's tool description looks like a prompt injection; it will not tell you whether the package that server depends on has a known CVE. Those remain separate tools.
Maintenance cost and what the Apache-2.0 licence leaves open
The repository is Python, licensed Apache-2.0, not archived, and the release cadence visible in the material is high, with v0.6.3 published on 2026-09-10 and snapshot builds appearing the day before. Frequent snapshot releases alongside tagged ones usually indicate an active main branch rather than a stabilised one, which lines up with the experimental-output warning. Practically, that means pinning matters. The README's own examples pin v0.5.17 for the older line and use @latest for the current one; if you care about reproducibility you want a pinned version, and if you pin v0.5.x you are pinning a line the README says is planned for deprecation. Upgrading from v0.5.x to v0.6 is not a cosmetic change: the output model moves from issue codes to named risks with scores, and the analysis API version changes with it, so any parsing you wrote against E001 or W007 stops applying. On licensing, Apache-2.0 permits commercial use and modification and includes an explicit patent grant, which is the permissive end of the spectrum. The licence covers the code in this repository. It does not cover the Snyk analysis service the CLI calls, and it does not tell you what happens to the configuration content you submit for analysis. That is governed by your Snyk account terms, not by the Apache-2.0 text, and it is the question to settle with whoever owns your Snyk relationship before you point the scanner at a config containing internal hostnames or credentials. Nothing here is legal advice; the licence file and your Snyk agreement are the documents that decide it.
Editorial conclusion
Adopt Agent Scan if you already hold a Snyk token and want a second opinion on MCP configs and skill files you did not write, and run it inside a container or VM because scanning a stdio server executes the command in its config. Do not adopt it if you need a stable machine-readable output contract for CI: the README states that field names, issue codes and risk names may change without notice between releases, and v0.5.x is planned for deprecation. Before trusting a result, verify three things: whether the scan ran in a sandbox, which analysis API version your pinned CLI talks to (2025-09-02 for v0.5.x, 2026-07-10 for v0.6 and later), and whether your findings need to appear in the Evo platform rather than the CLI.
Community notes