Cisco DefenseClaw vs MCPProxy: Two Architectures for Securing MCP Agents

Algis Dumbris • 2026/03/25

RSAC Week and the MCP Security Moment

The MCPwned presentation at RSAC 2026 did what years of theoretical warnings could not. It put MCP security on the main stage in front of an audience that controls enterprise budgets. The demonstration showed live exploitation of tool poisoning, rug pull attacks, and cross-server data exfiltration — all using the MCP protocol exactly as designed. For anyone who has been building MCP security tooling, the reaction was both validating and overwhelming: every CISO in attendance walked out asking the same question. How do I secure the MCP deployments my teams have already shipped?

That question is driving a wave of MCP security tooling into the market. Two projects that represent fundamentally different philosophies are Cisco’s DefenseClaw and the open-source MCPProxy. Both aim to solve the same problem — securing AI agents that interact with MCP servers — but they approach it from opposite ends of the architectural spectrum. Cisco brings enterprise backing, deep integration with its security ecosystem, and a scan-at-deploy model built on NVIDIA’s OpenShell. MCPProxy takes a different path: a single Go binary with no external dependencies, runtime quarantine, and BM25-based tool discovery that works without configuration.

This is not a product review. It is an architectural comparison. Both tools make real trade-offs, and understanding those trade-offs matters more than benchmarks or feature checklists.

Cisco DefenseClaw: Enterprise-Grade Scan and Shield

DefenseClaw emerged from Cisco’s AI Defense initiative, which has been building security tooling for AI workloads since late 2025. The project leverages Cisco’s existing infrastructure — its security intelligence feeds, its enterprise policy engine, and its deep integration with network-level visibility tools — to create a comprehensive MCP security platform.

Architecture

DefenseClaw operates on a scan-at-deploy model. When an MCP server is registered within an organization’s infrastructure, DefenseClaw intercepts the server’s tool declarations and runs them through a multi-stage analysis pipeline. The first stage uses NVIDIA’s OpenShell framework for semantic analysis of tool descriptions, checking for known poisoning patterns, suspicious instruction sequences, and description anomalies that might indicate adversarial intent. The second stage cross-references tool metadata against Cisco’s Talos threat intelligence feeds, matching server identifiers, package hashes, and behavioral signatures against known-bad indicators.

The deployment architecture assumes container orchestration. DefenseClaw runs as a sidecar or gateway service within Kubernetes clusters, intercepting MCP traffic at the network level. This means it can enforce policies without modifying the MCP client or server — it operates transparently at the infrastructure layer.

Strengths

The enterprise integration is genuine and deep. Organizations already running Cisco SecureX, Umbrella, or Duo can feed DefenseClaw’s findings into their existing SIEM pipelines, correlate MCP security events with network-level telemetry, and apply organization-wide policies from a single control plane. For a CISO who needs to demonstrate compliance and audit trails, this integration is not a convenience — it is a requirement.

The NVIDIA OpenShell dependency, while adding complexity, enables sophisticated semantic analysis that goes beyond pattern matching. OpenShell can reason about the intent of tool descriptions, detect multi-step poisoning chains where individual descriptions appear benign but collectively create an attack, and adapt its detection heuristics based on the specific LLM being used by the agent.

Cisco’s threat intelligence is another genuine advantage. Talos processes billions of security events daily. When a new MCP attack pattern is discovered in the wild, DefenseClaw users benefit from updated detection signatures without deploying new code. This is the traditional enterprise security model — centralized intelligence, distributed enforcement — applied to a new attack surface.

Trade-offs

The scan-at-deploy model has an inherent temporal gap. DefenseClaw verifies tools when they are registered, but MCP servers can change their tool offerings mid-session. The rug pull attack exploits exactly this gap. DefenseClaw addresses this with periodic re-scanning, but the interval between scans creates a window of vulnerability that does not exist in a runtime quarantine model.

The NVIDIA OpenShell dependency is substantial. OpenShell requires GPU resources for its semantic analysis pipeline, which means DefenseClaw’s full capabilities are only available in environments with NVIDIA hardware or cloud GPU access. In resource-constrained deployments — edge computing, developer workstations, CI/CD pipelines — the semantic analysis degrades to simpler pattern matching.

The container orchestration requirement limits where DefenseClaw can run. It is designed for Kubernetes environments and assumes a level of infrastructure maturity that many teams deploying MCP agents do not yet have. A developer running Claude Code on their laptop with three MCP servers cannot easily add DefenseClaw to their workflow.

MCPProxy: One Binary, Zero Dependencies

