Gartner Says Deploy MCP Proxies — Here Is What We Built and What We Learned

Algis Dumbris • 2026/03/20

The Gartner Moment

Gartner now recommends that organizations “deploy AI/API gateways or MCP proxies to mediate traffic, enforce policies and monitor agent behavior continuously.” That sentence, buried in their latest guidance on agentic AI infrastructure, marks a turning point. MCP gateways are no longer an engineering curiosity — they are an analyst-endorsed enterprise requirement.

The numbers behind the recommendation are staggering. Gartner projects that 40% of enterprise applications will incorporate AI agents by the end of 2026. At the same time, 75% of API gateway vendors are adding MCP-specific features to their products. The protocol that Anthropic introduced in late 2024 has become the de facto standard for agent-to-tool communication, and every organization scaling AI agent deployments now faces the same question: what sits between your agents and the tools they call?

The answer, increasingly, is an MCP gateway. But the term covers a widening range of architectures, threat models, and deployment philosophies. Over the past year, we built MCPProxy — an open-source MCP gateway focused on intelligent tool discovery and security quarantine. Along the way, we studied every serious competitor in the space. This post is an honest assessment of the landscape: what each project does well, where MCPProxy fits, and what the entire category still gets wrong.

The MCP Gateway Landscape in 2026

The market has moved fast. A year ago, you could count MCP gateways on one hand. Today, the awesome-mcp-gateways list tracks over 40 projects. Five stand out as architecturally distinct approaches to the same problem.

Traefik Hub: TBAC Policies

Traefik Hub extended its established reverse proxy with what they call Tool-Based Access Control (TBAC). Rather than applying coarse network-level policies, TBAC lets platform teams write fine-grained rules at the individual tool level — specifying which agents can invoke which tools, under what conditions, with what rate limits. It integrates with Traefik’s existing middleware stack, so teams already running Traefik for HTTP routing can add MCP governance without introducing a new data plane.

The strength is operational maturity. Traefik has years of production deployment behind it, battle-tested load balancing, and a large community. The limitation is that TBAC is a policy layer, not a discovery or security scanning layer. It assumes you already know which tools exist and which ones are safe. It does not help you answer either question.

PointGuard: Integrated DLP

PointGuard AI positions itself as “the first AI security platform with a fully integrated MCP Gateway.” Their pitch centers on zero-trust authorization evaluated at the individual tool-call level, combined with AI-native data loss prevention that masks or redacts sensitive data in agent responses. They also emphasize intent-based policies that separate read, write, and update operations per agent — a granularity that most gateways do not offer.

PointGuard coined the term “shadow MCP” to describe unmonitored agents operating outside centralized governance — a real problem in enterprises where developers spin up MCP servers without security review. Their DLP capabilities are genuinely differentiated. The tradeoff is that PointGuard is a commercial platform, not open-source. You are buying a product, not deploying a tool.

Gravitee: API Management Meets MCP

Gravitee 4.10 introduced an MCP proxy that treats the Model Context Protocol as a first-class citizen alongside REST and GraphQL. Their approach brings traditional API management capabilities to the MCP world: method-level analytics tracking which tools are called and how often, intelligent caching of repeatable MCP operations like tool listings and metadata, and rate limiting with context awareness that applies controls based on MCP method behavior rather than generic traffic patterns.

Gravitee also implements the formal MCP authorization specification, handling authentication redirects and user consent flows at the gateway level so individual MCP server developers do not have to. For organizations already running Gravitee for API governance, adding MCP support is a configuration change, not a new platform. The limitation is the same as any heavyweight API management solution: significant operational complexity for teams that just need a proxy.

agentgateway: Linux Foundation Neutrality

agentgateway is an open-source data plane built in Rust under the Linux Foundation. It supports both MCP and Google’s Agent-to-Agent (A2A) protocol, making it the only gateway in this list with multi-protocol interoperability. Key features include RBAC designed specifically for MCP/A2A, multi-tenancy with isolated resource management, dynamic configuration via the xDS protocol, and API transformation that converts legacy OpenAPI endpoints into MCP-compatible resources.

