Top 10 MCP security tools in 2026, from gateways to scanners

TL;DR

• MCP security is a stack, not a product. Five layers matter: a gateway that enforces identity and tool access, a scanner that reads tool descriptions for poisoning, a catalog or registry that limits which servers can be installed, endpoint discovery for servers added on laptops, and runtime guardrails on tool arguments and results.
• The MCP specification states that “tools represent arbitrary code execution,” forbids token passthrough, and admits the protocol “cannot enforce these security principles.” OWASP’s MCP Top 10, still in beta, names ten risks from token mismanagement to shadow MCP servers.
• Bifrost ranks first because it covers three of the five layers in one control plane: an MCP gateway with deny-by-default tool access per key, guardrails on tool inputs and outputs (enterprise), and Bifrost Edge, an alpha endpoint agent that inventories and blocks MCP servers on employee machines. It does not scan tool descriptions for poisoning.
• Docker MCP Gateway and Stacklok ToolHive lead on isolation of local servers. Snyk Agent Scan and Cisco’s MCP Scanner lead on detecting poisoned tools. Cloudflare is the only network-layer option that detects shadow MCP traffic by protocol header.
• No tool here stops prompt injection carried in a legitimate tool’s output. Least privilege and human approval for write actions remain the main defense.

Securing the Model Context Protocol (MCP), the open standard that lets AI agents call external tools, takes more than one product, because the risks sit in different places: in the description of a tool, in the token used to call it, in the laptop where a developer installed it, and in the text it sends back to the model. The best MCP security tools in 2026 each cover part of that surface. This comparison ranks ten of them against the risks named in the MCP specification and in OWASP’s MCP Top 10, and states which risks each one leaves open. Every capability below comes from vendor documentation, repositories or primary disclosures read in early October 2026. None of the tools were deployed or attacked for this piece.

The MCP threat model in 2026

The MCP threat model starts with one sentence from the specification: tools are code. The 2026-07-28 specification says “tools represent arbitrary code execution and must be treated with appropriate caution,” and that “descriptions of tool behavior such as annotations should be considered untrusted, unless obtained from a trusted server.” It then concedes that “MCP itself cannot enforce these security principles at the protocol level.” Enforcement is left to implementers, and to the tools in this list.

The specification’s Security Best Practices chapter names the attacks a deployment has to plan for. A few carry hard requirements:

• Token passthrough: “MCP servers MUST NOT accept any tokens that were not explicitly issued for the MCP server.”
• Confused deputy: an MCP proxy using a static OAuth client ID “MUST implement per-client consent” before forwarding to a third-party authorization server.
• Local MCP server compromise: a client offering one-click setup of a local server “MUST” show the exact command and require explicit approval; it “SHOULD” run the server in a sandbox with minimal default privileges.
• OAuth URL validation: clients “MUST NOT use shell commands” to open authorization URLs.
• Scope minimization: servers should start with a minimal scope set and elevate per operation.

OWASP’s MCP Top 10, led by Vandana Verma Sehgal and currently in “Phase 3: Beta Release and Pilot Testing,” turns these into a checklist. Its ten categories are below, because the rest of this comparison maps tools to them.

Disclosed MCP incidents

Three disclosures show why the layers are distinct. Each comes from the researchers’ own write-up.

Tool poisoning (April 2025). Invariant Labs defined tool poisoning as “malicious instructions embedded within MCP tool descriptions that are invisible to users but visible to AI models.” The same notice described a rug pull, where “a malicious server can change the tool description after the client has already approved it,” and shadowing, where one server’s description alters how the agent uses another server. Approval dialogs show a summary; the model reads everything.

Toxic agent flow through GitHub (May 2025). Invariant showed that a prompt injection planted in a public GitHub issue could lead an agent using the GitHub MCP server to leak data from the user’s private repositories. No tool was malicious. The attack used a legitimate tool’s output. Invariant’s recommended mitigation was to “limit agent access to only the repositories it needs to interact with.”

