MCP Security Scanners Guide: How They Work and How to Run Them Safely

Developers add MCP servers and agent skills faster than security teams can review them, and most of the risk sits in text and code that ordinary vulnerability scanners never read. MCP security scanners fill part of that gap: they discover the servers and skills configured on a machine, pull tool descriptions, prompts and resources, and look for prompt injection, tool poisoning, cross-server shadowing, risky capabilities and known-vulnerable dependencies. They also start servers, send data to analysis services and need their own API keys, so running them carelessly creates new risk. This guide explains what these scanners check, how four open source scanners work, how to run them safely on laptops and in CI, and where they stop being useful. It is for AppSec, platform and detection teams responsible for agent tooling. Scanners are listed alphabetically; order is not a ranking.

This is an independent guide from NHI Mgmt Group, based on the public documentation of Cisco AI Defense MCP Scanner, MCP-Shield, Nova Proximity and Snyk Agent Scan as of November 2026. It is not sponsored or reviewed by any of these projects or their publishers. Features change quickly, so confirm options against each project's current documentation.

Key takeaways

• Scanners read what agents read. They analyse tool names, descriptions, prompts, resources and skill files, which is where tool poisoning and indirect prompt injection live.
• Scanning can execute code. To list a stdio server's tools, a scanner starts the server command from the configuration; Snyk's documentation says plainly that scans can execute commands or make outbound requests, so scan untrusted configurations in a sandbox.
• Know where your data goes. Several scanners send tool descriptions, configurations or skill content to a vendor analysis API or a large language model provider; decide this before fleet-wide use.
• A clean scan is a point in time. Descriptions can change after approval and malicious behaviour can sit in code that a description scan never sees, as the postmark-mcp case showed.
• Scanners feed governance, not replace it. Use results to drive an MCP inventory, an allowlist and pinned versions, and pair them with gateway and runtime controls.

What MCP security scanners check

An MCP scanner works at a different layer from a software composition analysis tool. It treats the natural language an agent consumes as an attack surface. The checks map to threats named in the MCP specification's Security Best Practices page, the OWASP Top 10 for LLM Applications 2025 and MITRE ATLAS.

Background on the threats themselves is in the Top 10 MCP Security Risks and the MCP Security Guide. Manual and protocol-level testing is in the MCP Security Testing Guide; this page covers the automated scanners that sit beside it.

How scanners work

1. Discover: read known configuration locations for agent clients (for example Claude Desktop, Claude Code, Cursor, VS Code, Windsurf and Gemini CLI) or take a configuration file, server URL or skill path supplied by the user.
2. Connect: start each stdio server from its configured command, or connect to remote servers over HTTP with any configured headers or OAuth, then call the listing methods for tools, prompts and resources.
3. Analyse: apply local rules (YARA, pattern rules), send content to a large language model for judgement, or send it to a vendor analysis API.
4. Report: produce findings per server, tool or skill, often with a severity or score and a machine-readable format for CI.

Steps 2 and 3 carry the risk. Starting a stdio server runs whatever command the configuration holds, with the scanning user's rights. Sending content to an external service moves configuration data, which can include internal URLs and server names, outside your boundary.

Four open source scanners

Each scanner is described from its own documentation with the same headings. The descriptions are not a comparison; choose by the checks, data handling and workflow you need.

Cisco AI Defense MCP Scanner

• Scope: MCP tools, prompts, resources and server instructions, plus source code of MCP servers (behavioural code scanning).
• Engines: YARA rules, LLM-based analysis and the Cisco AI Defense inspect API, usable together or independently through --analyzers; further analysers cover vulnerable Python packages through pip-audit and bundled binaries through VirusTotal hash lookups.
• Modes: CLI or REST API server; live scans of known client configurations (--scan-known-configs), a stdio command or a server URL; and a static mode that scans pre-generated JSON offline for CI and air-gapped use.
• Data handling: the YARA engine runs locally; the API and LLM engines need keys (MCP_SCANNER_API_KEY, MCP_SCANNER_LLM_API_KEY) and send content to the configured endpoint, which can be a self-hosted model endpoint.
• Licence: Apache 2.0.

MCP-Shield

• Scope: installed MCP servers found in standard configuration locations or a supplied path.
• Checks: tool poisoning, hidden instructions, sensitive file access, exfiltration channels in parameters and cross-origin escalation (shadowing) between servers.
• Bait-and-switch testing: --identify-as connects under a different client name to see whether a server behaves differently for different clients.
• Data handling: pattern checks run locally; an optional Anthropic API key adds model-based analysis of the descriptions. --safe-list excludes named servers from scanning.
• Licence: MIT.

Nova Proximity

• Scope: MCP servers (tools, prompts and resources with parameters) and agent skills, including Streamable HTTP servers under the 2025-11-25 MCP specification.
• Checks: NOVA rules, which combine pattern matching with model evaluation, and remediation guidance per finding pattern; you can write your own rule files.
• Modes: a Python CLI that takes a server URL for MCP discovery, -n with a rule file (-r) for security analysis, and --skill for a skill directory.
• Data handling: model evaluation uses a key for OpenAI, Groq, Anthropic or Azure OpenAI, or a local Ollama host, so analysis can stay on your own infrastructure.
• Licence: GPL v3 according to the project README.

Snyk Agent Scan

