AI Agent Gateways: What They Are and Why They Matter#

Target Audience: Platform engineers, infrastructure architects, and engineering leaders evaluating how to manage, secure, and scale AI agent connectivity in production.

What Is an AI Agent Gateway?#

Simple Definition: An AI agent gateway is a reverse proxy purpose-built for AI agent traffic. It sits between your AI agents (or LLM-powered applications) and the tools, APIs, and other agents they need to communicate with. It handles protocol translation, authentication, rate limiting, observability, and policy enforcement — the same concerns that API gateways solved for microservices, now adapted for the agentic AI stack.

In Infrastructure Terms: Think of it as nginx or Envoy, but for MCP and A2A traffic instead of HTTP/gRPC. Without a gateway, every agent-to-tool connection is a point-to-point integration — each client must discover, authenticate with, and manage connections to each MCP server individually. A gateway centralizes this, giving you one control plane for all agent traffic.

Why It’s Needed Now: The Model Context Protocol (MCP, Anthropic, 2024) standardized how agents talk to tools. The Agent-to-Agent protocol (A2A, Google, 2025) standardized how agents talk to each other. But standards alone don’t solve operational concerns — who can call what tool, how fast, with what credentials, and who’s watching. That’s the gateway layer.

The Problem Space#

Without a Gateway#

Agent A ──────→ MCP Server 1 (auth: API key in env var)
Agent A ──────→ MCP Server 2 (auth: OAuth, different provider)
Agent A ──────→ MCP Server 3 (no auth, bound to 0.0.0.0)
Agent B ──────→ MCP Server 1 (duplicate auth config)
Agent B ──────→ MCP Server 4 (stdio only, needs transport bridge)
Agent C ──────→ Agent D via A2A (no policy enforcement)

Pain points:

• Auth credentials scattered across agent configs (53% of MCP servers use static API keys; 8.5% use OAuth)
• No centralized rate limiting or cost control
• No audit trail of which agent called which tool
• Transport mismatches (stdio servers can’t serve HTTP clients)
• No policy enforcement (any agent can call any tool)

With a Gateway#

Agent A ─┐
Agent B ─┤──→ [Gateway] ──→ MCP Servers (auth managed centrally)
Agent C ─┘        │──→ A2A Agents (policy enforced)
                  │──→ LLM APIs (rate limited, cost tracked)
                  └──→ Observability (traces, metrics, logs)

What changes:

• Single point for auth management (OAuth 2.1, API keys, mTLS)
• Centralized rate limiting and quota management
• Full audit trail via OpenTelemetry
• Transport bridging handled transparently
• Policy enforcement via OPA, Cedar, or built-in rules

Two Protocols, One Gateway Layer#

MCP (Model Context Protocol)#

Agent-to-tool communication. An MCP server exposes tools (functions), resources (data), and prompts that agents can discover and invoke. Think of MCP as “USB-C for AI tools” — a standard plug that any agent can use with any tool.

Gateway role for MCP: Federation (aggregate multiple MCP servers behind one endpoint), auth injection (MCP server stays stateless, gateway handles OAuth), transport bridging (stdio↔SSE↔Streamable HTTP), and tool-level access control.

A2A (Agent-to-Agent Protocol)#

Agent-to-agent communication. A2A enables agents to discover each other’s capabilities, delegate tasks, stream progress updates, and exchange results. Think of A2A as “HTTP for agents” — a standard way for agents to collaborate.

Gateway role for A2A: Routing (direct tasks to the right agent), identity verification, task lifecycle management, and cross-organization agent federation.

The Complementary Relationship#

MCP and A2A are not competing protocols — they serve different communication patterns:

A gateway that supports both protocols can serve as the unified control plane for all agent communication.

The Authentication Challenge#

MCP’s OAuth 2.1 specification has been widely criticized as enterprise-unfriendly:

• Implementation complexity: Protected Resource Metadata discovery, PKCE challenges, and Resource Indicators (RFC 8707) create significant developer burden
• Security incidents: CVE-2025-6514 (CVSS 9.6) — critical command injection in mcp-remote npm package via unsanitized OAuth URLs (437K+ downloads affected)
• Adoption gap: Only 8.5% of MCP servers implement OAuth; hundreds found exposed without authentication
• Enterprise mismatch: Enterprises already have identity infrastructure (Okta, Azure AD, Keycloak) — MCP’s bespoke OAuth flow doesn’t integrate cleanly

Market consensus: The gateway handles auth, MCP servers stay dumb. This is the strongest argument for the gateway layer — it decouples authentication complexity from tool implementation.

Technology Landscape Overview#

Full Governance Platforms#

Agent Gateway (Linux Foundation/Solo.io) — Rust-based, native MCP + A2A + LLM gateway, broadest protocol coverage, strongest governance backing.

IBM ContextForge — Python-based, MCP + A2A + REST/gRPC, broadest protocol support including legacy APIs, admin UI included.

Kong AI Gateway — Lua/Go-based, MCP plugins atop mature API gateway, strongest enterprise feature set (rate limiting, analytics, cost tracking), largest existing install base.

Envoy AI Gateway — Go-based, built on Envoy proxy, MCP-first with full spec compliance, CEL-based authorization, inherits Envoy’s battle-tested traffic management.

Protocol Bridges & Aggregators#

Docker MCP Gateway — Go-based, container-native MCP gateway, tight Docker Desktop integration, developer-experience focused.

Microsoft MCP Gateway — C#-based, Kubernetes-native, session-aware stateful routing, multi-tenant design for Azure environments.

MetaMCP — TypeScript-based, MCP aggregator/orchestrator, combines multiple MCP servers behind one endpoint, lightweight governance.

Transport Proxies#

Supergateway — TypeScript-based, stdio↔SSE bridge, lightweight transport translation.

mcp-proxy variants — Multiple implementations (Python, Go, TypeScript) for stdio↔HTTP bridging.