Remote code execution in mcp-remote (July 2025). JFrog disclosed CVE-2025-6514, rated CVSS 9.6, in mcp-remote versions 0.0.5 to 0.1.15. A malicious MCP server could return a crafted OAuth authorization_endpoint that the client passed unsanitized to the operating system, giving full command execution on Windows. It was fixed in 0.1.16. This is the case the specification’s rule against opening URLs through a shell addresses.

The lesson across all three: a scanner would catch the first, only least-privilege policy and output guardrails help with the second, and only patching, sandboxing and an approved-server list help with the third. Supply chain compromise of AI infrastructure is not hypothetical either; the Frontier Wire review of LiteLLM alternatives covers the March 2026 PyPI compromise of an AI gateway package.

Five layers of MCP security tooling

MCP security tools fall into five categories, and most products cover two or three of them. Knowing the categories makes vendor claims easier to test.

1. Gateways and control planes sit between MCP clients and servers. They authenticate the caller, filter which tools each caller can see and call, hold upstream credentials, and log every tools/call. The Frontier Wire comparison of MCP gateways covers this layer in depth, including OAuth flows and token exchange; this piece does not repeat it.
2. Scanners connect to MCP servers, read tool, prompt and resource descriptions, and flag poisoning, shadowing, prompt injection or dangerous capabilities. Some also read server source code or packages.
3. Registries and catalogs decide which servers may be installed at all: a curated list, signed images, verified publishers.
4. Endpoint and fleet controls find MCP servers configured on employee machines and either report or block them. This is the only layer that addresses shadow MCP, because a gateway never sees a server it is not routing.
5. Runtime guardrails inspect tool arguments before execution and tool results before they return to the model, for secrets, PII and injected instructions.

The distinction between a gateway for tools and one for models matters here too. The explainer on LLM gateways versus API gateways covers why a generic API proxy does not understand either protocol.

How the tools were chosen

Candidates were drawn from open-source projects and commercial products with public MCP security documentation in October 2026. A product had to document at least one of the five layers in enough detail to check. Tools with no public documentation of MCP-specific controls were left out. The criteria come before the ranking so readers can weight them differently.

Breadth across layers was weighted highest, because the incidents above each slipped past a single control. Bifrost’s first place rests on that breadth, and its write-up states what it does not cover.

MCP security tools at a glance

Control planes that span several layers

1. Bifrost

Bifrost is an open-source AI gateway written in Go under Apache 2.0, built by Maxim AI. It routes model traffic and MCP tool traffic in one process, so one virtual key can carry model, budget and tool permissions together. For MCP security it covers the gateway, guardrail and endpoint layers.

Gateway controls. The Bifrost MCP gateway aggregates upstream servers over STDIO, HTTP or SSE and exposes them at /mcp. Its MCP documentation states: “By default, Bifrost does NOT automatically execute tool calls.” Tool calls proposed by a model come back as suggestions; an application executes them through a separate endpoint, and an opt-in agent mode auto-runs only tools listed in tools_to_auto_execute. Tool filtering is deny-by-default: “If a Virtual Key has no specific MCP configurations, no MCP tools are available.” A request header can narrow the allowed set but never widen it, and the check runs again at execution time. Virtual MCPs bundle chosen tools into an endpoint at /mcp/<slug> that returns a 403 to any key not attached to it. Inbound, /mcp accepts virtual-key headers or an OAuth 2.1 flow with RFC 9728 discovery, RFC 7591 dynamic client registration, PKCE and RFC 8707 audience binding. These map to OWASP MCP02 and MCP07. The governance features, virtual keys, budgets and access control, apply to tools and models alike.

Guardrails on tool calls. Bifrost’s guardrail layer can run on input, output or both. The provider documentation says that for MCP the input phase “inspects arguments before tool execution” and the output phase “inspects tool results after execution,” so a poisoned result can be blocked before it reaches the model. Built-in detectors include Gitleaks-based secrets detection and custom regex; third-party providers include AWS Bedrock Guardrails, Azure Content Safety, Google Model Armor, CrowdStrike AIDR and Patronus AI. Guardrails, SSO, audit logs and clustering are in the enterprise tier.

