What are the actual MCP security tools worth running?

Three categories, one each. For scanning, Cisco MCP Scanner is open source and does semantic analysis of tool definitions rather than pattern matching alone; mcp-scan from Invariant Labs, now Snyk, is the original and covers tool poisoning and rug pulls. For runtime enforcement, Solo.io agentgateway is the strongest open-source option, with Docker MCP Gateway good where servers run as containers and signature verification matters. For provenance, the official MCP Registry with namespace verification, plus the Docker MCP Catalog for signed SBOMs. A scanner alone leaves runtime uncovered, which is the most common gap.

Can an MCP gateway stop the STDIO remote code execution issue?

No. The CSA and OX Security finding, confirmed by Anthropic as intentional behavior, is that any process command passed to the STDIO interface executes on the host. That is local process execution on the machine running the MCP client. It never crosses the network, so no HTTP gateway, proxy, or firewall observes it. The controls that address it are workstation controls: sandboxing tool execution, restricting which servers can be configured, and MCP Defender or similar local proxies. What a network gateway covers is the consequence, since a compromised local agent that exfiltrates data or calls a model produces HTTP traffic.

What does the NSA recommend for MCP security?

The June 2026 Cybersecurity Information Sheet from the NSA's Artificial Intelligence Security Center names five actions: define trust boundaries, sandbox tool execution, sign and verify messages, filter chained outputs, and log all tool and model invocations. Its problem list calls out weak access controls, open-ended serialization, poor approval workflows, token-lifecycle gaps, limited audit logging, and denial-of-service patterns. Two of the five recommendations, message signing and invocation logging, describe a per-decision audit record, which is a runtime property rather than something a scanner produces.

What is tool poisoning, and how common is it?

Tool poisoning embeds malicious instructions in a tool's metadata, its description or input schema, at registration time. The user never sees the metadata. The model always reads it. Invariant Labs demonstrated the first proof of concept, showing a malicious tool on a secondary MCP server silently changing the recipient and content of messages sent by a different, trusted tool. MCPTox benchmarked it against 45 authentic MCP servers, 353 real tools, and 20 LLM agents, measuring attack success rates up to 72% and concluding that safety alignment offers minimal pre-execution protection.

Does the MCP specification require authorization?

Yes, and specifically. The 2025-06-18 revision classifies MCP servers as OAuth 2.1 resource servers. PKCE with SHA-256 is mandatory. RFC 8707 resource indicators are mandatory, so a client must declare the intended audience and a malicious server cannot replay the token elsewhere. RFC 9728 protected resource metadata is required for discovery. The spec explicitly forbids token passthrough: servers MUST NOT accept tokens that were not issued for them, and MUST NOT use sessions for authentication.

How do I audit which MCP tools my agents have actually called?

Not from the MCP server, which is the party you are auditing. The record has to come from a layer the traffic passes through and the agent has no write access to. Practically that means an enforcement point in front of the remote MCP servers that commits a signed record per tools/call, carrying the originating human principal, the tool name, the argument classification, the policy version, and the outcome. This is the self-attestation problem applied to agents: an agent that misbehaves cannot be the source of truth about what it did.

← Blog

July 13, 2026

Best MCP Security Tools: Scanners, Gateways, and Registries Worth Running in 2026

The NSA published an MCP security information sheet in June 2026 calling out limited audit logging and weak access controls. The Cloud Security Alliance documented a design-level RCE across every official MCP SDK. MCPTox measured tool-poisoning success rates up to 72% against real servers. This piece sorts the MCP security tooling that actually exists into scanners, gateways, and registries, names what each one covers, and marks which failure modes no HTTP control can reach.

ByParminder Singh· Founder & CEO, DeepInspect Inc.

Comparisons & Alternativesai-securityagentic-aillm-securityarchitectureidentity-and-authorizationcybersecurity

Best MCP Security Tools: Scanners, Gateways, and Registries Worth Running in 2026