Standards Frameworks#

AGNTCY (Cisco/Linux Foundation) — Not a gateway product but a standards framework for agent identity, discovery, and messaging. Complementary to gateway infrastructure.

Generic Implementation Strategy#

Phase 1: Evaluate Transport Needs (1 week)#

Target: Understand your current agent-to-tool connectivity pattern

• How many MCP servers do you operate?
• What transports do they use (stdio, SSE, Streamable HTTP)?
• How many agents/clients consume them?
• What auth mechanisms are in place?

If you have <5 MCP servers with simple auth, a transport proxy (Supergateway, mcp-proxy) may suffice.

Phase 2: Deploy Gateway (1-2 weeks)#

Target: Centralize MCP connectivity through a gateway

# Example: Agent Gateway configuration
listeners:
  - name: mcp-listener
    protocol: MCP
    address: 0.0.0.0:8080
    tls:
      cert_path: /certs/server.crt
      key_path: /certs/server.key
targets:
  - name: github-tools
    protocol: MCP
    address: mcp-server-github:3000
  - name: db-tools
    protocol: MCP
    address: mcp-server-db:3001
policies:
  - name: rate-limit
    type: rate_limit
    config:
      requests_per_minute: 100

Phase 3: Add Governance (2-4 weeks)#

Target: Layer auth, observability, and policy enforcement

• Configure OAuth 2.1 or integrate with existing IdP
• Enable OpenTelemetry tracing for all agent traffic
• Define tool-level access policies (OPA, Cedar, or built-in)
• Set up cost tracking and alerting for LLM API calls

Phase 4: Multi-Protocol (1-2 months)#

Target: Extend to A2A for agent-to-agent communication

• Enable A2A listeners alongside MCP
• Configure agent discovery and capability advertising
• Implement cross-agent task routing policies
• Monitor inter-agent communication patterns

Decision Framework#

Choose Agent Gateway When:#

• Need MCP + A2A + LLM gateway in one binary
• Performance matters (Rust, compiled binary)
• Want Linux Foundation governance and multi-vendor backing
• Kubernetes-native deployment preferred

Choose IBM ContextForge When:#

• Need to gateway legacy REST/gRPC APIs alongside MCP/A2A
• Python ecosystem preferred
• Want built-in admin UI
• Broader protocol support trumps raw performance

Choose Kong AI Gateway When:#

• Already running Kong for API management
• Enterprise features critical (analytics, developer portal)
• MCP is an addition to existing API gateway needs
• Need commercial support and SLAs

Choose Envoy AI Gateway When:#

• Already invested in Envoy/Istio service mesh
• Want MCP as part of broader traffic management
• CEL-based authorization preferred
• Need standalone (non-K8s) deployment option

Choose Docker MCP Gateway When:#

• Container-native development workflow
• Docker Desktop is the primary development environment
• Simple MCP gateway needs without A2A
• Developer experience over enterprise governance

Choose a Transport Proxy When:#

• Just need stdio↔HTTP bridging
• <5 MCP servers, simple auth
• Minimal infrastructure overhead
• Evaluation/prototyping phase

Risk Assessment#

Technical Risks#

Protocol Immaturity (High Priority)

• Mitigation: Choose gateways that track spec changes actively (AG, Envoy AI Gateway release monthly); abstract protocol details behind gateway config
• Business Impact: MCP and A2A specs are still evolving; breaking changes may require gateway upgrades

Auth Complexity (High Priority)

• Mitigation: Let the gateway handle OAuth; keep MCP servers stateless; use existing IdP integration rather than MCP-native OAuth
• Business Impact: CVE-2025-6514 showed that MCP auth implementations are attack surface; centralize to reduce exposure

Vendor Lock-in (Medium Priority)

• Mitigation: Choose Apache 2.0 licensed gateways; Agent Gateway and Envoy AI Gateway both under foundation governance
• Business Impact: Gateway config is not portable between products; migration requires reconfiguration

Business Risks#

Market Consolidation (Medium Priority)

• Mitigation: Bet on foundation-backed projects (Agent Gateway, A2A under LF); avoid single-vendor solutions without governance
• Business Impact: The gateway space is consolidating rapidly; early choices may become orphaned

Premature Investment (Medium Priority)

• Mitigation: Start with transport proxies, graduate to full gateways as needs grow; most proxies can be replaced non-disruptively
• Business Impact: The gateway layer is <18 months old; patterns are still emerging

S1: Rapid Discovery — Approach#

Philosophy: “Popular libraries exist for a reason” Time Budget: 10 minutes Date: March 2026

Methodology#

Discovery Strategy#

Ecosystem-driven discovery focused on the emerging AI agent gateway category — projects that proxy, aggregate, or govern MCP and/or A2A traffic between AI agents and their tools or peer agents.

Discovery Tools Used#

1. GitHub Repository Analysis

   • Star counts, commit frequency, contributor diversity
   • Release cadence and version maturity (pre-release vs GA)
   • License and governance model

2. Foundation & Vendor Announcements

   • Linux Foundation project donations and launches
   • Cloud vendor blog posts (Google, Microsoft, AWS, IBM)
   • Conference presentations (KubeCon, AI Engineer Summit)

3. Community Signals

   • Hacker News and Reddit discussions on MCP gateways
   • Developer blog posts and tutorials
   • MCP specification GitHub discussions

4. Market Research

   • Analyst reports on AI agent infrastructure
   • VC funding announcements in the gateway space
   • Enterprise adoption surveys

Selection Criteria#

Primary Filters#

1. Protocol Support

   • MCP support (minimum requirement)
   • A2A support (strong differentiator)
   • LLM API proxying (nice-to-have)

2. Adoption Metrics

   • GitHub stars > 200 (for purpose-built gateways)
   • Active development (commits in last 30 days)
   • Contributor diversity (not single-developer projects)