Endpoint governance. Bifrost Edge is an endpoint agent, currently in alpha, for macOS, Windows and Linux. It routes AI traffic from desktop apps, browser AI and coding agents through the gateway, so the same keys, budgets and guardrails apply. Its MCP governance reads MCP configurations in Claude Code, Claude Desktop, Gemini CLI, OpenCode, Codex and Cursor, builds a fleet inventory, sends newly found servers to an approval queue, and enforces decisions on the device “so the disallowed tool cannot be used, even by an app that had it configured before the policy existed.” Edge guardrails such as secrets detection apply to prompts leaving the machine. Edge is distributed through MDM tools including Jamf, Intune and Kandji. This is the most direct answer in the list to OWASP MCP09, shadow servers, but as an alpha it is a pilot, not a compliance control yet.

Limits. Bifrost does not scan tool descriptions for hidden instructions or detect description changes between sessions, so tool poisoning and rug pulls need a scanner alongside it. Its allow-lists work by tool name. Guardrails and audit logs require the enterprise tier. The published benchmark of 11 µs added overhead at 5,000 requests per second on a t3.xlarge, against a mocked OpenAI upstream, is vendor-reported and measures the model path, not tool calls.

Best fit: organizations that want tool access, model access, guardrails and laptop-level MCP discovery governed by one set of keys.

2. Docker MCP Gateway and Catalog

Docker MCP Gateway is an MIT-licensed Go plugin for the Docker CLI and the engine behind Docker Desktop’s MCP Toolkit. Its strength is the isolation layer, documented in an unusually specific security model. Server containers “do not receive the user’s host environment by default,” run with no-new-privileges and CPU and memory limits, and host bind mounts default to read-only and cannot target known credential paths. Signature verification is on by default for images in Docker Hub’s mcp/ namespace, which must be referenced by digest. --block-secrets, enabled by default, “scans tool-call arguments and text responses for secret-like values before and after tool execution.” Remote MCP URLs must be public HTTPS, which blocks the SSRF patterns the specification warns about, and the gateway rejects tool names that collide with another server’s, a direct guard against shadowing.

The Docker MCP Catalog adds the registry layer: Docker-built servers are “digitally signed by Docker,” entries carry provenance and SBOM metadata, and custom catalogs let an organization “restrict which servers your organization approves for use.”

Limits. “Network egress is not globally denied by default”; --block-network and per-server allowHosts must be configured. The security model lists tool-description poisoning and prompt injection as out of scope unless they bypass a gateway boundary. Third-party images outside the mcp/ namespace are not signature-verified.

Best fit: developer workstations where local server compromise (OWASP MCP05) is the main worry.

3. Stacklok ToolHive

ToolHive is an Apache 2.0 MCP platform with three parts: a runtime that “runs every MCP server in an isolated container,” a gateway, and a registry server that integrates with the official MCP Registry and can “verify provenance and sign servers.” It runs as a desktop app, a CLI or a Kubernetes operator. ToolHive’s network isolation is on by default and routes egress through a per-server proxy limited to hosts declared in a permission profile, which goes further than Docker’s default. Authorization uses Cedar policies evaluated on every request: “If no policy matches, the request is denied.”

The open-source tier includes OIDC and OAuth, Cedar, audit logging, RFC 8693 token exchange and the registry server. Stacklok Enterprise adds Sigstore-signed packages with SBOMs, IdP group mapping, policy packs and a web console.

Limits. No documented scanning of tool descriptions for poisoning. No model gateway in the same process. Kubernetes is the path to fleet scale.

Best fit: platform teams that want default-deny egress and policy-as-code for every server they host.

Scanners for poisoning and rug pulls

4. Snyk Agent Scan

Snyk Agent Scan is the successor to MCP-Scan, the scanner Invariant Labs released in April 2025; Snyk acquired Invariant Labs in June 2025, and the old repository now redirects to Snyk’s. The CLI is Apache 2.0. It auto-discovers configurations for Claude Desktop and Code, Cursor, VS Code, GitHub Copilot, Windsurf, Gemini CLI, Codex and others, connects to each server, and scans tools, prompts, resources and agent skills. The v0.6 line scores risk indicators including prompt injection in tool descriptions, untrusted content, private data and destructive capabilities. A background mode runs on a schedule under MDM and reports to Snyk’s Evo platform, which gives it a fleet role against shadow MCP.

