Agentic Data Engineering Resources

Resource

MCP Proxy Server vs MCP Gateway

MCP proxies and gateways solve different production problems. Here is how to choose the right pattern for security, access, and operations.

Pedro Lopez

June 8, 2026

Last updated September 3, 2026

Summarize with AI:

Teams use "MCP proxy" to describe different components with different security boundaries, and "gateway" is just as slippery. That ambiguity matters once MCP agents move into production, because proxy and gateway decisions define different boundaries for authentication, access, observability, and operations.

Treating the terms as synonyms leads teams to compare architectures that solve different problems. The practical choice is not just about routing MCP traffic. It determines whether you are optimizing for aggregation and OAuth delegation, or for policy enforcement, auditability, tenant isolation, and centralized control over agent-to-tool access.

TL;DR

MCP proxies handle aggregation and OAuth delegation, while MCP gateways commonly add policy enforcement, observability, and multi-tenant control.
The term "MCP proxy" is used in multiple ways across the ecosystem, so teams need to determine which meaning a vendor or project intends before evaluating it.
Direct connections fit prototyping and small internal setups, proxies fit small production deployments needing aggregation and credential delegation, and gateways fit enterprise production with regulated data, multi-tenant agents, or heterogeneous auth requirements.
Proxies and gateways cover access and operational control, while row-level security, entity resolution, and schema-aware access control sit in the data infrastructure underneath.

How Do MCP Proxy Servers and MCP Gateways Compare?

The comparison starts with scope. A proxy usually focuses on forwarding, aggregation, and delegated authentication, while a gateway adds a control plane around access, policy, and operations.

Dimension	MCP Proxy Server	MCP Gateway
Spec status	An OAuth delegation intermediary defined in MCP security documentation	An architectural pattern not formally defined in the MCP specification
Primary function	Protocol translation, server aggregation, and credential delegation. It forwards requests between MCP clients and MCP servers and bridges transports.	A central point for MCP server access. It commonly enforces policy, governs access, and provides unified observability across agent-to-tool interactions.
Authentication	Centralized credential handling for third-party application programming interface (API) access on behalf of downstream MCP clients	Per-tool credential handling and lifecycle orchestration; often supports heterogeneous auth across different backend MCP servers
Access control	No per-tool or per-agent access control list (ACL) enforcement in the basic pattern; authenticated clients generally see the same tool catalog	Per-tool, per-agent access control lists (ACLs); filtered tool discovery where clients only see tools they are authorized to use; role-based access control (RBAC) for tool access
Multi-tenancy	Commonly single-tenant or shared-access	Tenant-scoped tool discovery, data routing, and permission enforcement via patterns such as Tenant-ID headers or namespace isolation
Observability and audit	Basic request forwarding logs; no structured audit trail in the basic pattern	Full audit trails, structured logging, Security Information and Event Management (SIEM) integration, per-tool latency metrics, and compliance-oriented observability are common gateway capabilities
Operational complexity	Low to moderate; can run as a single process or container with JSON-based configuration	Moderate to high; often involves Kubernetes, identity provider integration, policy engines, and dedicated operational overhead

Spec Status

An MCP proxy server, as defined in the MCP security best practices, connects MCP clients to third-party APIs, offers MCP features while delegating operations, and acts as a single OAuth client to the third-party API server. Gateway is an architectural pattern that the MCP specification does not formally define.

Primary Function and Architecture

A proxy forwards MCP requests, aggregates servers, and can participate in MCP's OAuth-based authentication flow. A gateway builds on that routing with policy decisions, tool registry management, and centralized control over which clients can call which tools.

Authentication Patterns

In the basic model, the MCP server manages credentials for underlying services while clients authenticate with the MCP server itself. When a server does not support Dynamic Client Registration under the MCP authorization specification, clients need an alternative way to obtain a client ID, such as a pre-registered or hardcoded value.

Access Control Granularity

Basic proxy patterns aggregate tool lists from backend servers, and authenticated clients generally see the same unfiltered catalog. Gateway patterns add per-tool and per-agent access control, so tool discovery can reflect the tools a client is authorized to use. MCP servers still enforce permissions on resources and tools before returning data to agents, which is why the gateway decision does not replace data-layer enforcement.

Multi-Tenancy Support

Gateway-style tenant separation is an implementation pattern rather than a formal MCP mechanism. In practice, gateway implementations separate tenants by scoping tools/list responses per tenant, using public versus authenticated catalogs for visibility, and injecting Tenant-ID headers so downstream systems receive tenant identity with each request.

Observability and Audit

Proxies produce application-level forwarding logs. Gateways often produce structured audit records that tie OAuth-derived fields to specific agent identities and specific tool calls. That difference matters when teams need incident reconstruction, tenant-level review, or evidence for controls around regulated data.

Operational Complexity Tradeoffs

A proxy can run as a single Docker container with a mounted JSON config file, and teams can launch it with npx or uvx. A gateway typically adds an identity provider, policy enforcement, and observability capabilities, and some platforms also deploy it on Kubernetes.

When Should You Choose a Proxy, a Gateway, or a Direct Connection?

The choice depends less on protocol purity and more on operational constraints. Teams should look at server count, tenant isolation, audit requirements, and whether authentication is uniform or mixed across the estate.