3. Operational Maturity

   • Auth integration (OAuth, API key management)
   • Observability (metrics, tracing, logging)
   • Deployment model (Docker, Kubernetes, standalone)

4. Governance

   • License (Apache 2.0, MIT preferred)
   • Foundation backing (Linux Foundation, CNCF)
   • Corporate backing stability

Solutions Evaluated#

Category 1: Full Governance Platforms#

1. Agent Gateway (LF/Solo.io) — 2,056 stars, Rust, Apache 2.0, v1.0.0-rc.2
2. IBM ContextForge — 3,440 stars, Python, Apache 2.0, v1.0.0-RC2
3. Kong AI Gateway — 42,996 stars (overall), Lua, Apache 2.0, MCP since v3.12
4. Envoy AI Gateway — 1,440 stars, Go, Apache 2.0, v0.5.0

Category 2: Protocol Bridges & Aggregators#

5. Docker MCP Gateway — 1,310 stars, Go, MIT, v0.41.0
6. Microsoft MCP Gateway — 531 stars, C#, MIT, pre-release
7. MetaMCP — 2,130 stars, TypeScript, MIT, v2.4.22

Category 3: Transport Proxies#

8. Supergateway — 2,513 stars, TypeScript, MIT, v3.4.3
9. mcp-proxy (sparfenyuk) — 2,356 stars, Python, MIT, v0.11.0
10. mcp-proxy (tbxark) — 662 stars, Go, MIT

Category 4: Standards Frameworks#

11. AGNTCY (Cisco/LF) — Multi-repo, Go/Python/Rust, Apache 2.0

Discovery Process (Timeline)#

0-2 minutes: Category mapping

• Identified four tiers: full governance, protocol bridges, transport proxies, standards frameworks
• Noted rapid market evolution — most projects <18 months old
• Linux Foundation emerging as governance home for agent infrastructure

2-4 minutes: Full governance platforms

• Agent Gateway: broadest protocol coverage (MCP + A2A + LLM), Rust performance, LF governance
• IBM ContextForge: highest stars in dedicated gateway category, Python, broadest protocol support including legacy
• Kong: massive existing install base, MCP via plugins, enterprise features
• Envoy AI Gateway: built on proven Envoy proxy, MCP-first, inherits battle-tested traffic management

4-6 minutes: Protocol bridges and aggregators

• Docker MCP Gateway: strong DX, container-native, rapid release cadence (v0.41.0)
• Microsoft MCP Gateway: Kubernetes-native, session-aware, Azure-aligned
• MetaMCP: aggregator model popular with developers running many MCP servers locally

6-8 minutes: Transport proxies and standards

• Supergateway and mcp-proxy variants: solve the stdio↔HTTP problem, high adoption but narrow scope
• AGNTCY: complementary standards layer, not a gateway product — provides identity and discovery

8-10 minutes: Market context and trends

• AI agent gateway market: $7.63B (2025) → projected $182.97B by 2033
• Gartner: 40% of enterprise apps will feature AI agents by end of 2026
• Consolidation pattern: transport proxies → full governance platforms

Key Findings#

Convergence Signals#

• Agent Gateway is the consensus leader: broadest protocol coverage, LF governance, industry backing from AWS/Cisco/IBM/Microsoft/Red Hat/Apple
• Gateway handles auth, servers stay dumb: market consensus that MCP OAuth complexity belongs in the gateway layer, not individual tool servers
• MCP + A2A convergence: dual-protocol support is the key differentiator for governance platforms (only AG and ContextForge deliver this today)

Divergence Points#

• Language preference: Rust (AG) vs Python (ContextForge) vs Go (Envoy, Docker) — team expertise matters
• Scope: Full governance (AG, Kong) vs protocol bridging (Docker, MetaMCP) vs transport proxy (Supergateway, mcp-proxy)
• Maturity: Kong is GA with years of production use; AG is at v1.0.0-rc.2; most others are pre-v1.0

Market Dynamics#

• Foundation consolidation: Both Agent Gateway and A2A Protocol now under Linux Foundation governance
• Rapid evolution: Most dedicated AI agent gateways are <18 months old; patterns still emerging
• Enterprise pull: 57% of companies already have AI agents in production (G2, Aug 2025) — gateway demand is immediate, not speculative

Confidence Assessment#

Sources#

• Agent Gateway GitHub: github.com/agentgateway/agentgateway (accessed March 2026)
• IBM ContextForge GitHub: github.com/IBM/mcp-context-forge (accessed March 2026)
• Kong AI Gateway Blog: konghq.com/blog/product-releases/enterprise-mcp-gateway (accessed March 2026)
• Envoy AI Gateway: aigateway.envoyproxy.io (accessed March 2026)
• Docker MCP Gateway: github.com/docker/mcp-gateway (accessed March 2026)
• Microsoft MCP Gateway: github.com/microsoft/mcp-gateway (accessed March 2026)
• MetaMCP: github.com/metatool-ai/metamcp (accessed March 2026)
• AGNTCY: docs.agntcy.org (accessed March 2026)
• Doyensec MCP Auth Analysis: blog.doyensec.com/2026/03/05/mcp-nightmare.html (accessed March 2026)
• Gartner AI Agents Prediction (Aug 2025): gartner.com/en/newsroom/press-releases/2025-08-26
• Grand View Research AI Agents Market: grandviewresearch.com/industry-analysis/ai-agents-market-report (accessed March 2026)

S2: Comprehensive Analysis — Approach#

Philosophy: “Understand the entire solution space before choosing” Time Budget: 45 minutes Date: March 2026

Methodology#

Discovery Strategy#

Deep technical analysis of each gateway project — architecture, protocol support, auth model, deployment options, performance characteristics, and ecosystem integration. Focus on production readiness indicators and operational concerns.

Discovery Tools Used#

1. Source Code Analysis

   • Architecture review (core abstractions, plugin models)
   • Configuration format and flexibility
   • Protocol implementation completeness