The NSA's Artificial Intelligence Security Center published a Cybersecurity Information Sheet on Model Context Protocol in June 2026. Its list of problems reads like a design review: weak access controls, open-ended serialization, poor approval workflows, token-lifecycle gaps, and limited audit logging. Its recommendations are equally specific: define trust boundaries, sandbox tool execution, sign and verify messages, filter chained outputs, and log all tool and model invocations. Two months earlier the Cloud Security Alliance published MCP by Design, documenting OX Security's finding of a design-level remote code execution path across every officially supported MCP SDK, which Anthropic confirmed as intentional behavior of the STDIO interface.

I want to walk through the tools that exist to address this, sorted by what they actually do, and mark clearly which parts of the MCP threat surface no network control reaches.

The three tool categories

MCP security tooling splits cleanly. Scanners inspect servers and tool definitions before or outside runtime. Gateways sit in the traffic path and enforce at call time. Registries establish provenance before installation. Most deployments need one of each, and the common mistake is buying a scanner and believing runtime is covered.

Scanners and static analysis

mcp-scan (Invariant Labs, now Snyk). The original. It reads MCP config files, connects to servers, pulls tool descriptions, and analyzes them for tool poisoning, MCP rug pulls, and cross-origin escalation. Invariant Labs, an ETH Zurich spin-off, coined both "tool poisoning" and "MCP rug pull" and was acquired by Snyk on June 24, 2025. It also has a mcp-scan proxy runtime mode that injects a local gateway to intercept live MCP traffic and apply guardrails entirely on the local machine. Caution before you standardize on it: the tooling appears to be migrating to snyk/agent-scan, distributed as snyk-agent-scan. Check which repository is canonical before pinning it in CI.

Cisco MCP Scanner (github.com/cisco-ai-defense/mcp-scanner). Open source, announced October 2025. Its distinguishing property is contextual and semantic analysis of tool definitions, descriptions, and implementations rather than pattern matching alone. Three engines that run together or independently: YARA rules, an LLM-as-judge, and Cisco AI Defense. Targets tool poisoning, rug pulls, and over-privileged tool permissions.

MCP-Shield (github.com/riseandignite/mcp-shield). Scans installed servers for hidden instructions, tool shadowing, behavior modification, exfiltration channels, and cross-origin violations. Worth a correction that several roundups get wrong: this is the work of an independent developer, Nikita Kryzhanouski, inspired by Invariant's research rather than produced by them.

MCP Defender (mcpdefender.com, AGPL-3.0). A desktop application that proxies MCP traffic from Cursor, Claude, VS Code, and Windsurf, checks tool call requests and responses against signatures, and prompts allow or block. It is a local control on a developer workstation, which is exactly why it covers a threat that network tooling never sees, and exactly why it covers nothing about your production agent fleet.

Gateways and proxies

Docker MCP Gateway (github.com/docker/mcp-gateway). Runs MCP servers as containers behind a single gateway and acts as the enforcement point between agents and tools. Pairs with the Docker MCP Catalog of verified servers. The property worth having is runtime signature verification, backed by build attestations and signed SBOMs.

IBM ContextForge (github.com/IBM/mcp-context-forge, Apache 2.0). A gateway, registry, and proxy that federates MCP, A2A, and REST or gRPC behind one endpoint. Protocol conversion across STDIO, SSE, and Streamable HTTP, virtual MCP server composition, rate limiting, auth, 40-plus plugins, and OpenTelemetry tracing. Python and FastAPI, at 1.0 beta.

Solo.io agentgateway (agentgateway.dev). Rust, Apache 2.0, contributed to the Linux Foundation in August 2025. Native MCP OAuth 2.1, tool-level RBAC, secure token exchange, global rate limits across every MCP server, and sandboxing of backend URLs an MCP server dynamically requests. The strongest open-source runtime enforcement point for MCP traffic today.

Lasso Security MCP Gateway (lasso.security). MIT-licensed, security-first, with a plugin architecture covering real-time scanning, token masking, guardrails, and threat detection.

