What is an MCP proxy? The definitive guide

The rise of autonomous AI agents in the enterprise is creating a new and often invisible infrastructure layer. As developers connect these agents to more internal and external tools, from databases and APIs to specialized SaaS products, a hidden shadow AI emerges. This uncontrolled proliferation of connections, a problem we call “MCP server sprawl,” creates massive security and governance blind spots. Organizations are deploying powerful agents with little to no insight into which tools they are using, what data they are accessing, or how they are being controlled.

This shift mirrors a familiar pattern. Just as API gateways became essential for managing the explosion of REST APIs and microservices, a new control plane is required to manage the interactions between agents and their tools. The MCP proxy is that critical control plane. It sits between AI agents and the MCP servers they consume, providing a single point of security, governance, and observability.

This guide is for enterprise architects, security engineers, and engineering leads responsible for deploying AI agents securely and at scale. It provides a comprehensive breakdown of: 

• What an MCP proxy is
• The critical problems it solves
• Its core technical architecture
• A strategic framework for implementing a governance strategy around it

What is an MCP proxy?

An MCP proxy is a centralized intermediary service that securely manages, routes, and monitors all communication between AI agents and the MCP servers they use. Its primary function is to act as a single, policy-driven entry point for all tool-related traffic, abstracting the complexity of the underlying MCP server ecosystem from the agent itself.

A direct definition

An MCP proxy is a centralized intermediary that intercepts every MCP request (tool discovery, tool execution, resource reads, and prompt retrieval) between an AI agent (the MCP host) and the MCP servers it uses. By sitting on the JSON-RPC 2.0 data layer that MCP runs on, it enables consistent enforcement of security and governance policies across an entire fleet of agents and servers. The term MCP stands for Model Context Protocol, the open standard published by Anthropic that defines how AI applications discover and interact with external context sources and capabilities.

A note on terminology

The official MCP specification uses the term “MCP proxy server” in a narrower sense, meaning an MCP server that connects MCP clients to a third-party API and acts as a single OAuth client to that API. In this guide, “MCP proxy” refers to the broader governance and control-plane pattern, meaning a gateway that sits in front of many MCP servers. Some teams call this an “MCP gateway” to avoid ambiguity. Both senses of the term are common in the wild, and the security concerns the specification raises about the narrower pattern (notably the confused deputy problem) apply equally to the broader one.

The API gateway analogy for AI agents

An MCP proxy is to AI agents what an API gateway is to microservices and REST APIs. This analogy provides a familiar mental model for platform teams and enterprise architects. Just as an API gateway centralizes cross-cutting concerns for API traffic, an MCP proxy does the same for agent-tool traffic. This includes parallel functions such as centralized authentication, rate limiting, traffic routing, policy enforcement, and deep observability. It transforms a chaotic, point-to-point mesh of connections into a managed, secure, and observable network.

Key responsibilities of an MCP proxy

An enterprise-grade MCP proxy serves as a critical control plane with four main responsibilities:

• Security: It enforces authentication and authorization for every request, ensuring that only trusted agents can access specific, approved tools. Critically, it ensures tokens are validated for the correct audience; the MCP specification explicitly forbids token passthrough, where a proxy or server accepts a token that was not issued specifically to it.
• Governance: It acts as a single point of control for auditing all agent activity. The proxy logs every tools/call, the arguments passed, and the result returned, creating an immutable audit trail for compliance and security forensics.
• Orchestration: It intelligently routes agent requests to the correct upstream MCP servers. This includes managing different versions of tools, combining multiple MCP servers into a unified namespace, and abstracting backend complexity.
• Resilience: It protects backend services from being overwhelmed. The proxy provides essential capabilities like caching for deterministic tool calls, rate limiting to prevent abuse, and circuit breaking to handle failures gracefully.

By centralizing these functions, an MCP proxy provides the control and visibility necessary to manage agent-based systems in production environments.

Why direct MCP connections fail in enterprise environments

