MCP Vulnerability Scanner: Pre-Deploy and Runtime Compared

What an MCP vulnerability scanner actually does

An MCP vulnerability scanner checks Model Context Protocol servers and their tool definitions for security weaknesses. The category covers two distinct lanes.

Pre-deploy scanners examine an MCP server before an agent connects to it. They read tools/list output, validate schemas, check tool descriptions for poisoning, review dependency manifests for known CVEs, and flag suspicious patterns in tool argument shapes. The job is to catch the server-side flaws that are visible without traffic.

Runtime scanners inspect MCP traffic while the agent is using it. They scan tool-call responses for injected instructions, detect tool description changes mid-session (rug-pulls), match cross-call sequences against known attack chains, and pin the tool inventory per session. The job is to catch the behavioral and content threats that only appear in live traffic.

The two lanes catch different classes of attack and neither replaces the other. Most enterprise rollouts run both.

Tools landscape

The table covers the projects most commonly referenced when teams shop for MCP security. The categories below the table cover what’s not in the table (server-side runtime guardrails, static checklists).

What is intentionally not in the table:

• SlowMist MCP Security Checklist is a static reference document, not a scanner. Useful for review, not a tool you run.
• Vulnerable MCP Project tracks known-vulnerable servers but is not a scanner you point at your own servers.
• “Runtime guardrails inside an MCP server” (the server protecting itself) is a different lane from “runtime guardrails between the agent and the MCP server.” Cisco MCP Runtime Guardrails sits in the first lane. Pipelock sits in the second.
• Hook and supply-chain tools such as Immunity Agent are adjacent, not replacements for scanner or proxy coverage. They can block risky tool calls and package installs inside supported agent runtimes, but they do not sit between every agent process and the network.

How to read the lanes

The two lanes solve different problems.

Pre-deploy scanners are necessary, not sufficient. They catch code-level flaws, schema injection vectors, poisoned descriptions that exist at scan time, and known-vulnerable dependencies. Endor Labs analyzed 2,614 MCP implementations using static analysis alone and found path-traversal-prone file operations in 82% and code-injection-related APIs in 67%. That work is real; pre-deploy scanning closes a real gap.

The bound is what scanners cannot see: a clean tool description that returns a poisoned response, a description that changes after approval, a sequence of three calls where each individual call looks fine, or a session that talks to a tool not in the original inventory. Those threats only appear once traffic is flowing.

Runtime scanners catch what scanners cannot see at scan time. They sit on the wire, watch every tools/list, every tools/call argument, and every response, and apply the same content-detection logic to live bytes that a pre-deploy scanner applies to static code. The bound is what runtime scanners cannot see: the source-code flaw an attacker has not yet exercised, the dependency CVE in a tool the agent has not yet called.

The combined posture is pre-deploy on every approval + runtime on every session. Vendors that sell only one lane are not wrong, they are partial.

Where Pipelock fits in this landscape

Pipelock is the open-source agent-side option in the runtime lane. Specifically:

• Runtime MCP proxy that wraps any MCP server (stdio, Streamable HTTP, HTTP reverse proxy) and scans bidirectionally.
• Tool poisoning detection on tools/list responses with rug-pull description-drift detection across the session.
• Prompt injection detection on tools/call results (same 6-pass normalization that protects HTTP responses).
• DLP scanning on tools/call arguments (62 credential patterns, encoded-form coverage).
• Tool policy enforcement (allow / deny / redirect, shell-obfuscation detection on command-shaped arguments).
• Cross-call chain detection (subsequence matching against the session’s tool-call history).
• Session binding (pins the tool inventory at session start, rejects unknown tools mid-session).
• Fail-closed defaults on parse error, scanner timeout, HITL timeout, and context cancellation.

Plus a pre-deploy lane on the same project: pipelock mcp scan runs against MCP configs, tool definitions, and policy files. CI-friendly, JSON-output, exit-code-driven. Same threat patterns, same project, same release line. pipelock audit and pipelock git scan-diff cover related static surfaces (workspace directories and git-diff change sets).

The repo also ships a standalone pipelock-verifier binary at cmd/pipelock-verifier/ with subcommands for audit-packet, chain, and receipt verification (offline verification of signed action receipts and chain integrity). Release status: present on main, formal release tag pending the next Pipelock cut. The shipping pre-deploy lane is pipelock mcp scan; runtime is the MCP proxy. Use both.

Choosing between scanners

If you can only run one lane, pick the lane that matches your dominant threat. If you control the MCP servers and care about source-code flaws, run a pre-deploy scanner. If you do not control the MCP servers (Claude Desktop talking to third-party servers, IDE agents pulling from registries, hosted MCP gateways), run a runtime scanner because the source code is not yours to scan.

If you can run both, run a pre-deploy scanner in CI for the servers you ship and a runtime scanner in front of every agent that connects to MCP. Independent layers. Each catches what the other cannot see.

Open-source bias: prefer open-source in both lanes so the scanning logic is auditable. Invariant Labs MCP-Scan and Proximity in the pre-deploy lane; Pipelock in the runtime lane. Commercial tools (mcpscan.ai, NeuralTrust, Enkrypt, Cisco, Snyk, Akto) layer on top if you need enterprise reporting and managed service.

What this page does not cover

• API security generally. MCP runs over JSON-RPC, but the relevant threat model is agent-action, not API-request rate-limiting. API security tools partially overlap with MCP security but they were not built for the model-receives-instructions-from-tool-output threat.
• LLM firewall and prompt injection at the inference layer. See Open Source AI Firewall for the distinction.
• Supply chain attestations on MCP server packages. That is a sigstore / SLSA conversation that sits underneath any scanner.
• Server-side OAuth, identity, and token management. The MCP spec covers this; the scanner lane is separate.

Further reading

• MCP Security Tools: the broader scanners, proxies, and gateways comparison this scanner page sits under.
• MCP Runtime Security — depth on the runtime layer specifically.
• MCP Tool Poisoning — definitive page on the poisoning class.
• MCP Security — hub page covering threat taxonomy and rollout.
• OWASP MCP Top 10 coverage — framework crosswalk.
• Shadow MCP — discovery of unauthorized servers.
• How to Secure MCP — operator checklist.
• Pipelock — full feature list and deployment options.
• Pipelock on GitHub