Envoy AI Gateway. Its 1.0 release in June 2026 added an MCP gateway that multiplexes multiple servers behind one endpoint, with CEL-based per-tool authorization where tools/list applies the same rules as tools/call, and JWT claim projection to MCP backends. Worth noting because it means MCP authorization is now a first-class feature of a mainstream CNCF-ecosystem data plane.

MintMCP and TrueFoundry both ship commercial MCP gateways. Both also publish the "best MCP security tools" roundups that rank for this query. Read their competitor comparisons as marketing.

Registries and provenance

The official MCP Registry enforces namespace ownership verification. An io.github.<user>/... namespace requires GitHub OAuth as that user. A custom domain namespace requires a DNS TXT or HTTP challenge. Before installing anything, read four fields: is the namespace verified, does the repository show recent commits, where do the listed remotes and packages actually send data, and what does _meta say about active or deprecated status. The registry has been in preview since September 2025.

The Docker MCP Catalog curates verified servers with signed SBOMs and build attestations. Cisco AI Defense ships an MCP server catalog that discovers and inventories servers across public and private registries.

Provenance matters more here than in most package ecosystems, and the postmark-mcp incident is why. In September 2025 an npm package cloning the official Postmark MCP server shipped fifteen clean versions to build trust, then added a single line in version 1.0.16 that BCC'd every processed email to an attacker-controlled address. Koi Security estimated roughly 300 organizations affected. MITRE tracks it as ATLAS case study AML.CS0053.

Commercial platforms with MCP coverage

Palo Alto Networks Prisma AIRS added agent artifact scanning in March 2026, analyzing agent code, MCP servers, and skills for unsafe permissions and indirect injection paths. Cisco AI Defense does runtime protection across MCP requests and responses. Snyk owns Invariant Labs and ships agent-scan. Zenity auto-discovers MCP servers across the enterprise and maps each to agents and owners. Wiz and Noma Security both do discovery and posture across models, agents, and MCP servers.

What no HTTP control reaches, stated plainly

This is where most MCP security content quietly overclaims, so let me be direct about the boundary.

Outside the reach of any network gateway:

The CSA and OX Security STDIO finding. Any process command passed to the STDIO interface executes on the host. This is local process execution. It never crosses the network, and no proxy sees it.
Local MCP server compromise, and the credential theft that follows from it.
The installation step of a supply-chain attack. When a developer runs npm install on a poisoned package, that happens at build time on a workstation.
Escape-to-host from a locally running agent.

Inside the reach of a gateway:

MCP over Streamable HTTP between authenticated agents and remote servers.
OAuth 2.1 authorization, RFC 9728 protected resource metadata, and RFC 8707 resource indicators, which the MCP spec makes mandatory to stop token misuse.
Per-tool-call authorization: which principal may invoke which tool with which arguments.
The audit record of every tool and model invocation, which is precisely what the NSA information sheet asks for.
The runtime consequence of every attack in the first list. A poisoned tool that causes an agent to exfiltrate data has to send that data somewhere, and the send is an HTTP request.

The most important development is not a tool

Enterprise-Managed Authorization became stable on June 18, 2026, with Anthropic, Microsoft, and Okta as adopters. EMA introduces ID-JAG, a short-lived identity assertion JWT issued by the enterprise identity provider through RFC 8693 token exchange after validating the user's SSO identity against organizational policy. It lets an enterprise decide which MCP servers employees may reach, and it removes the per-server OAuth consent dance entirely.

Read what that concedes. The protocol's answer to MCP security in 2026 is that a verified human identity must bind to the agent's call. That is the same position I have argued from the gateway side in MCP OAuth authorization security and MCP server authorization patterns. A scanner cannot enforce it. Only something in the traffic path can.

DeepInspect

This is exactly what DeepInspect does. DeepInspect sits inline between authenticated users and agents and the remote MCP servers and models they call. For every tools/call, it evaluates the natural-person identity the application supplies, the tool being invoked, the arguments and their data classification, and the policy version active at that moment, then passes or blocks before the call reaches the server. The decision is deterministic and fail-closed.