Directly connecting AI agents to a growing number of MCP servers creates significant security vulnerabilities and operational burdens that are untenable in an enterprise setting. This approach leads to a decentralized and unmanageable ecosystem where risks multiply and visibility disappears, effectively preventing a secure and scalable AI strategy.

The MCP server sprawl problem

In the early stages of AI adoption, teams often deploy their own MCP servers to expose internal tools or APIs to their agents. Without central oversight, this leads to MCP server sprawl. Multiple teams build and deploy dozens of servers, each with its own security model, authentication mechanism, and logging format. The consequences are severe:

• Inconsistent security: Different servers have different security postures, creating weak links in the chain.
• Duplicated effort: Teams reinvent the wheel, building the same boilerplate for auth, logging, and rate limiting.
• No visibility: The platform team has no way to know which agents are using which tools, what data is flowing, or how much it’s costing.
• Massive attack surface: Every new MCP server is another potential entry point for an attacker.

This sprawl creates a shadow AI infrastructure that is impossible to govern, secure, or operate efficiently.

Critical security risks of unproxied connections

The MCP specification’s Security Best Practices document calls out a specific set of attacks that target agent-to-server interactions. Unproxied, point-to-point connections leave each MCP server responsible for mitigating these on its own, inevitably with inconsistent results.

The most consequential threats are:

Token passthrough 

Explicitly forbidden by the MCP authorization specification, this anti-pattern occurs when an MCP server accepts a token from a client without validating that the token was issued specifically to that server, and then forwards it to a downstream API. The risks are severe. It circumvents audience-based security controls, breaks audit trails (downstream logs show the wrong identity), and turns a compromised server into a ready-made data-exfiltration relay for any stolen token. 

The specification’s rule is absolute: An MCP server MUST NOT accept tokens that were not explicitly issued for it. Without a proxy enforcing audience validation as a gateway-level policy, the burden falls on every individual MCP server team to implement this correctly.

Confused deputy

This attack targets MCP servers that act as a single OAuth client to a third-party API. If such a server uses a static client ID upstream while allowing MCP clients to dynamically register with their own client IDs, an attacker can exploit a user’s existing consent cookie on the third-party authorization server. By sending the victim a crafted link with a malicious redirect URI and a newly registered client ID, the attacker causes the third-party server to skip the consent screen (because the cookie is still valid for the static client ID) and redirects an authorization code to the attacker. The specification requires per-client consent storage, strict redirect-URI validation, and proper OAuth state handling to defeat this attack.

Server-Side Request Forgery (SSRF)

During OAuth metadata discovery, an MCP client fetches URLs from sources that a malicious MCP server controls: 

• The resource_metadata URL from the WWW-Authenticate header
• The authorization_servers URLs from the Protected Resource Metadata document
• The endpoint URLs in Authorization Server Metadata. 

A malicious server can populate these with URLs pointing to internal IPs, cloud metadata endpoints (169.254.169.254), localhost services, or domains that DNS-rebind to internal addresses, exfiltrating cloud credentials or bypassing the network perimeter. Mitigations include enforcing HTTPS, blocking private IP ranges per RFC 9728 Section 7.7, validating redirect targets, and routing all outbound MCP traffic through an egress proxy.

Session hijacking

MCP defines two specific session-hijack patterns: 

• In session hijack impersonation, an attacker who obtains a session ID makes calls directly to the server, which (if it relies on session IDs alone for authorization) treats them as a legitimate user. 
• In session hijack prompt injection, an attacker uses a stolen session ID to inject a malicious event into a shared queue between stateful servers. The original client later receives the malicious payload as an asynchronous or resumed response. 

The specification’s mitigations are strict: MCP servers MUST verify all inbound requests, MUST NOT use sessions for authentication, MUST use cryptographically random session IDs, and SHOULD bind session IDs to user-specific information (e.g. a <user_id>:<session_id> key format).

Scope inflation