2. Documentation Review

   • Official docs, getting-started guides, API references
   • Architecture decision records (where available)
   • Known limitations and roadmap

3. Security Analysis

   • Auth implementation approach
   • Known CVEs and security advisories
   • mTLS, TLS termination, credential management

4. Deployment & Operations

   • Container images, Helm charts, Kubernetes operators
   • Resource requirements and scaling characteristics
   • Observability integration (OpenTelemetry, Prometheus)

Detailed Solution Profiles#

1. Agent Gateway (Linux Foundation / Solo.io)#

GitHub: agentgateway/agentgateway | Stars: 2,056 | Language: Rust | License: Apache 2.0 Latest: v1.0.0-rc.2 (March 14, 2026) | Created: 2025

Architecture: Agent Gateway operates in three modes, selectable at startup:

• MCP Gateway: Reverse proxy for MCP servers, federation, tool-level access control
• A2A Gateway: Routing and policy enforcement for agent-to-agent communication
• LLM Gateway: Unified API for multiple LLM providers (OpenAI, Anthropic, Google, etc.)

All three modes share a common traffic management layer built in Rust for performance. Configuration is declarative (YAML/JSON) with hot-reload support.

Protocol Support:

Auth & Policy:

• OAuth 2.1 (MCP spec-compliant)
• API key management
• OPA integration for fine-grained authorization
• OpenFGA/SpiceDB for relationship-based access control
• mTLS for inter-service communication

Observability:

• Native OpenTelemetry (traces, metrics, logs)
• Prometheus metrics endpoint
• Structured logging (JSON)

Deployment:

• Single binary (Rust, ~15MB)
• Docker image
• Kubernetes Gateway API integration
• Helm chart available

Contributors: Solo.io (creator), AWS, Cisco, Huawei, IBM, Microsoft, Red Hat, Apple, Shell, Zayo

Strengths:

• Broadest protocol coverage in a single binary
• Rust performance (low latency, minimal resource footprint)
• Linux Foundation governance — no single-vendor risk
• Active multi-vendor contributor community

Weaknesses:

• v1.0.0 not yet GA (RC2 as of March 2026)
• Rust codebase may limit community contributions vs Go/Python
• Newer project — less production mileage than Kong or Envoy

2. IBM ContextForge#

GitHub: IBM/mcp-context-forge | Stars: 3,440 | Language: Python | License: Apache 2.0 Latest: v1.0.0-RC2 (March 9, 2026) | Created: 2025

Architecture: ContextForge is a unified gateway that normalizes heterogeneous tool and agent APIs behind a single management layer. It can proxy MCP servers, A2A agents, and traditional REST/gRPC APIs — treating them all as “context sources” for AI agents.

Protocol Support:

Key Differentiator: Broadest protocol support including legacy APIs. Enterprises with existing REST/gRPC services can expose them to agents via ContextForge without rewriting as MCP servers.

Features:

• Admin UI for gateway management
• Centralized discovery and registry
• Plugin framework for custom integrations
• Guardrails layer (input/output validation)
• Optimized agent-to-tool calling patterns

Deployment:

• Docker Compose (primary)
• Kubernetes (Helm)
• Standalone Python process

Strengths:

• Broadest protocol support (MCP + A2A + REST + gRPC)
• Admin UI for non-CLI users
• IBM backing and enterprise focus
• Python ecosystem — easy to extend and customize

Weaknesses:

• Python performance ceiling vs Rust/Go alternatives
• IBM single-vendor backing (no foundation governance yet)
• Less community momentum than Agent Gateway

3. Kong AI Gateway#

GitHub: Kong/kong | Stars: 42,996 | Language: Lua (OpenResty) | License: Apache 2.0 MCP Support Since: Kong Gateway 3.12 (October 2025)

Architecture: Kong is a mature, battle-tested API gateway that added MCP support via plugins. It’s not a purpose-built AI gateway — it’s a general-purpose API gateway with an AI plugin layer.

MCP-Specific Plugins:

• AI MCP Proxy: Protocol bridge between MCP clients and MCP servers via HTTP
• AI MCP OAuth2: OAuth 2.1 implementation per MCP specification
• MCP Registry (Kong Konnect, Feb 2026): Centralized discovery and governance for MCP servers

Protocol Support:

Enterprise Features:

• Rate limiting (per-consumer, per-route, sliding window)
• Analytics and developer portal (Kong Konnect)
• Cost tracking per LLM API call
• MCP-specific Prometheus metrics
• Commercial support and SLAs

Strengths:

• Most mature gateway platform (years of production use)
• Largest existing install base (42K+ stars)
• Enterprise features (analytics, portal, support)
• MCP is incremental — doesn’t require rip-and-replace

Weaknesses:

• MCP support via plugins, not native — may lag spec changes
• No A2A support
• Commercial licensing for enterprise features
• Lua/OpenResty ecosystem less familiar to most teams

4. Envoy AI Gateway#

GitHub: envoyproxy/ai-gateway | Stars: 1,440 | Language: Go | License: Apache 2.0 Latest: v0.5.0 (January 23, 2026) | Created: 2025

Architecture: Built on Envoy Gateway (which builds on Envoy Proxy), inheriting Envoy’s battle-tested traffic management — load balancing, circuit breaking, retries, rate limiting. Adds first-class MCP support with full spec compliance.

Protocol Support:

Auth & Policy:

• OAuth 2.1 authentication for MCP (per spec)
• CEL-based MCP authorization (fine-grained, tool-level)
• Upstream API key injection
• Inherits Envoy’s mTLS and RBAC

Deployment:

• Kubernetes (primary, via Envoy Gateway)
• Standalone mode (no K8s required, added in v0.5.0)
• Multi-gateway deployments via GatewayConfig CRD

Strengths:

• Built on proven Envoy proxy (battle-tested in production at scale)
• CEL-based authorization — expressive and type-safe
• Standalone mode for non-K8s environments
• CNCF ecosystem alignment

Weaknesses:

• MCP-focused, no A2A support
• Early stage (v0.5.0)
• Envoy complexity inherited (steep learning curve)
• Smaller community than AG or Kong

5. Docker MCP Gateway#

GitHub: docker/mcp-gateway | Stars: 1,310 | Language: Go | License: MIT Latest: v0.41.0 (March 18, 2026)

Architecture: Docker CLI plugin that acts as an MCP gateway, tightly integrated with Docker Desktop and container workflows. Optimized for developer experience over enterprise governance.

Key Features:

• Docker CLI integration (docker mcp)
• Container-native MCP server management
• Gateway mode for aggregating multiple MCP servers
• Rapid release cadence (v0.41.0 in ~6 months)

Strengths:

• Best developer experience for Docker users
• Rapid iteration and release cadence
• Simple setup for local development
• Container-native by design

Weaknesses:

• Focused on development workflow, not production governance
• No A2A support
• Docker Desktop dependency for full experience
• Limited auth and policy features

6. Microsoft MCP Gateway#

GitHub: microsoft/mcp-gateway | Stars: 531 | Language: C# | License: MIT Latest: Pre-release (no formal tagged release)

Architecture: Reverse proxy and management layer for MCP servers, designed for Kubernetes and Azure environments. Key differentiator is session-aware stateful routing — important for MCP’s stateful protocol semantics.

Key Features:

• Session-aware stateful routing (sticky sessions for MCP)
• MCP server lifecycle management in Kubernetes
• Scalable multi-tenant design
• Azure ecosystem integration

Strengths:

• Session-aware routing (unique capability for stateful MCP)
• Kubernetes-native design
• Microsoft backing, Azure alignment
• Multi-tenant by design

Weaknesses:

• Pre-release, no formal versioning
• C# ecosystem (narrower contributor pool for infrastructure)
• No A2A support
• Smallest community of the governance platforms

7. MetaMCP#

GitHub: metatool-ai/metamcp | Stars: 2,130 | Language: TypeScript | License: MIT Latest: v2.4.22 (December 19, 2025)

Architecture: MCP aggregator and orchestrator — manages multiple MCP servers through a single unified MCP endpoint. Deployed as a single Docker container. Positioned as middleware between MCP clients and MCP servers.

Key Features:

• Aggregate N MCP servers behind 1 endpoint
• Custom headers and security configuration
• Tool sync caching for performance
• Docker-first deployment

Strengths:

• Simple aggregation model — easy to understand and deploy
• Good for developers running many MCP servers locally
• Lightweight footprint

Weaknesses:

• Limited governance features (no OPA, no fine-grained auth)
• No A2A support
• TypeScript performance ceiling for high-throughput scenarios
• Less active maintenance (last release Dec 2025)

8. Transport Proxies (Supergateway, mcp-proxy variants)#

Supergateway: 2,513 stars, TypeScript, MIT, v3.4.3 (Oct 2025) mcp-proxy (sparfenyuk): 2,356 stars, Python, MIT, v0.11.0 (Jan 2026) mcp-proxy (tbxark): 662 stars, Go, MIT

These projects solve a specific problem: bridging MCP transport protocols (stdio↔SSE↔Streamable HTTP). They are not gateways in the governance sense — no auth, no rate limiting, no policy enforcement. Useful for:

• Making stdio MCP servers accessible over HTTP
• Evaluating MCP without infrastructure investment
• Lightweight development setups

Note: Supergateway appears less actively maintained (last update Oct 2025), suggesting the community may be graduating to more feature-rich alternatives.

9. AGNTCY (Cisco / Linux Foundation)#

GitHub: github.com/agntcy | Stars: ~88-178 (across repos) | Languages: Go, Python, Rust, TypeScript | License: Apache 2.0

AGNTCY is not a gateway product but a standards framework for multi-agent interoperability:

• AGNTCY Identity: Agent and MCP server identity verification
• SLIM Protocol: Secure Low-Latency Interactive Messaging
• Agent Directories: Discovery infrastructure for agent capabilities
• Observable SDKs: Instrumented client libraries

Open-sourced by Cisco (March 2025), donated to Linux Foundation (July 2025). 75+ supporting companies including Dell, Google Cloud, Oracle, Red Hat.

Relationship to Gateways: AGNTCY provides the identity and discovery layer that gateways consume. Agent Gateway and AGNTCY are complementary — AG handles traffic, AGNTCY handles “who is this agent and what can it do?”

Comparative Analysis#

Protocol Coverage Matrix#

Auth & Policy Matrix#

Maturity & Governance#

Auth Deep Dive: The MCP Authentication Landscape#

The Problem#

MCP’s OAuth 2.1 specification requires:

1. Protected Resource Metadata discovery
2. PKCE challenges
3. Resource Indicators (RFC 8707, added June 2025)
4. Dynamic Client Registration (optional but common)

This is a significant implementation burden for every MCP server. The June 2025 spec update reclassified MCP servers as OAuth Resource Servers, adding more complexity.

Security Track Record#

• CVE-2025-6514 (CVSS 9.6): Command injection in mcp-remote npm package via unsanitized OAuth authorization URLs. 437K+ downloads affected.
• NeighborJack vulnerability (June 2025): Hundreds of MCP servers found bound to 0.0.0.0 without authentication
• SSO intermediary attacks: Fake metadata injection, redirect URI manipulation documented by Doyensec

The Gateway Solution#

The emerging consensus: the gateway handles auth, MCP servers stay stateless.

Client → [Gateway: OAuth 2.1, API keys, mTLS] → MCP Server (no auth code)

This approach:

• Reduces attack surface (one auth implementation, not N)
• Leverages existing IdP infrastructure (Okta, Azure AD, Keycloak)
• Simplifies MCP server development (just implement tools)
• Enables centralized credential rotation and audit