When it launched, MCP-Scan detected rug pulls with “Tool Pinning,” “tracking changes via tool hashing.” The current risk reference does not list a rug-pull indicator, so change detection should be confirmed for the version in use.

Limits. A Snyk API token is required, and analysis runs through Snyk’s API; the README says secrets are redacted before transmission. The README warns that scanning “can execute commands,” since starting a stdio server means running its configured command, and recommends a sandbox for untrusted configs. CLI output is labelled experimental. Detection is reporting, not enforcement.

Best fit: security teams that want a fast inventory and risk score of MCP servers and skills across developer machines.

5. Cisco AI Defense MCP Scanner

Cisco’s MCP Scanner is an Apache 2.0 Python tool, version 4.8.5 on PyPI as of 2 October 2026. It combines three engines: YARA rules, LLM-based analysis using a model the user supplies, and the commercial Cisco AI Defense inspection API. Only YARA runs without any key. It scans tools, prompts, resources and server instructions, and goes beyond descriptions: a behavioural analyzer checks MCP server source code for “mismatches between docstring claims and actual implementation,” pypi-scan and npm-scan analyse packages in a Docker sandbox, and VirusTotal lookups check bundled binaries. A static mode scans exported tool lists offline for CI pipelines and air-gapped environments, and known-configs scans the client configurations on a machine.

Limits. Reporting only; there is no proxy or enforcement. LLM analysis quality depends on the model configured and sends descriptions to that provider. No fleet mode is documented in the repository.

Best fit: pipelines that gate new MCP servers before approval, especially for supply chain review (OWASP MCP04).

Network and policy gateways

6. agentgateway

agentgateway is a Rust proxy under Apache 2.0 and a Linux Foundation project, covering LLM, MCP and agent-to-agent traffic. For security, its MCP authorization evaluates CEL expressions against MCP methods, for example jwt.sub == "test-user" && mcp.tool.name == "add", and tools that fail the check are excluded from list responses, so a caller cannot discover them. The README lists JWT, API key and OAuth authentication, rate limiting, OpenTelemetry, and guardrails using regex, OpenAI moderation, AWS Bedrock Guardrails, Google Model Armor and custom webhooks.

Limits. No scanning or endpoint component. Its Kubernetes controller assumes Gateway API familiarity.

Best fit: Kubernetes platform teams that want expression-based policy on MCP and model traffic.

7. Cloudflare MCP server portals and Gateway

Cloudflare covers two layers. MCP server portals put up to 80 servers behind one endpoint protected by Cloudflare Access, with per-portal tool curation, request logging and DLP when traffic routes through Cloudflare Gateway. The newer part is detection. In August 2026 Cloudflare announced that Gateway classifies MCP traffic by the MCP-Protocol-Version header on TLS-inspected requests, exposed as the selector experimental.is_mcp. A dashboard lists “top MCP servers seen outside your Portals,” and a rule can block any MCP request that did not arrive through a portal.

Limits. Detection needs Cloudflare’s TLS inspection and works only for traffic routed through Cloudflare; local stdio servers send no network traffic to classify. The selector is marked experimental. The portal documentation warns that users blocked from a server in the portal “can still connect to the server (and bypass your Access policies) by using its direct URL,” which is why the blocking rule matters, and that MFA is not prompted when authorizing servers through a portal.

Best fit: Cloudflare One customers who want network-level shadow MCP visibility for remote servers.

8. IBM ContextForge

ContextForge is IBM’s Apache 2.0 registry and proxy that federates MCP servers, A2A agents and REST or gRPC APIs. Its security defaults require JTI and expiry claims in tokens and disable public self-registration. Its plugin framework adds guardrails at hooks such as tool_pre_invoke and tool_post_invoke, with plugins including a PII filter, a deny list and a resource filter, and external integrations such as LlamaGuard. The README is blunt about local risk: “Never run untrusted MCP servers directly on your local filesystem.”

Limits. No server isolation of its own; it recommends a sandbox, container or microVM. A large Python and PostgreSQL deployment.