When MCP servers expose every scope in scopes_supported and clients request all of them upfront, a single compromised token grants lateral access across tools, audit logs lose the ability to distinguish user intent, and revoking access disrupts every workflow at once. The specification recommends a progressive, least-privilege model with minimal initial scopes, incremental elevation via WWW-Authenticate scope=”…” challenges when privileged operations are first attempted, and explicit avoidance of wildcard or omnibus scopes.

Local MCP server compromise

Local MCP servers run as binaries on the user’s machine, often launched via one-click client configuration. Without proper sandboxing and pre-execution consent, malicious startup commands can exfiltrate data, escalate privileges, or destroy files. Clients that support one-click configuration MUST display the exact command to be executed, identify it as a potentially dangerous operation, and require explicit consent.

Beyond these spec-documented attacks, an unproxied architecture is also vulnerable to supply-chain risks: an agent connected directly to a public MCP server has no central inspection point to detect malicious tool descriptions, anomalous argument patterns, or unexpected outbound destinations.

The operational nightmare of decentralized management

Without a central proxy, managing the security and lifecycle of agent-tool connections becomes an operational nightmare. Every time a credential needs to be rotated, a security policy updated, or a tool deprecated, engineers must manually update the configuration of every single agent that connects to it. There is no central audit log, making it impossible to answer critical governance questions, such as: “Which agent accessed the production CRM tool last night and with what arguments?” 

This lack of a centralized control plane makes scaling AI agents beyond small experiments operationally infeasible. The security and operational failures also make a compelling case for a centralized enforcement point.

How an MCP proxy works: A technical breakdown

An MCP proxy operates as an intelligent and policy-aware intermediary, managing the entire lifecycle of an agent’s interaction with its MCP servers. The architecture is designed to intercept, inspect, and forward JSON-RPC 2.0 traffic according to a centrally managed set of rules, providing a secure and observable communication channel.

The end-to-end request flow

A typical request flows through the proxy in a series of well-defined steps:

1. Connection initiation: The AI agent (the MCP host, via its MCP client) initiates a connection to the MCP proxy’s single, well-known endpoint, rather than connecting directly to dozens of different upstream MCP servers.
2. Initialization and capability negotiation: The client sends an initialize request declaring its supported features and protocol version. The proxy responds with the capabilities it (and, by extension, its upstream servers) supports. This handshake is mandatory in MCP and establishes the contract for the session.
3. Authentication: The proxy authenticates the request using a bearer token in the Authorization header. MCP’s authorization specification builds on OAuth 2.1, with the proxy acting as the Protected Resource and validating that the token’s audience (aud claim) matches its configured resource URL.
4. Tool discovery: The agent sends a tools/list request to enumerate available tools. The proxy filters the returned list based on the agent’s identity and granted scopes, so the agent only sees the tools it is authorized to invoke.
5. Tool execution request: When the agent invokes a tool, it sends a tools/call request with a name and arguments payload. (Equivalent methods exist for other MCP primitives: resources/list and resources/read for resources, prompts/list and prompts/get for prompts.)
6. Policy enforcement: The proxy validates the request against its configured policies – rate limits, scope requirements for the specific tool, argument sanitization rules, and data governance constraints.
7. Secure routing: Once validated, the proxy looks up the appropriate upstream MCP server in its service registry and forwards the request, attaching the correct audience-scoped credentials for that server (never passing the original client token through, which the specification forbids).
8. Audit logging: The proxy logs the full transaction – the agent identity, the tool name, the arguments, the response, latency, and any policy decisions made along the way.
9. Response forwarding: The proxy returns the result to the agent. If the upstream server emits notifications (such as notifications/tools/list_changed), the proxy forwards them and re-applies its filtering policy.

This structured flow ensures that no MCP interaction occurs without passing through a security and governance checkpoint.

Transport handling

Under the current MCP specification, there are two transport mechanisms an MCP server can use:

• Stdio transport: Standard input/output streams for direct process communication. This is used by local MCP servers that run on the same machine as the host (for example, Claude Desktop launching a local filesystem server as a subprocess). There is no network overhead.
• Streamable HTTP transport: This uses HTTP POST for client-to-server messages, with optional Server-Sent Events (SSE) for streaming server-to-client responses. This is the transport used by remote MCP servers. It supports standard HTTP authentication, with OAuth 2.1 bearer tokens being the recommended mechanism.