Policy Language Comparison#

Sources#

• Agent Gateway docs and source: github.com/agentgateway/agentgateway (accessed March 2026)
• IBM ContextForge docs and source: github.com/IBM/mcp-context-forge (accessed March 2026)
• Kong AI Gateway MCP docs: docs.konghq.com/hub/kong-inc/ai-mcp-proxy/ (accessed March 2026)
• Kong MCP blog: konghq.com/blog/product-releases/enterprise-mcp-gateway (accessed March 2026)
• Envoy AI Gateway docs: aigateway.envoyproxy.io (accessed March 2026)
• Docker MCP Gateway: github.com/docker/mcp-gateway (accessed March 2026)
• Microsoft MCP Gateway: github.com/microsoft/mcp-gateway (accessed March 2026)
• MetaMCP: github.com/metatool-ai/metamcp (accessed March 2026)
• AGNTCY docs: docs.agntcy.org (accessed March 2026)
• Cedar for Agents: github.com/cedar-policy/cedar-for-agents (accessed March 2026)
• Doyensec MCP Auth Analysis: blog.doyensec.com/2026/03/05/mcp-nightmare.html (accessed March 2026)
• Christian Posta on MCP OAuth: blog.christianposta.com/the-updated-mcp-oauth-spec-is-a-mess/ (accessed March 2026)
• Auth0 MCP Spec Updates: auth0.com/blog/mcp-specs-update-all-about-auth/ (accessed March 2026)
• Obsidian Security MCP OAuth Pitfalls: obsidiansecurity.com/blog/when-mcp-meets-oauth-common-pitfalls (accessed March 2026)
• Linux Foundation A2A: linuxfoundation.org/press/linux-foundation-launches-the-agent2agent-protocol-project (accessed March 2026)
• Google A2A Upgrade: cloud.google.com/blog/products/ai-machine-learning/agent2agent-protocol-is-getting-an-upgrade (accessed March 2026)
• Natoma OPA vs Cedar for MCP: natoma.ai/blog/mcp-access-control-opa-vs-cedar-the-definitive-guide (accessed March 2026)

S3: Need-Driven Discovery — Approach#

Philosophy: “Start with requirements, find exact-fit solutions” Time Budget: 20 minutes Date: March 2026

Methodology#

Discovery Strategy#

Requirement-focused discovery that maps real-world agent infrastructure scenarios to optimal gateway solutions, validating fit against must-have and nice-to-have criteria.

Use Case Selection#

Identified 6 representative deployment scenarios:

1. Enterprise Multi-Agent Platform (large org, 50+ MCP servers)
2. Startup AI Product (small team, 5-10 MCP servers)
3. Solo Developer / Local Development (1 developer, 3-5 MCP servers)
4. Existing API Gateway Migration (adding MCP to existing infrastructure)
5. Multi-Cloud Agent Federation (agents spanning AWS/Azure/GCP)
6. Compliance-Heavy Environment (financial services, healthcare)

Evaluation Framework#

Requirement Categories#

Must-Have (blockers if missing):

• Protocol support for current needs (MCP minimum)
• Auth integration with existing IdP
• Deployment compatibility (K8s, Docker, standalone)
• License compatibility

Nice-to-Have (differentiators):

• A2A support for future agent-to-agent communication
• Policy language integration (OPA, Cedar)
• Admin UI
• Commercial support option

Fit Scoring#

• ✅ 100% — Meets all must-haves + most nice-to-haves
• ⚠️ 70-99% — Meets must-haves, gaps in nice-to-haves
• ❌ <70% — Missing must-haves, not recommended for this use case

Use Case Evaluations#

1. Enterprise Multi-Agent Platform#

Scenario: Large organization (500+ developers), 50+ MCP servers, multiple AI agent frameworks, Kubernetes infrastructure, existing IdP (Okta/Azure AD), need for audit trails and compliance.

Must-Haves: MCP + A2A support, OAuth/OIDC with existing IdP, fine-grained authorization, OpenTelemetry, Kubernetes-native, multi-tenant.

Recommendation: Agent Gateway for new deployments. Kong if already running Kong.

2. Startup AI Product#

Scenario: Small team (5-15 developers), building an AI-powered product, 5-10 MCP servers, deploying to a single cloud, Docker Compose or simple K8s, need to move fast.

Must-Haves: MCP support, simple deployment, quick setup (<1 day), reasonable auth, not enterprise-priced.

Recommendation: Docker MCP Gateway for speed. Graduate to Agent Gateway when governance needs grow.

3. Solo Developer / Local Development#

Scenario: Individual developer, 3-5 MCP servers (GitHub, database, file system), using Claude Desktop or VS Code Copilot, need stdio↔HTTP bridging, minimal infrastructure.

Must-Haves: Simple setup, stdio support, runs locally, minimal resource usage.

Recommendation: MetaMCP for aggregation, Supergateway or mcp-proxy for simple transport bridging.

4. Existing API Gateway Migration#

Scenario: Organization already running Kong, Envoy, or similar API gateway. Want to add MCP support without replacing existing infrastructure.

Must-Haves: Incremental adoption, works alongside existing gateway, doesn’t require rip-and-replace.

Recommendation: Use MCP plugins for your existing gateway if available. Otherwise, deploy Agent Gateway alongside.

5. Multi-Cloud Agent Federation#

Scenario: Agents and MCP servers distributed across AWS, Azure, and GCP. Need unified control plane, cross-cloud routing, consistent auth.

Must-Haves: Cloud-agnostic deployment, A2A for cross-cloud agent communication, centralized auth, network-level security.

Recommendation: Agent Gateway. Its Rust single-binary deployment and cloud-agnostic design make it the strongest multi-cloud option.

6. Compliance-Heavy Environment#

Scenario: Financial services or healthcare organization. Strict audit requirements, data residency constraints, formal access policies, regulatory review of all agent actions.