MCPProxy takes the opposite architectural stance. It is a single Go binary that compiles to around 15 MB, has zero external dependencies, and can be running in under a minute. The design philosophy is that MCP security should be as easy to adopt as MCP itself — if adding security requires more infrastructure than the thing you are securing, adoption will lag behind deployment.

Architecture

MCPProxy operates as a local proxy that sits between the MCP client (Claude Desktop, Claude Code, Cursor, or any MCP-compatible client) and the upstream MCP servers. All MCP traffic flows through MCPProxy, which applies security controls at runtime rather than at deploy time.

The core security primitive is quarantine. When a new MCP server is added via mcpproxy serve followed by mcpproxy upstream add, its tools are registered but placed in quarantine. Quarantined tools are visible to the administrator but invisible to the AI agent. No tool from an unverified server can be invoked until it is explicitly approved with mcpproxy upstream approve. This is not a scan-then-trust model. It is a deny-by-default model where trust is granted manually and can be revoked at any time.

Tool discovery uses BM25 ranking rather than vector embeddings or semantic search. When an agent requests a tool by description or intent, MCPProxy scores all available (non-quarantined) tools using BM25 term-frequency scoring against the query. This approach requires no embedding model, no GPU, no external API calls, and no pre-computed index. It runs in microseconds on commodity hardware and produces surprisingly accurate results for the structured, keyword-rich domain of tool descriptions.

Each upstream MCP server runs in its own Docker container, providing process-level isolation. A compromised server cannot access the filesystem, network, or memory of other servers or the host system. This is not sandboxing as a feature — it is isolation as architecture. The containers are ephemeral, resource-limited, and monitored for anomalous behavior.

Strengths

The zero-dependency architecture means MCPProxy runs everywhere MCP runs. Developer laptops, CI/CD runners, air-gapped environments, Raspberry Pis. There is no GPU requirement, no cloud dependency, no license server, no container orchestration prerequisite. You download a binary and it works.

Runtime quarantine closes the temporal gap that scan-at-deploy models leave open. Because MCPProxy intercepts every tool invocation at runtime, a rug pull attack — where a server changes its tools mid-session — triggers immediate re-quarantine. The changed tools are blocked until re-approved. There is no scan interval, no periodic check, no window of vulnerability. The quarantine is continuous and synchronous with every MCP interaction.

BM25 discovery eliminates an entire class of infrastructure. Vector search requires an embedding model, a vector database, and careful tuning of similarity thresholds. BM25 requires nothing. For the specific domain of MCP tool descriptions — which are short, keyword-dense, and structurally consistent — BM25 performs comparably to embedding-based approaches at a fraction of the operational complexity. Tool listings are available with mcpproxy upstream list.

The Docker-per-server isolation model is simple to understand and audit. Each server gets its own container. There are no shared namespaces, no complex RBAC policies, no trust hierarchies. The blast radius of a compromised server is exactly one container.

Trade-offs

MCPProxy’s simplicity comes at the cost of enterprise features. There is no built-in SIEM integration, no centralized policy engine, no multi-tenant management console. Organizations running MCPProxy across hundreds of developer workstations need to build their own distribution and configuration management layer. The tool is designed for operators who are comfortable with CLI workflows, not for security teams that need dashboards and compliance reports.

The manual quarantine approval process does not scale to large deployments where new MCP servers are onboarded frequently. Each server requires explicit human approval, which is exactly the right security posture for high-trust environments but creates friction in fast-moving development workflows where teams add and remove MCP servers daily.

BM25, for all its practical advantages, cannot perform the semantic analysis that OpenShell enables. It will not detect a tool description that uses novel phrasing to disguise a poisoning attack, and it cannot reason about the collective intent of multiple tool descriptions that are individually benign but collectively malicious. BM25 finds tools. It does not analyze them for adversarial intent.

Honest Comparison: Where Each Excels

The difference between DefenseClaw and MCPProxy is not about which is better. It is about which architectural trade-offs match your threat model, your infrastructure, and your team.

DefenseClaw Excels When:

You are already in the Cisco ecosystem. If your organization runs SecureX, Umbrella, and Duo, DefenseClaw is not just another tool — it is a natural extension of your existing security architecture. The integration is real and it matters. Correlating MCP security events with network-level telemetry, endpoint detection, and identity management creates a security posture that no standalone tool can replicate.

You need compliance and audit trails. Regulated industries need to demonstrate that AI agent interactions are monitored, logged, and governed by enforceable policies. DefenseClaw’s enterprise policy engine and SIEM integration provide the paper trail that auditors require. MCPProxy generates logs, but transforming those logs into compliance artifacts is left as an exercise for the operator.