Decision Factor	Direct Connection	MCP Proxy	MCP Gateway
Number of MCP servers	1–3 servers per agent	4–15 servers needing aggregation	10+ servers with different auth models and ownership boundaries
Tenant model	Single-tenant; internal use only	Single-tenant or small number of known tenants	Multi-tenant SaaS; per-customer tool scoping required
Compliance requirements	Dev/test environments; no regulatory exposure	Basic audit logs sufficient	Full audit trails, SIEM integration, and compliance-oriented logging required
Security maturity level	Level 1, development and testing	Level 2, token + capability enforcement, container isolation, basic audit	Level 3, mutual TLS (mTLS) + token authorization, signed tool artifacts, centralized capability registry, incident-reconstructable logging
Team DevOps capacity	No dedicated infrastructure team	Can manage a proxy process or container	Can operate Kubernetes, identity providers, policy engines
Existing API gateway investment	None	Minimal; standalone proxy sufficient	Existing gateway infrastructure can be extended
Best for	Prototyping, local development, single-agent internal tools	Small production deployments needing server aggregation and credential delegation	Enterprise production with regulated data, multi-tenant agents, or heterogeneous auth requirements

Choose a direct connection for prototyping and small internal setups, a proxy for small production deployments that need aggregation and credential delegation, and a gateway when you need per-tool AI agent access control, multi-tenant scoping, or heterogeneous auth across many servers. Direct connections over stdio can work for prototyping with a small number of servers, and MCP reduces duplicated integration work when multiple teams would otherwise build separate connections.

Gateways become useful when teams need per-tool access control across multiple MCP servers, want to limit overly permissive token spread, or need one layer that can normalize heterogeneous authentication mechanisms. Those benefits come with added operational demands, which often include Kubernetes, an identity provider, policy enforcement, and a team that can operate them.

What Changes When MCP Servers Are Data Infrastructure?

When MCP servers connect to databases, warehouses, or pipeline tools, the proxy-versus-gateway decision gains data-layer constraints that require separate controls. Protocol routing decides who can call a tool, but it does not decide which rows, entities, or records the tool should return.

Row-Level Security Beyond Tool-Level ACLs

Tool-level ACLs decide whether an agent can call a tool, while Row-Level Security (RLS) decides which data that tool returns. Gateways cover tool access, and data infrastructure enforces the data returned by the tool. A gateway usually sits outside the database session, so database roles and session variables remain part of the data layer.

This distinction matters most in systems handling customer data, payment data, or health data. In those environments, teams usually care about auditability, tenant scoping, and permission boundaries for controls associated with SOC 2, HIPAA, and PCI DSS. The gateway can help with access and logging, but those controls still depend on what the database, warehouse, or pipeline layer enforces.

Entity Resolution Across Sources

A gateway can route requests and aggregate responses at the protocol level, but cross-system entity resolution requires a separate layer that understands whether records from separate systems refer to the same entity. An agent querying customer data across a CRM, a support platform, and a payment system through separate MCP servers may see three disconnected records that correspond to the same legal entity under different identifiers. Without a dedicated entity resolution layer, the agent either inflates totals or attempts fuzzy matching inside the model context window.

These are context engineering problems as much as protocol problems. They sit below gateway policy and above raw source connectivity, which is why teams often need both MCP access control and a governed data layer.

Which MCP Architecture Pattern Is Right for Your Team?

Use direct connections when the environment is small and temporary, use a proxy when you need aggregation and delegated auth without much platform overhead, and use a gateway when policy, audit, tenant isolation, and mixed authentication models become central operating requirements.

That still leaves the data layer underneath. If your agents depend on governed access to operational systems, warehouses, or pipelines, the proxy-versus-gateway decision does not remove the need for row-level permissions, entity resolution, and source-aware filtering.

Airbyte's agentic platform sits under the proxy-or-gateway decision as the data layer for AI agents whose agent connectors can optionally be exposed through MCP. Its agent connectors provide access to enterprise systems with typed methods, validation, and error handling, while Airbyte's Managed Auth handles OAuth flows, API keys, and token refresh across agent connectors. Airbyte's Context Store lets agents reason across unified records from connected sources rather than fragmented tool responses. Row-level and user-level ACLs enforce permissions at the data layer and filter data before it reaches the agent.

That matters because a gateway can control discovery and access, but it cannot by itself reconcile entities across systems or apply source-aware filtering before results reach the model. For teams building MCP-based agents on top of production data, Airbyte's agentic platform fits as the governed context layer beneath the proxy or gateway choice.

Talk to sales to learn whether Airbyte's agentic platform fits your production AI agent architecture, or try Airbyte's agentic platform today.

Frequently Asked Questions

Can an MCP proxy do everything an MCP gateway does?

A proxy handles protocol translation, server aggregation, and OAuth delegation in its basic form. Gateway capabilities commonly include per-tool ACLs, filtered tool discovery, multi-tenant isolation, per-tool token handling, and audit trails with agent identity attribution. In practice, a proxy can overlap with a gateway, but the terms usually point to different levels of control.

Does the official MCP specification define gateways?

Gateways are a vendor- and community-driven architectural pattern rather than a formal specification element. That is why teams should ask what a product means by "gateway" before comparing it to a proxy.

Is a generic HTTP reverse proxy sufficient for MCP traffic?

A generic reverse proxy is usually insufficient for MCP traffic. MCP uses JSON-RPC 2.0, and requests such as tools/list, tools/call, and initialize are typically sent as HTTP POSTs, often to a single /mcp endpoint using JSON content. Fine-grained policy enforcement usually requires body deserialization and method-level dispatch.

When does a direct MCP connection make sense over a proxy or gateway?

A direct MCP connection makes sense for prototyping, local development, and single-agent internal tools with 1–3 MCP servers running over stdio transport. The process boundary provides inherent isolation, and the connectivity problem stays manageable without an intermediary layer.

How do MCP gateways handle multi-tenant agent access?

Common patterns include filtered tool discovery, visibility-based access, and Tenant-ID header injection. Together, these scope tools/list responses per tenant and propagate tenant identity consistently to backend systems. The exact mechanism varies by implementation, but the goal is consistent tenant-aware routing and authorization.