Must-Haves: Complete audit trail, formal policy language, data residency options, credential management, self-hosted (no SaaS dependency).

Recommendation: Agent Gateway with OPA for policy enforcement. Kong Enterprise if budget allows and A2A isn’t needed.

Cross-Cutting Findings#

The Graduation Path#

Most organizations will follow this progression:

Transport Proxy → Protocol Bridge → Full Governance
(mcp-proxy)    → (Docker MCP GW) → (Agent Gateway / Kong)

Start simple, graduate as needs grow. The gateway layer is new enough that premature over-investment carries risk.

The A2A Divider#

A2A support is the sharpest differentiator in the market:

• With A2A: Agent Gateway, IBM ContextForge (only two)
• Without A2A: Everything else

If agent-to-agent communication is on your roadmap, this narrows the field dramatically.

The Auth Consensus#

Across all use cases, the pattern is consistent: gateway handles auth, tools stay stateless. No use case benefits from implementing OAuth in individual MCP servers when a gateway is present.

Sources#

• Use case patterns derived from community discussions: reddit.com/r/mcp, Hacker News (accessed March 2026)
• Enterprise adoption data: G2 AI Agent Survey (August 2025)
• Multi-cloud patterns: CNCF case studies on Envoy Gateway (accessed March 2026)
• Compliance requirements: NIST AI RMF, EU AI Act agent provisions (accessed March 2026)

S4: Strategic Selection — Approach#

Philosophy: “Think long-term and consider broader context” Time Budget: 15 minutes Outlook: 3-5 years Date: March 2026

Methodology#

Future-focused analysis of market trajectory, vendor risk, ecosystem momentum, and the gateway layer’s strategic position in the evolving agentic AI stack.

Discovery Tools#

1. Market Trajectory Analysis

   • Revenue projections and investment signals
   • Foundation governance as stability indicator
   • Consolidation patterns in adjacent markets (API gateways, service meshes)

2. Vendor Risk Assessment

   • Foundation vs single-vendor governance
   • Contributor diversity as resilience indicator
   • License stability (Apache 2.0 vs commercial)

3. Technology Trajectory

   • MCP and A2A spec evolution pace
   • Convergence with existing infrastructure (Envoy, Kong, K8s)
   • Emerging patterns (agent identity, policy-as-code)

4. Ecosystem Momentum

   • Developer adoption velocity
   • Enterprise adoption signals
   • Standards body activity

Strategic Landscape (2026-2030)#

Macro Trend: Agent Infrastructure Standardization#

The AI agent gateway market mirrors the API gateway market circa 2015-2018:

Key insight: The API gateway market took ~5 years to consolidate from dozens of options to 3-4 dominant platforms. The agent gateway market is moving faster — Linux Foundation governance of both AG and A2A suggests a 2-3 year consolidation timeline.

Market Projections#

• AI Agent Market: $7.63B (2025) → $182.97B by 2033 (CAGR 49.6%)
• Enterprise Adoption: 40% of enterprise apps will feature AI agents by end of 2026 (Gartner)
• Multi-agent Systems: 1,445% surge in enterprise inquiries Q1 2024 → Q2 2025 (Gartner)
• Agent Infrastructure: Estimated $1-2B gateway/infrastructure TAM by 2028 (extrapolated from overall market)

Protocol Trajectory#

MCP: Evolving rapidly. The June 2025 auth spec change broke many existing implementations. Expect 1-2 more breaking changes before the spec stabilizes (~2027). Gateways that track spec changes closely (AG, Envoy AI Gateway monthly releases) will handle this better.

A2A: Earlier in lifecycle. Donated to Linux Foundation June 2025. v0.3 added gRPC support. Expect significant evolution through 2027. Currently only two gateways support it (AG, ContextForge).

Convergence: MCP (agent→tool) and A2A (agent→agent) will likely remain separate protocols but with shared infrastructure. The gateway is the natural convergence point.

Strategic Risk Assessment#

Agent Gateway (LF/Solo.io)#

Trajectory: ↑ Strong upward

• Linux Foundation governance eliminates single-vendor risk
• Multi-vendor contributor base (AWS, Cisco, IBM, Microsoft, Red Hat, Apple) — broadest of any gateway
• Rust performance provides long-term scaling headroom
• Only gateway with MCP + A2A + LLM support

Risk Factors:

• Not yet GA (v1.0.0-rc.2) — production adoption limited
• Rust barrier to community contributions (Go/Python alternatives may grow faster)
• Solo.io as primary maintainer — diversity of contribution matters more than diversity of announcement

5-Year Outlook: High probability of becoming the default open-source AI agent gateway. LF governance + multi-vendor backing + broadest protocol coverage is a strong combination. The API gateway parallel suggests AG will be to agent gateways what Envoy became to service meshes.

Vendor Risk: LOW (Foundation governance, Apache 2.0, multi-vendor)

IBM ContextForge#

Trajectory: → Stable

• Strong on protocol breadth (REST/gRPC alongside MCP/A2A)
• IBM backing provides stability but not community momentum
• Python ecosystem is accessible but performance-limited

Risk Factors:

• Single-vendor (IBM) without foundation governance — if IBM deprioritizes, project may stall
• Python performance ceiling may limit enterprise adoption at scale
• Competing with AG on the same protocol coverage, without the governance advantage

5-Year Outlook: Likely remains viable for IBM ecosystem organizations and Python-first teams. May struggle to compete with AG for mindshare as AG reaches GA. Best chance: get donated to a foundation (LF, CNCF) to establish vendor-neutral positioning.

Vendor Risk: MEDIUM (IBM-backed, Apache 2.0, but single-vendor governance)

Kong AI Gateway#

Trajectory: → Stable with incremental growth

• Massive existing install base provides inertia
• Enterprise features unmatched by any open-source alternative
• MCP is incremental add-on, not core value proposition