Best fit: enterprises exposing internal APIs as tools that want registry and plugin guardrails in one service.

Runtime guardrails and registries

9. Lasso MCP Gateway

Lasso Security’s MCP Gateway is an MIT-licensed Python proxy that a developer places in front of the servers in a local mcp.json. Plugins provide runtime guardrails: basic masks secrets such as GitHub tokens and AWS keys, presidio masks PII, and lasso adds prompt injection and harmful content checks through Lasso’s commercial API. A --scan mode scores server reputation from marketplace and GitHub data, scans tool descriptions for “hidden instructions, sensitive file patterns, and malicious actions,” and blocks servers below a reputation threshold of 30 by writing a blocked status into the config.

Limits. No fleet management is documented; it works on one developer’s configuration. The latest PyPI release is 1.2.1 from January 2026. The strongest checks depend on the paid API.

Best fit: individual developers or small teams who want guardrails and pre-load scanning without central infrastructure.

10. Official MCP Registry

The official MCP Registry is the protocol project’s metadata catalog for public servers, still in preview. Its security contribution is publisher verification: names follow a reverse-DNS format tied to a verified GitHub account or domain, so only the owner can publish under a namespace. That addresses the squatting and impersonation side of OWASP MCP04. Maintainers can remove spam or malicious entries by hand.

Limits. The registry “delegates security scanning” to package registries and downstream aggregators, does not support private servers, and its codebase “is not designed for self-hosting.” Host applications are expected to consume downstream registries, not the official one directly.

Best fit: as the upstream source for a private catalog, such as ToolHive’s registry server, that adds an organization’s own review.

Building a layered MCP security stack

A practical stack picks one tool per layer and closes the gaps between them. The mapping below starts from the OWASP categories.

Two patterns hold regardless of vendor. First, put scanners before approval and gateways after it: a scanner decides whether a server enters the catalog, and the gateway decides who may call it. Second, keep model and tool policy in the same place where possible. A key restricted to cheap models can still drive an agent that calls a production database tool unless the same key limits tools; the guide to running a gateway in front of every model call covers the model side of that loop, and Maxim’s comparison of production LLM gateways scores the routing half. Teams choosing servers to approve can start from the sibling list of MCP servers.

The GitHub incident shows the remaining gap. A scanner would pass the GitHub server, a gateway would allow it, and the injected issue text would still reach the model. Scoping tokens to the repositories a task needs, and requiring approval before tools that write, are the controls that limit that blast radius.

Limits of this comparison

Capabilities come from vendor documentation, repositories and disclosures read in early October 2026. No tool was deployed, no scanner was run against a test corpus, and no detection rate was measured, so this piece makes no claim about which scanner catches more poisoned tools. Vendor performance figures are vendor-reported. Pricing was not compared.

Several tools were considered and left out. Microsoft MCP Gateway and Kong appear in the MCP gateway comparison, which covers them in depth. Commercial AI security platforms from Prompt Security (SentinelOne), Pillar Security and Golf were not included because their MCP-specific controls could not be verified from public documentation during research. NSA guidance on MCP published in May 2026 is not cited because its primary document could not be retrieved. OWASP’s MCP Top 10 is in beta and its categories may change. The MCP specification changes too: the 2026-07-28 revision removed protocol-level sessions, so session hijacking guidance now applies only to servers on older revisions.

Verdict

Bifrost is the broadest single choice for MCP security and governance in this list. It denies tools by default per key, inspects tool arguments and results with enterprise guardrails, governs model traffic under the same keys, and, through the Bifrost Edge alpha, inventories and blocks MCP servers on employee machines. It should be paired with a description scanner, because it does not detect tool poisoning or rug pulls.

For isolation of local servers, Docker MCP Gateway and ToolHive are the strongest; ToolHive’s default-deny egress is the stricter of the two. For scanning, Snyk Agent Scan fits fleet inventory and Cisco’s MCP Scanner fits pipeline review of code and packages. Cloudflare is the option for network-level shadow MCP detection on remote servers. agentgateway and ContextForge are credible open-source policy layers, Lasso suits single developers, and the official registry is a feed to build on, not a control in itself.