The Linux Foundation governance is a meaningful differentiator for enterprises that need vendor neutrality. With 2.1K GitHub stars, 1,400+ commits, and 118 contributors, the project has real community momentum. The Kubernetes-native design with Gateway API integration makes it a natural fit for platform engineering teams. The tradeoff is that agentgateway focuses on routing, access control, and protocol bridging — it does not perform security analysis of tool schemas or provide tool discovery ranking.

MCPProxy: BM25 Discovery and Quarantine

MCPProxy takes a different approach. Instead of starting from network infrastructure and adding MCP awareness, we started from the agent’s perspective: how does an agent find the right tool among hundreds, and how do you prevent a malicious tool from reaching the agent in the first place?

The answer is two mechanisms that no other gateway provides.

What MCPProxy Brings to the Table

BM25 Tool Discovery

When an agent connects through MCPProxy to 15 upstream MCP servers exposing 200+ tools, the BM25 ranking engine scores every tool against the current query and presents only the top-K most relevant results. This solves two problems simultaneously.

First, usability. Research shows agents make significantly better tool selections from focused lists. Presenting 200 tools and hoping the LLM picks the right one is wasteful — it burns tokens on irrelevant schemas, increases latency, and degrades selection accuracy. MCPProxy’s BM25 scoring achieves roughly 99% token reduction while improving accuracy by 43%.

Second, security. Tools that are not visible to the agent cannot be invoked. If a compromised MCP server registers a tool designed to exfiltrate data, that tool only reaches the agent when the BM25 scoring determines it is relevant to the current query. For most queries, it will not be. This does not eliminate the threat — a targeted query could still surface it — but it reduces the attack window from “always available” to “relevant-query-only.”

This approach is fundamentally different from what the other gateways offer. Traefik’s TBAC controls which tools an agent is allowed to call. MCPProxy’s BM25 controls which tools an agent knows about. Both layers are valuable, and they compose well.

Quarantine-by-Default

When a new MCP server connects to MCPProxy, its tool definitions do not go straight into the available tool pool. They enter quarantine. The quarantine system analyzes each tool’s name, description, and parameter schema for known attack patterns:

• Hidden instructions embedded in tool descriptions that attempt to override agent behavior
• Parameter schemas requesting unnecessary permissions or access to sensitive data
• Description patterns that mimic legitimate system prompts
• Sensitive data markers in tool responses such as API keys, credentials, and PII patterns

Suspicious tools are flagged for manual review. Only tools that are explicitly approved via mcpproxy upstream approve are released to the agent. This creates an intake workflow that most gateways lack entirely. Traefik, Gravitee, and agentgateway all assume you have already vetted your servers. MCPProxy makes vetting a built-in step in the connection lifecycle.

Docker Container Isolation

The third layer wraps each MCP server in a Docker container with restricted capabilities: filesystem isolation limiting servers to explicitly mounted paths, network restrictions that can disable or constrain outbound access, and CPU/memory caps preventing runaway processes. Even if a tool passes quarantine review and gets surfaced by BM25 ranking, it operates within an OS-level sandbox that limits the blast radius of any compromise.

What SAFE-MCP Reveals About the Gaps

Here is where the honest assessment gets uncomfortable — for us and for every other gateway in the market.

The SAFE-MCP framework, which adapts MITRE ATT&CK methodology specifically for MCP ecosystems, documents 85 attack techniques across 14 tactical categories. These are not theoretical attacks. They are structured, categorized, and mapped to real exploitation patterns.

The categories span the full attack lifecycle:

• Initial Access (9 techniques): Tool poisoning with malicious instructions invisible to users but processed by LLMs, supply chain compromise via backdoored packages, server impersonation through name-collision attacks, OAuth authorization phishing
• Execution (9 techniques): Command injection, prompt injection, fake tool invocation, path traversal, autonomous loop exploitation causing denial-of-service
• Persistence (8 techniques): OAuth token theft, backdoored binaries, context memory implants, time-delayed malicious tool definition changes after initial approval
• Privilege Escalation (9 techniques): Sandbox escape, credential relay chains, rogue authorization servers minting overly-permissive tokens
• Defense Evasion (8 techniques): Instruction steganography, consent-fatigue exploitation, server proxy masquerading
• Credential Access (7 techniques): Full-schema poisoning, environment variable scraping, token theft
• Lateral Movement (7 techniques): Cross-tool contamination, token pivot replay
• Collection, C2, Exfiltration, Impact (21 techniques combined): Automated data harvesting, webhook-based command and control, parameter exfiltration, service disruption