Risk Factors:

• No A2A support — if agent-to-agent communication becomes essential, Kong falls behind
• MCP support via plugins may lag spec changes vs native implementations
• Commercial licensing for enterprise features creates cost burden

5-Year Outlook: Strong for organizations already on Kong. Will not lead the agent gateway category but will remain relevant as an MCP-capable general-purpose API gateway. The “add MCP to your existing Kong” value proposition is compelling for enterprises with sunk investment.

Vendor Risk: LOW-MEDIUM (Kong Inc is stable, Apache 2.0 core, but enterprise features are commercial)

Envoy AI Gateway#

Trajectory: ↑ Moderate upward

• Built on Envoy’s proven foundation (CNCF graduated project)
• Strong in Istio/Envoy shops
• CEL-based authorization is technically elegant

Risk Factors:

• MCP-focused, no A2A — same limitation as Kong
• Envoy’s complexity is a barrier to adoption
• CNCF governance is an advantage but Envoy AI Gateway is a sub-project, not a top-level project

5-Year Outlook: Will likely become the default MCP gateway for Envoy/Istio users. May not compete broadly with AG for greenfield deployments. Strength is in the existing service mesh integration story.

Vendor Risk: LOW (CNCF governance via Envoy, Apache 2.0)

Docker MCP Gateway#

Trajectory: → Stable, development-focused

• Docker brand provides developer trust
• Rapid release cadence shows strong investment
• Focused on DX over governance

Risk Factors:

• Docker Desktop dependency limits deployment flexibility
• Not positioned for production governance use cases
• Docker Inc’s financial trajectory uncertain long-term

5-Year Outlook: Will remain the best option for local development and prototyping. Not a production governance platform and likely won’t evolve into one — Docker’s strategy is developer workflow, not infrastructure governance.

Vendor Risk: MEDIUM (Docker Inc, MIT license, but tied to Docker ecosystem)

Transport Proxies (Supergateway, mcp-proxy)#

Trajectory: ↓ Declining relevance

• Solved an early problem (stdio↔HTTP) that full gateways now handle
• Supergateway’s maintenance appears to be slowing (last update Oct 2025)
• No governance features limits long-term utility

5-Year Outlook: Will be largely absorbed by full gateway products. The transport bridging problem is solved; the governance problem is the new frontier. Still useful for minimal setups, but not strategic investments.

Vendor Risk: HIGH (individual maintainers, no governance)

Strategic Recommendations#

The Safe Bet: Agent Gateway#

For organizations making a strategic investment in AI agent infrastructure, Agent Gateway is the lowest-risk choice:

• Foundation governance eliminates vendor lock-in
• Broadest protocol coverage handles current and future needs
• Multi-vendor backing signals long-term commitment
• Rust performance provides scaling headroom

When to wait: If you need GA stability guarantees and can’t tolerate RC-level software. Kong is the only GA option with meaningful MCP support.

The Pragmatic Bet: Your Existing Gateway + AG Later#

For organizations with existing API gateway infrastructure:

1. Add MCP support to your current gateway (Kong plugins, Envoy AI Gateway)
2. Evaluate Agent Gateway when it reaches GA
3. Migrate to AG when A2A becomes a requirement

This avoids premature investment while keeping the door open for the likely winner.

The Build-Nothing Bet: Transport Proxy + Revisit in 12 Months#

For organizations in evaluation phase:

1. Deploy a transport proxy (mcp-proxy, Supergateway) for immediate needs
2. Revisit gateway landscape when AG reaches GA (~Q2-Q3 2026)
3. The market will be clearer by then, with fewer options and proven patterns

Emerging Patterns to Watch#

Agent Identity & Discovery#

AGNTCY’s identity and discovery standards are complementary to the gateway layer. Watch for convergence between AG’s traffic management and AGNTCY’s identity framework. The agent equivalent of “service mesh + service registry” is forming.

Policy-as-Code for AI Agents#

Three policy languages competing for the AI agent space:

• OPA (Rego): Broadest ecosystem, already integrated with AG and Kong
• Cedar (AWS): Formal verification properties, purpose-built cedar-for-agents
• CEL: Fastest evaluation, integrated with Envoy AI Gateway

No clear winner yet. OPA has the ecosystem advantage; Cedar has the formal methods advantage. Watch which gateway adopts which.

The MCP Auth Resolution#

The MCP OAuth 2.1 spec is contentious and evolving. The gateway-handles-auth consensus may lead to formal spec changes — potentially an “MCP Gateway” spec extension that standardizes the gateway-to-server auth delegation pattern. Watch the MCP spec repository for related proposals.

Multi-Protocol Convergence#

Agent Gateway and IBM ContextForge both support MCP + A2A, but from different directions (AG: performance-first with Rust; ContextForge: breadth-first with Python). The market will likely converge on one approach. AG’s LF governance gives it the edge, but ContextForge’s REST/gRPC bridging capability addresses a real enterprise need AG doesn’t yet cover.

Sources#

• Gartner AI Agents Prediction: gartner.com/en/newsroom/press-releases/2025-08-26 (accessed March 2026)
• Grand View Research AI Agents Market: grandviewresearch.com/industry-analysis/ai-agents-market-report (accessed March 2026)
• Linux Foundation A2A Launch: linuxfoundation.org/press (accessed March 2026)
• Google Cloud AI Agent Trends: cloud.google.com/resources/content/ai-agent-trends-2026 (accessed March 2026)
• Lyzr State of AI Agents 2026: lyzr.ai/state-of-ai-agents/ (accessed March 2026)
• CNCF Envoy Gateway project: gateway.envoyproxy.io (accessed March 2026)
• API gateway market history: analyst reports from Gartner, Forrester (2015-2020)
• Cedar for Agents: github.com/cedar-policy/cedar-for-agents (accessed March 2026)
• AGNTCY documentation: docs.agntcy.org (accessed March 2026)