Note on legacy transports

Earlier versions of MCP defined a separate “HTTP+SSE” transport. This has been superseded by Streamable HTTP, which folds streaming into the standard HTTP transport via optional SSE. References to a standalone “SSE transport” in older content refer to this deprecated mechanism.

An enterprise MCP proxy needs to handle both transports. A common pattern is for the proxy to expose a single Streamable HTTP endpoint to agents while connecting to a mix of upstream servers, some over Streamable HTTP and some launched locally over stdio. The proxy abstracts these differences, so agents see a unified set of tools regardless of how the underlying servers are deployed.

Core capabilities of an enterprise-grade MCP proxy

An enterprise-grade MCP proxy provides a rich set of features far beyond simple request forwarding. These capabilities are essential for deploying AI agents in production environments that demand high levels of security, governance, and reliability.

Centralized authentication and audience-scoped tokens

The proxy serves as the primary security checkpoint for all agent-to-server interactions. It offloads the burden of authentication from individual MCP servers and enforces a consistent security model across the entire ecosystem.

• OAuth 2.1 alignment: MCP authorization is built on OAuth 2.1, with Protected Resource Metadata (RFC 9728), Authorization Server Metadata (RFC 8414) or OpenID Connect Discovery, and Resource Indicators (RFC 8707) as the supporting standards. For client registration, the current specification recommends Client ID Metadata Documents (CIMD), with Dynamic Client Registration (RFC 7591) retained as a backwards-compatibility fallback. An enterprise proxy implements the Protected Resource side of this contract.
• Audience enforcement (anti-passthrough): The proxy validates the aud claim of every inbound token to ensure it was issued specifically for this proxy. When calling an upstream MCP server, it requests a fresh token scoped to that upstream’s audience rather than passing the client token through. This single discipline closes off the entire class of token-passthrough attacks.
• Role-Based Access Control (RBAC): Beyond protocol-level auth, a proxy enables granular access policies based on agent identity, group membership, or assigned roles. A policy can state, for example, that “agents in the finance-bots group may invoke any tool whose name begins with sap., but no others.” You can learn more about securing services with Tyk’s OAuth 2.1 support.

Least-privilege scopes

A well-designed proxy enforces progressive scope elevation, in line with the specification’s scope minimization guidance:

• Minimal initial scopes for discovery and read-only operations (something like mcp:tools-basic).
• Incremental elevation via WWW-Authenticate: Bearer scope=”…” challenges when an agent attempts a privileged operation for the first time, rather than requesting all possible scopes upfront.
• No wildcard scopes. Patterns such as *, all, or full-access are anti-patterns. They bundle unrelated privileges and turn any compromised token into a master key.

Tool orchestration and namespace management

In a large enterprise, hundreds of tools may be available across many MCP servers. The proxy helps manage this complexity by orchestrating how they are presented to agents.

• Unified namespace: The proxy can combine multiple upstream MCP servers into a single, unified tool namespace. The agent sees one logical catalog while the proxy handles routing to the correct physical server.
• Prefix-based routing: A common orchestration pattern is routing based on tool name prefixes. For instance, all requests for tools starting with crm. can be automatically routed to the Salesforce MCP server, while billing. requests go to the Stripe server. This enables logical grouping and delegates ownership to the appropriate teams.

Deep observability and audit logging

To govern AI agent behavior, you must be able to see exactly what they are doing. The proxy provides this deep observability.

• Argument-level logging: It’s not enough to log that a request was made. An MCP proxy logs the JSON-RPC method (e.g. tools/call), the tool name, and the full arguments payload. This is crucial for security audits and for debugging unexpected agent behavior.
• Notification logging: MCP includes notifications such as notifications/tools/list_changed that can dynamically alter which tools an agent sees mid-session. The proxy should log these, since they can be a vector for tool-set manipulation if an upstream server is compromised.
• Integration with observability platforms: The proxy should export detailed metrics to standard platforms like Prometheus, Datadog, or systems supporting OpenTelemetry. This enables monitoring of KPIs such as latency per tool, error rates, scope-elevation events, and token usage.