The second property is the one the NSA sheet asks for by name. Every tool and model invocation produces a per-decision audit record, signed, bound to the originating principal rather than to the agent's service credential, and committed before the response returns. When a tool turns out to have been poisoned three weeks after the fact, the record answers which principals reached it, what arguments they sent, what came back, and what policy was active at each call. Scanners tell you a server is dangerous now. The audit record tells you what it already did.

The boundary is honest and worth repeating: STDIO execution, local host compromise, and package installation sit outside what a proxy sees. DeepInspect is the compensating control on the outcome, not a control on the local vector.

If you are running remote MCP servers against regulated data, let's talk today.

Frequently asked questions

What are the actual MCP security tools worth running?: Three categories, one each. For scanning, Cisco MCP Scanner is open source and does semantic analysis of tool definitions rather than pattern matching alone; mcp-scan from Invariant Labs, now Snyk, is the original and covers tool poisoning and rug pulls. For runtime enforcement, Solo.io agentgateway is the strongest open-source option, with Docker MCP Gateway good where servers run as containers and signature verification matters. For provenance, the official MCP Registry with namespace verification, plus the Docker MCP Catalog for signed SBOMs. A scanner alone leaves runtime uncovered, which is the most common gap.
Can an MCP gateway stop the STDIO remote code execution issue?: No. The CSA and OX Security finding, confirmed by Anthropic as intentional behavior, is that any process command passed to the STDIO interface executes on the host. That is local process execution on the machine running the MCP client. It never crosses the network, so no HTTP gateway, proxy, or firewall observes it. The controls that address it are workstation controls: sandboxing tool execution, restricting which servers can be configured, and MCP Defender or similar local proxies. What a network gateway covers is the consequence, since a compromised local agent that exfiltrates data or calls a model produces HTTP traffic.
What does the NSA recommend for MCP security?: The June 2026 Cybersecurity Information Sheet from the NSA's Artificial Intelligence Security Center names five actions: define trust boundaries, sandbox tool execution, sign and verify messages, filter chained outputs, and log all tool and model invocations. Its problem list calls out weak access controls, open-ended serialization, poor approval workflows, token-lifecycle gaps, limited audit logging, and denial-of-service patterns. Two of the five recommendations, message signing and invocation logging, describe a per-decision audit record, which is a runtime property rather than something a scanner produces.
What is tool poisoning, and how common is it?: Tool poisoning embeds malicious instructions in a tool's metadata, its description or input schema, at registration time. The user never sees the metadata. The model always reads it. Invariant Labs demonstrated the first proof of concept, showing a malicious tool on a secondary MCP server silently changing the recipient and content of messages sent by a different, trusted tool. MCPTox benchmarked it against 45 authentic MCP servers, 353 real tools, and 20 LLM agents, measuring attack success rates up to 72% and concluding that safety alignment offers minimal pre-execution protection.
Does the MCP specification require authorization?: Yes, and specifically. The 2025-06-18 revision classifies MCP servers as OAuth 2.1 resource servers. PKCE with SHA-256 is mandatory. RFC 8707 resource indicators are mandatory, so a client must declare the intended audience and a malicious server cannot replay the token elsewhere. RFC 9728 protected resource metadata is required for discovery. The spec explicitly forbids token passthrough: servers MUST NOT accept tokens that were not issued for them, and MUST NOT use sessions for authentication.
How do I audit which MCP tools my agents have actually called?: Not from the MCP server, which is the party you are auditing. The record has to come from a layer the traffic passes through and the agent has no write access to. Practically that means an enforcement point in front of the remote MCP servers that commits a signed record per tools/call, carrying the originating human principal, the tool name, the argument classification, the policy version, and the outcome. This is the self-attestation problem applied to agents: an agent that misbehaves cannot be the source of truth about what it did.

← All posts