MCP Tunnels: How OpenAI and Anthropic Bridge Cloud AI to Private Infrastructure
The problem: cloud AI needs to reach your private tools
If you use ChatGPT, Claude, Codex, or the Responses API, sooner or later your agents need to call tools that live inside your network — databases, internal APIs, CI pipelines, code repositories. You wrap them as MCP servers, and now you need a way for a cloud-hosted AI product to reach them.
At the same time, OpenAI and Anthropic are both pushing managed agents: cloud-hosted runtimes that run the reasoning loop on their infrastructure. The agent runs in their cloud, but the tools it calls live in yours. Someone has to bridge that gap.
The standard approach is to put an MCP Gateway in a DMZ — a reverse proxy that adds auth, RBAC, rate limiting, and audit logging between the cloud and your tools:
The problem is that inbound endpoint. The security track record for publicly exposed MCP servers makes it a hard sell:
- CVE-2025-49596: CSRF/DNS rebinding in MCP Inspector < 0.14.1 → arbitrary stdio command execution
- OWASP published a beta MCP Top 10 in March 2026
The attack surface isn't just the MCP server — it's everything the MCP server can reach.
The tunnel pattern: flip the direction
Instead of the cloud reaching into your network, a local agent reaches out. OpenAI and Anthropic both shipped this in May 2026. Same pattern:
- A tunnel agent runs inside your network, where it can already reach the MCP server
- It opens an outbound-only HTTPS connection to the provider's tunnel edge
- The provider routes MCP requests back through that connection
- The MCP server never gets a public endpoint and never accepts inbound connections
No inbound firewall rules, no public DNS, no IP allowlisting — the MCP server address never leaves your network.
OpenAI: custom tunnel-client with long-polling
A single Go binary (tunnel-client, Apache 2.0, v0.0.9) long-polls api.openai.com:443, pulls queued MCP JSON-RPC requests, forwards them to a local MCP server (stdio or Streamable HTTP), and posts responses back. SSE is supported for streamed results.
Setup is three commands: tunnel-client init → tunnel-client doctor → tunnel-client run. Tunnel identity is managed in Platform tunnel settings; RBAC splits "Tunnels Read + Use" (runtime) from "Tunnels Read + Manage" (admin).
tunnel-client also embeds Harpoon, a secondary MCP server for scoped HTTP callouts to private REST endpoints that haven't been wrapped in MCP. You configure allowed targets and request limits — it is not a general-purpose proxy.
Traffic goes outbound to api.openai.com:443 (default) or mtls.api.openai.com:443 (with control-plane mTLS). OAuth discovery travels through the tunnel, so the MCP server's authorization-server metadata is preserved. Health endpoints: /healthz, /readyz, /metrics, plus a local admin UI at /ui.
Anthropic: cloudflared + proxy on Cloudflare's network
Two components run inside your network. cloudflared is Cloudflare's tunnel agent — it opens outbound connections to the Anthropic-operated tunnel edge. A proxy (Anthropic's image) terminates inner TLS, validates upstream IPs, and routes requests to the right MCP server by hostname. Each server gets its own subdomain under your tunnel domain (e.g., docs.<your-tunnel-domain>).
The feature is beta (research preview) with no availability commitment — it depends on Cloudflare.
Authentication supports two modes:
- Workload Identity Federation (recommended) — short-lived tokens from your IdP, automatic CA cert management
- Manual — static tunnel token + server certificate signed by a CA you register
Deploy with the Helm chart (Kubernetes) or Docker Compose (single host / local testing). Provisioning traffic goes to api.anthropic.com:443; tunnel traffic goes to the Cloudflare edge (198.41.192.0/19) on port 7844 TCP+UDP.
How they compare
OpenAI ships one binary. Anthropic requires two containers. On operational simplicity alone, OpenAI has less to manage.
The security models diverge more than the architectures. Anthropic adds three layers — outer mTLS with IP validation, inner TLS that keeps Cloudflare from reading payloads, and per-server OAuth — with a documented shared responsibility model. OpenAI goes direct (no third-party transport) with a runtime API key and optional control-plane mTLS. Neither approach is objectively better; they optimise for different threat models.
On authentication, Anthropic supports Workload Identity Federation — short-lived tokens from your IdP, no static secrets to rotate. OpenAI uses runtime API keys. If your organisation already runs an OIDC issuer, WIF is a meaningful advantage.
OpenAI's Harpoon lets you make scoped HTTP callouts through the tunnel to private endpoints that aren't MCP servers. Anthropic has no equivalent.
Both are early. OpenAI ships without a beta label, but tunnel-client is at v0.0.9 with two contributors. Anthropic is explicitly beta/research preview, with no availability commitment and a Cloudflare dependency that carries no SLA for this use case.
Each tunnel works only with its provider. If you use both OpenAI and Anthropic products, you run both.
Why not just use an MCP Gateway?
An MCP Gateway (e.g. Microsoft's) is a reverse proxy that sits in front of your MCP servers and controls access: who can call which tool, with what credentials, under what rate limits, with full audit logging.
That's a different problem from what tunnels solve. A gateway answers "who is allowed to do what." A tunnel answers "how does traffic get here in the first place." If your MCP servers already live in the same network as the AI product calling them — same VPC, same cluster — a gateway is probably all you need.
But a gateway is an inbound service. It listens on a port, accepts connections from the internet, and forwards them to your tools. That means you need a public endpoint, a VPN, or IP allowlisting — and you need to get all of that right. Misconfigure the RBAC, miss a CVE, let a certificate expire, and you've handed the internet a direct path to your internal tools. The gateway itself becomes the attack surface.
Tunnels eliminate that surface entirely. There is no inbound port, no public endpoint, nothing to misconfigure from the outside. For teams running on-prem, in air-gapped environments, on developer laptops, or in private clusters — anywhere exposing an inbound port is impossible or unacceptable — tunnels are the simpler, safer choice.
The two are not competing. A gateway inside your network handles policy; a tunnel makes that gateway reachable from the cloud. You can run both.