• Scope: agent harnesses, MCP servers and skills, auto-discovered across many clients at system, user, project and extension scope. It was first published by Invariant Labs as MCP-Scan.
• Checks: from version 0.6, scored risk indicators such as prompt_injection_tool_desc, untrusted_content, private_data and destructive_capabilities for servers, plus skill risks including malicious code, suspicious downloads and secret detection. Scores are 100, 300, 600 and 1000 for low to critical.
• Safety controls: interactive runs ask for consent before contacting each server; non-interactive runs inspect remote servers but do not start stdio servers unless --dangerously-run-mcp-servers is set; remote requests refuse link-local and cloud metadata addresses and do not follow redirects.
• Data handling: requires a SNYK_TOKEN; component information, including server configurations, tool names and descriptions and skill content, is sent to the Agent Scan API with secrets redacted. An inspect subcommand lists components without analysis.
• CI: --ci exits non-zero on findings and --json emits results; the project marks CLI output as experimental. Standalone binaries ship with an SBOM and GPG-signed checksums.
• Licence: Apache 2.0 licence file; use is also subject to Snyk's terms for Agent Scan.

Choosing a scanner for the job

Small teams can run one scanner by hand when adding a server and again before upgrades. Large organisations should schedule fleet scans through endpoint management, send results to a central store, and tie each finding to the MCP Server Inventory Template and an approval workflow.

Running scanners safely

1. Agree data handling first. Record which engines send content off the machine, to whom, and under which terms. For sensitive environments use local rules or a self-hosted model endpoint.
2. Treat scanner keys as secrets. SNYK_TOKEN, MCP_SCANNER_API_KEY, LLM provider keys and VirusTotal keys belong in a secrets manager or CI secret store, scoped to the scanning job, never in shared shell profiles. See the Secrets Management Guide.
3. Sandbox untrusted configurations. Scan third-party or unknown configurations in a disposable container or VM with no access to real credentials, matching the MCP specification's advice to run local servers with minimal privileges.
4. Verify the scanner itself. Pin scanner versions, verify release checksums where the project publishes them, and review changes before upgrading, since the scanner runs with the same access as the developer.
5. Pilot, then widen. Run on a small group of developer machines in report-only mode, review findings with the server owners, and tune suppressions before enforcing anything.
6. Enforce in rings. Move from report-only to blocking in CI for new servers first, then to blocking upgrades with new critical findings, then to fleet policy.
7. Roll back cleanly. Keep blocking rules in version control. If a scanner update floods teams with new findings, pin the previous scanner version and re-baseline rather than disabling scanning.

Where identity fits

Many findings are really identity findings. A tool that "reads credentials" usually holds an API key or OAuth token with more scope than it needs, and a poisoned description often aims to make the agent pass a secret such as an SSH key or a cloud credential to an attacker-controlled parameter. Use scanner output to find servers holding long-lived tokens, move them to scoped, short-lived credentials, and record each server's identity in your inventory. The MCP Authorisation Specification Guide covers token handling, and the Agent Skills Security Guide covers skills.

Detection and measurement

• Coverage: percentage of managed developer machines and CI pipelines scanned in the last 30 days.
• Inventory match: share of discovered MCP servers and skills that are in the approved inventory (target 100%).
• Critical findings open: count and age of critical or high findings, with a target time to remove or fix.
• Drift: number of servers whose tool descriptions changed since approval, detected by comparing scans.
• Pinned versions: share of approved servers pinned to a reviewed version.

Scanner results are one signal. Pair them with runtime logging from an MCP gateway or client audit logs to see what tools were actually called. See the MCP Gateway and MCP Server Governance Guide.

Framework mapping

Common failure patterns

• Scan once, trust forever: approving a server on a clean scan and allowing automatic upgrades. The postmark-mcp malicious server case had 15 legitimate releases before one added a single line that copied every email to an attacker, a change in code rather than in tool descriptions.
• Running scans with real credentials: scanning an unknown configuration on a developer's own machine, so the scan itself starts a malicious server with access to their keys and files.
• Uncontrolled data sharing: enabling cloud analysis across the fleet without checking what content is sent, including internal server names and URLs.
• Building on unstable output: wiring CI gates to field names that a project marks as experimental, so an update silently breaks the gate.
• Ignoring skills and extensions: scanning only user-level MCP configuration and missing project, extension and skill components.
• Findings without owners: producing reports with no path to remove, pin or re-scope a server.

Practitioner checklist

• Pick a scanner per use case (fleet, CI, code review) and record its data handling.
• Store scanner and model API keys in a secrets manager scoped to the scan job.
• Scan untrusted configurations only in a disposable sandbox without real credentials.
• Pin and verify scanner versions before rollout.
• Scan every new MCP server and skill before approval, and every upgrade before it is allowed.
• Store scan results centrally and compare them to detect description drift.
• Link findings to the MCP server inventory with a named owner.
• Pin approved servers to reviewed versions and block unreviewed upgrades.
• Pair scanning with gateway or client logging of actual tool calls.

Standards and references

• Model Context Protocol: Security Best Practices (specification 2025-11-25)
• OWASP: Top 10 for LLM Applications 2025
• MITRE ATLAS: AI Agent Tool Poisoning
• NIST: SP 800-53 Rev. 5
• Cisco AI Defense: MCP Scanner documentation
• MCP-Shield: Project documentation
• Nova Proximity: Project documentation
• Snyk: Agent Scan documentation

Related NHI Mgmt Group resources: MCP Security Testing Guide · How to audit MCP servers on developer laptops · MCP Server Trust Assessment · Local MCP Server Security Guide · Unsanctioned AI Agents and MCP Servers Guide