Performance, caching, and rate limiting

While any intermediary adds a small amount of network latency, a well-designed MCP proxy includes features that can significantly improve overall system performance and resilience.

• Caching: For tools that are deterministic (i.e. they return the same output for the same input), the proxy can cache responses. Repeated calls to a currency-conversion tool, for example, can be served from cache after the first call.
• Rate limiting: This is essential for protecting sensitive or expensive upstream tools. A policy can be set to limit an agent to 10 calls per minute to a paid data API, preventing a faulty or malicious agent from running up a huge bill or causing a denial-of-service event.
• Connection pooling: The proxy can maintain a pool of warm, ready-to-use connections to upstream servers, avoiding TCP and TLS setup overhead on every request.
• Session hardening: When the proxy itself maintains MCP sessions, session IDs must be cryptographically random and bound to authenticated user identity. They must never used as the sole means of authorization, in line with the specification’s session hijacking mitigations.

These capabilities transform the proxy from a simple gatekeeper into a sophisticated management and performance-tuning layer.

MCP proxy vs API gateway: Key differences and similarities

While the analogy is powerful, it’s important for architects to understand the specific distinctions between an MCP proxy and a traditional API gateway. They share a common philosophical purpose but are optimized for fundamentally different protocols and interaction patterns.

Shared DNA: The control plane concept

Both an MCP proxy and an API gateway are implementations of a control plane. They act as a centralized policy enforcement point for network traffic, providing a single entry point for clients and handling cross-cutting concerns.

• Single entry point: Both abstract a complex backend of many services into one manageable endpoint.
• Policy enforcement: Both are responsible for applying security, traffic management, and observability policies.
• Decoupling: Both decouple clients from services, allowing backend systems to be changed or updated without affecting the clients.

This shared DNA is why platforms such as the Tyk API Gateway, a battle-tested solution for API management, are a natural foundation for building out MCP proxy capabilities. To learn more, see our foundational guide on what an API gateway is.

Where they differ: Protocol and payload

The primary difference between an MCP proxy and a traditional API gateway lies in the specific protocols and payload structures they are designed to understand and manage.

• API gateways are purpose-built for synchronous, request-response communication, primarily over HTTP/REST. They have a deep, native understanding of HTTP concepts including verbs (GET, POST), paths, headers, and query parameters. Their policies are often built around manipulating these elements. Payloads are typically structured as JSON or XML.
• MCP proxies are designed for the Model Context Protocol, which runs on JSON-RPC 2.0. They must natively understand MCP’s lifecycle (initialize, capability negotiation), primitives (tools/list, tools/call, resources/list, resources/read, prompts/list, prompts/get), and notifications (notifications/tools/list_changed and others). Their policies must inspect and act on JSON-RPC fields including method, params.name, and params.arguments. They must also handle both MCP transports (stdio for local servers and Streamable HTTP for remote ones) and bridge between them where needed.

This specialization allows an MCP proxy to provide much deeper and more context-aware governance for AI agent traffic than a generic API gateway could.

Getting started: A conceptual MCP proxy implementation

While an enterprise-grade MCP proxy is a complex piece of infrastructure, the core routing logic is straightforward to understand. This conceptual example is designed to bridge the gap between the technical details and the strategic need, illustrating the fundamental principle of how a proxy operates. It is for demonstration purposes and not for production use.

The goal: Bridging the technical and strategic gap

By showing the core mechanism in a few lines of code, engineers can grasp the concept, and security leaders can see how this simple pattern becomes the foundation for a robust governance strategy. The code demonstrates how multiple, disparate MCP servers can be unified behind a single, manageable entry point.

A simple Python example

This short, commented snippet uses a hypothetical proxy library to demonstrate the core proxying and namespace mounting functionality. In practice, you would build this on top of an MCP SDK and an OAuth 2.1 resource-server library.