No single gateway covers all of these. Not Traefik, not PointGuard, not agentgateway, and not MCPProxy.

MCPProxy’s quarantine catches tool poisoning (Initial Access) and its Docker isolation limits sandbox escape (Privilege Escalation). BM25 scoping reduces the surface area for fake tool invocation (Execution). But we have no defense against time-delayed definition changes after approval (Persistence), no detection of instruction steganography (Defense Evasion), and no monitoring for cross-tool contamination (Lateral Movement).

PointGuard’s DLP catches credential exfiltration but does not sandbox execution. Traefik’s TBAC prevents unauthorized tool calls but does not inspect tool schemas for poisoning. agentgateway’s RBAC controls access but does not analyze whether the tools themselves are trustworthy.

The gap is structural. Every gateway protects a different slice of the SAFE-MCP attack surface, and no two slices overlap cleanly. The 85 techniques demand a defense-in-depth approach that combines static scanning, runtime inspection, schema analysis, container isolation, and behavioral monitoring — and no single product does all five.

What We Are Building Next

Acknowledging gaps is useful only if you are working to close them. Here is what is on the MCPProxy roadmap, informed directly by SAFE-MCP coverage analysis.

Schema Pinning

MCPDome, a Rust-based security proxy, pioneered this idea: compute SHA-256 hashes of tool definitions at registration time and block any server that modifies its schemas after initial approval. This directly counters SAFE-MCP technique categories around time-delayed malicious tool definition changes (Persistence) and tool schema mutation (Defense Evasion). We are implementing schema pinning in MCPProxy as a first-class feature, with alerts when a pinned schema changes and a re-quarantine workflow for updated tools.

OpenTelemetry Integration

MCPProxy currently provides a web UI and structured logs for observability. That is not enough for production deployments. We are adding OpenTelemetry export — traces, metrics, and logs — so MCPProxy integrates with whatever observability stack you already run: Grafana, Datadog, Honeycomb, Jaeger. Every tool call will emit a span with the upstream server, tool name, BM25 score, quarantine status, and execution duration. This closes our observability gap relative to ContextForge and Gravitee.

SAFE-MCP Coverage Mapping

We are building a systematic mapping between SAFE-MCP techniques and MCPProxy defenses, identifying exactly which of the 85 techniques each feature addresses and which remain uncovered. This will be published as an open document — not because it makes us look good (it will not; the coverage will be partial), but because the ecosystem needs honest threat-to-defense mapping that helps teams understand what their gateway stack actually protects against.

Behavioral Analysis

The hardest techniques to defend against are behavioral: an MCP server that acts normally for weeks, then begins exfiltrating data when it detects a specific query pattern. Static schema analysis and one-time quarantine review cannot catch this. We are exploring runtime behavioral baselines — tracking tool call patterns, response sizes, and timing anomalies to flag deviations. This is research-stage work, not a near-term feature, but it addresses the most dangerous gap in our current architecture.

The Honest Takeaway

Gartner is right: if you are deploying AI agents in production, you need an MCP gateway. But choosing one requires understanding what each gateway actually defends against, not just what features it advertises.

Traefik gives you mature, battle-tested policy enforcement. PointGuard gives you DLP and zero-trust authorization. Gravitee gives you API management discipline. agentgateway gives you vendor-neutral, multi-protocol routing. MCPProxy gives you intelligent tool discovery and schema quarantine.

None of them give you complete SAFE-MCP coverage. The 85 documented attack techniques demand layered defenses, and the honest answer is that the industry is still building those layers.

If you want to try MCPProxy, it is a single binary install:

brew install smart-mcp-proxy/mcpproxy/mcpproxy
mcpproxy serve
mcpproxy upstream add <server-name> -- <command>
mcpproxy upstream list
mcpproxy upstream approve <server-name>

If you want to contribute to closing the SAFE-MCP gaps, the framework is open and actively maintained. The attack techniques are documented. The defenses are not. That is the work ahead.