You have GPU infrastructure available. OpenShell’s semantic analysis is genuinely powerful when it has the resources to run. In environments with NVIDIA hardware — cloud deployments, GPU clusters, inference platforms — the additional detection capability over pattern matching is meaningful and can catch sophisticated poisoning attacks that simpler approaches miss.

You operate at enterprise scale. Hundreds of developers, dozens of MCP servers, centralized security policy. DefenseClaw’s architecture is designed for this operating model. MCPProxy’s architecture is not.

MCPProxy Excels When:

You need security today, not after a procurement cycle. MCPProxy is open source, free, and running in sixty seconds. There is no sales call, no POC approval, no infrastructure buildout. For teams that have MCP agents in production right now and need security controls right now, this matters more than any feature comparison.

You need runtime quarantine, not scan-time verification. If your threat model includes rug pulls, supply chain attacks on MCP servers, or any scenario where a server’s behavior changes after initial approval, MCPProxy’s continuous runtime quarantine is architecturally superior to periodic scanning. The quarantine is not a feature bolted on top. It is the fundamental security model.

You run in resource-constrained environments. Developer laptops, edge devices, CI/CD pipelines, air-gapped networks. MCPProxy runs anywhere a Go binary runs. No GPU, no cloud, no Kubernetes, no container orchestration.

You value transparency and auditability of the tool itself. MCPProxy is open source. You can read every line of code that sits between your AI agent and your MCP servers. You can audit the quarantine logic, the BM25 scoring algorithm, the Docker isolation configuration. For security-conscious teams, the ability to verify the security tool is as important as the security tool itself.

Defense in Depth: Use Both

The most honest recommendation is that DefenseClaw and MCPProxy address different layers of the MCP security stack, and the strongest security posture uses both.

DefenseClaw operates at the infrastructure layer — network-level interception, enterprise policy enforcement, threat intelligence integration. MCPProxy operates at the application layer — runtime quarantine, per-server isolation, zero-trust tool discovery. These layers are complementary, not competing.

Consider a deployment where DefenseClaw runs as a gateway service in the Kubernetes cluster, performing semantic analysis of tool descriptions and cross-referencing against threat intelligence feeds. MCPProxy runs on each developer’s workstation, providing runtime quarantine and Docker isolation for the MCP servers they interact with directly. The organization gets DefenseClaw’s enterprise visibility and MCPProxy’s runtime protection. A rug pull attack that slips past DefenseClaw’s scan interval is caught by MCPProxy’s continuous quarantine. A novel poisoning pattern that BM25 cannot detect is flagged by OpenShell’s semantic analysis.

This is not a theoretical architecture. It is how defense in depth has always worked. Firewalls and endpoint detection. Network IDS and host-based IDS. Perimeter security and zero-trust networking. The same principle applies to MCP security: different tools, different layers, complementary coverage.

The Market Is Splitting, and That Is Fine

RSAC 2026 will be remembered as the week MCP security went from a niche concern to a board-level priority. The MCPwned presentation did not create the demand — the vulnerabilities were already being exploited in production — but it concentrated the demand into a moment that vendors and open-source projects alike are racing to address.

The market is splitting along a familiar axis. Enterprise vendors like Cisco are building integrated security platforms that extend their existing products into the MCP domain. Open-source projects like MCPProxy are building focused tools that solve specific security problems with minimal dependencies. This is not a winner-take-all market. It is a layered security stack where both approaches have a clear role.

For enterprise teams evaluating MCP security: start with MCPProxy to get runtime quarantine and Docker isolation in place today. It is free, it takes minutes to deploy, and it closes the most critical vulnerability window — the gap between when a server is deployed and when it is verified. Then evaluate DefenseClaw for the infrastructure-level integration, policy management, and threat intelligence that enterprise operations require.

For developer teams and open-source projects: MCPProxy is built for you. Single binary, zero dependencies, runtime quarantine, and full source code transparency. Add it to your MCP workflow the same way you would add a linter to your code pipeline — as a non-negotiable quality gate that catches problems before they reach production.

The MCP protocol is not going to become more secure by itself. The attack classes — tool poisoning, rug pulls, sampling abuse — are architectural consequences of design decisions that are now deeply embedded in the ecosystem. The security has to come from the tooling layer. Whether that tooling is enterprise-backed or open-source, scan-at-deploy or quarantine-at-runtime, the important thing is that it exists and that teams deploy it before the next wave of exploits arrives.

It is already arriving.