# A conceptual example of a simple MCP proxy.

# Note: ‘MCPProxy’ here is hypothetical; real implementations build on the

# official MCP SDKs (https://modelcontextprotocol.io/docs/sdk).

from hypothetical_proxy import MCPProxy, MCPUpstream

# 1. Define two upstream MCP servers that agents might use.

#    One is a remote server reached over Streamable HTTP;

#    the other is a local tool launched over stdio.

weather_server = MCPUpstream(

    target=”https://weather-service.internal/mcp”,

    transport=”streamable-http”

)

calculator_server = MCPUpstream(

    target=”./local_calculator_tool”,

    transport=”stdio”

)

# 2. Instantiate the central MCP proxy. This is the single Streamable HTTP

#    endpoint that all AI agents will connect to.

proxy = MCPProxy(host=”0.0.0.0″, port=9000)

# 3. Mount the upstream servers under named prefixes. Incoming `tools/call`

#    requests are routed by the prefix on the tool’s `name` field:

#    e.g. a call to `weather.get_current_temp` is routed to weather_server;

#    a call to `calc.add` is routed to calculator_server. The proxy also

#    bridges between transports as needed.

proxy.mount(prefix=”weather”, upstream=weather_server)

proxy.mount(prefix=”calc”, upstream=calculator_server)

# 4. Configure OAuth 2.1 audience validation. The proxy will reject any

#    token whose `aud` claim does not match its own resource URL – this

#    is the audience check that prevents token-passthrough abuse.

proxy.require_audience(“https://mcp-proxy.example.com”)

# 5. Start the proxy server.

print(“MCP Proxy is running on port 9000…”)

proxy.run()

From concept to production

A production-ready solution builds directly on this core concept. It wraps this simple routing logic with essential enterprise modules for:

• OAuth 2.1 token validation with strict audience checking (aud claim).
• Protected Resource Metadata served at /.well-known/oauth-protected-resource per RFC 9728.
• Deep audit logging of every JSON-RPC method, including tools/call arguments and notifications/tools/list_changed events.
• Dynamic configuration management from a central control plane.
• Progressive scope enforcement, returning WWW-Authenticate challenges with the specific scope required when an agent first attempts a privileged operation.
• SSRF protections on outbound metadata-discovery requests (HTTPS enforcement, private IP blocking, redirect-target validation).
• Session hardening with cryptographically random IDs bound to authenticated user identity.

This is precisely what a platform such as Tyk provides, taking the core proxying pattern and hardening it with the security, reliability, and manageability features required for enterprise workloads.

The three-tier maturity model for MCP governance

Adopting and implementing an MCP proxy strategy is a journey, not a single event. Organizations can follow a progressive maturity model to scale their governance capabilities from basic control to a sophisticated, automated ecosystem. This approach allows teams to realize immediate benefits while building towards a long-term strategic vision.

Tier 1: Centralized visibility and control

The initial goal is to eliminate the immediate security risks and operational chaos of MCP server sprawl. This tier focuses on establishing a single source of truth and a baseline of security for all agent-to-server interactions.

• Goal: Eliminate the shadow AI infrastructure and gain full visibility.
• Actions:
  • Deploy a single, central MCP proxy.
  • Onboard all existing, disparate MCP servers as upstreams behind the proxy.
  • Mandate that all new agents and servers must connect through the proxy.
  • Implement OAuth 2.1 authentication and audience validation on every request – no token passthrough.
  • Enable comprehensive audit logging of every JSON-RPC method invocation, including tools/call arguments.

Tier 2: Policy enforcement and orchestration

With visibility established, the next step is to implement granular, automated governance rules that enforce business and security policies.

• Goal: Implement fine-grained, automated control over tool access and usage.
• Actions:
  • Introduce Role-Based Access Control (RBAC) to restrict tool access based on agent identity or team affiliation.
  • Implement least-privilege scope policies with progressive elevation via WWW-Authenticate challenges and deprecate any catch-all scopes.
  • Add rate limiting and quotas on expensive or sensitive tools to prevent abuse and control costs.
  • Use namespace management to create logical tool catalogs for different business units, simplifying discovery and management.
  • Begin integrating proxy logs with SIEM (Security Information and Event Management) systems.

Tier 3: Distributed trust and advanced security

At the highest level of maturity, the MCP governance model supports a secure, federated ecosystem where trust can be established between different domains, and security becomes proactive rather than reactive.

• Goal: Enable a secure, federated, many-to-many ecosystem with automated threat detection.
• Actions:
  • Deploy multiple, trusted MCP proxies that can securely communicate with each other, enabling inter-departmental or even inter-company agent collaboration.
  • Implement advanced threat detection, with anomaly detection on tools/call arguments to identify potential prompt injection or data exfiltration attempts. Flag unusual notifications/tools/list_changed patterns that could indicate tool-catalog tampering.
  • Integrate the proxy with automated incident response systems, so that a detected threat can automatically trigger a policy change, like revoking an agent’s credentials.

Frequently asked questions

What is the difference between an MCP proxy and a reverse proxy?

An MCP proxy is a specialized, application-aware gateway designed specifically for the Model Context Protocol. It understands JSON-RPC 2.0 methods like tools/call, the structure of arguments, MCP’s lifecycle (initialize and capability negotiation), and MCP’s notifications. A reverse proxy, on the other hand, is a generic layer 7 gateway that forwards HTTP traffic and is unaware of the underlying application logic or MCP-specific payloads it’s transmitting.

Does an MCP proxy add latency to AI agent responses?

Yes, any intermediary service like an MCP proxy introduces a small amount of network latency. However, enterprise-grade proxies are designed to mitigate this with high-performance architectures and optimizations like connection pooling. Furthermore, they can often reduce overall system latency by caching responses from deterministic tools, serving results faster than the backend ever could.

Can you use an API gateway as an MCP proxy?

You could configure a modern API gateway to route the underlying network traffic of MCP, but without significant custom development it would lack native understanding of the protocol. It wouldn’t parse tools/call arguments for deep logging, validate the aud claim of MCP bearer tokens in the way the specification requires, handle stdio-transport upstreams, or interpret notifications such as notifications/tools/list_changed. A dedicated MCP proxy, or an API gateway with first-class MCP support, is purpose-built for these tasks.

Why is OAuth 2.1 important for MCP proxies?

The MCP authorization specification is built on OAuth 2.1. It provides a standardized, secure framework for delegated authorization, with audience-scoped bearer tokens that prevent token passthrough, Protected Resource Metadata (RFC 9728) for client-side discovery, and PKCE-based authorization code flows for client authentication. Using these standards correctly is what allows an MCP proxy to act as a proper Protected Resource, including validating tokens, issuing scope-elevation challenges, and refusing tokens issued for a different audience.

How does an MCP proxy prevent data exfiltration by AI agents?

An MCP proxy helps prevent data exfiltration through multiple layers of defence. It enforces strict access controls so only authorized agents can communicate with approved MCP servers. It validates token audiences to prevent passthrough abuse – a key vector for using a compromised server as an exfiltration relay. It can inspect tools/call arguments against patterns that match sensitive data (credit card numbers, PII) and block matching requests. It applies SSRF protections to outbound metadata-discovery traffic. And it logs every JSON-RPC invocation, creating an immutable audit trail to detect, trace, and respond to malicious activity.

Conclusion

The shift to AI-driven, agent-based architectures requires a corresponding evolution in our approach to security and governance. As enterprises deploy more autonomous agents, the need for a dedicated control plane becomes undeniable. The MCP proxy is that essential layer.

As AI agents become more deeply integrated into core business processes, the MCP proxy will transition from an architectural best practice to a non-negotiable component of any secure and scalable enterprise AI platform. It is the control plane required to manage this new, dynamic world of autonomous systems.

To see how a unified API management platform can enforce these policies for both your APIs and AI agents, speak to the Tyk team.