OpenAI's Secure MCP Tunnel lets private servers talk to ChatGPT without opening your firewall

The thing stopping most enterprise teams from connecting their internal tools to hosted AI products has not been protocol support. MCP has been solid for a while. The real blocker has been the conversation with your security team when you ask them to open an inbound firewall rule so ChatGPT can call your internal tool server. That conversation usually ends with a no.

OpenAI shipped a direct answer to that problem on May 27, 2025. Secure MCP Tunnel is now generally available for enterprise customers, and the core idea is simple: your network never accepts an inbound connection. Your server never gets a public DNS record. OpenAI’s products connect to your private MCP server through a tunnel that your side initiates.

How it actually works

You run a small open-source daemon called tunnel-client inside whatever network already has access to your MCP server. That daemon opens an outbound HTTPS connection to OpenAI’s control plane and sits there long-polling for work. When ChatGPT or Codex needs to call one of your tools, the request arrives via that queued channel, tunnel-client forwards it to your local MCP server over your private network, and the response travels back through the same tunnel.

From your network’s perspective, this looks like any other outbound HTTPS call to api.openai.com:443. No new inbound rules. No NAT configuration. No public endpoint to maintain or monitor for external scanning.

The four OpenAI surfaces that can use it right now are ChatGPT web (via custom connector settings), Codex (giving your AI coding agent access to internal tools and APIs), the Responses API (for server-side agent workflows against private data), and AgentKit (for agent-builder access to internal systems).

What this means for your team

If you have an MCP server running on a laptop, a VM, a Kubernetes cluster, or anywhere inside a private network, and you want an OpenAI-hosted product to reach it without anyone signing off on a firewall change, this is the path.

Deployment is flexible. You can run tunnel-client as a Kubernetes sidecar next to your MCP server pod, as a dedicated deployment talking to a private Service, or as a systemd service on a VM. The daemon supports outbound HTTP proxies, custom CA bundles, and mTLS on both legs if you want stronger guarantees: control-plane traffic can route to mtls.api.openai.com, and the connection between tunnel-client and your internal server can also be mTLS-protected.

There are two separate API keys to keep in mind. CONTROL_PLANE_API_KEY is the runtime key for the long-running daemon (tunnel read/use scope). OPENAI_ADMIN_KEY is for tunnel management operations. OpenAI is explicit about keeping them separate. Reusing an admin key in a long-lived daemon expands your blast radius unnecessarily.

For observability, tunnel-client exposes /healthz, /readyz, and /metrics endpoints plus a lightweight admin UI at /ui. You can adjust log verbosity between debug, info, and warn at runtime without restarting the process.

The embedded Harpoon server and why it matters

One feature worth understanding before you deploy: tunnel-client embeds something called Harpoon, an MCP server that exposes a customer-configured set of allowlisted HTTP targets by label. This lets agent flows call a small, bounded set of private REST endpoints through the tunnel.

OpenAI is careful to note this is not a general-purpose proxy. Callers cannot pick arbitrary hosts. The targets, methods, and request/response size limits are all customer-configured. This is a deliberate constraint, not a limitation to work around. It keeps the blast radius of what an agent can reach through the tunnel well-defined, which is exactly what security teams want to see before approving any of this.

A note on OAuth

If your MCP server uses OAuth, the tunnel can carry the authorization server discovery metadata needed for browser-facing flows. That part works. What does not automatically tunnel is the authorization server itself. If your OAuth server is unreachable from the public internet and from the tunnel-client host, the OAuth flow can still fail even when the MCP server is reachable. Worth mapping this out before you go live.

How it compares to Anthropic’s approach

Anthropic launched a similar capability in research preview in May 2025, using the same outbound-only principle with a gateway component that adds an independent mTLS layer where Anthropic’s infrastructure cannot read payloads. It works with Claude Managed Agents and the Messages API. The meaningful difference right now is availability: Anthropic’s version requires requesting access and waiting. OpenAI’s Secure MCP Tunnel is GA for enterprise customers today.

The shared pattern across both vendors is clear: outbound-only connections, credentials held at the perimeter, vendor-managed polling loop. This is becoming the standard enterprise shape for agent-to-private-tool connectivity.

The honest trade-off

Secure MCP Tunnel removes one dependency (public inbound reachability) and replaces it with another: your private MCP server now requires OpenAI’s control plane to be reachable for any of this to work. If OpenAI’s infrastructure has an outage or your network cannot reach api.openai.com, the tunnel goes down and your agent workflows stop.

The tunnel also does nothing about prompt injection. If a hostile payload makes it into a tool response, tunnel-client passes it through faithfully. The security boundary here is network topology, not content.

For teams where the main blocker has been network policy rather than trust in OpenAI’s infrastructure, Secure MCP Tunnel is a clean solution. For teams with broader concerns about dependency on external control planes, that conversation is separate and worth having before you build workflows around this.

The open-source tunnel-client repo and the full documentation are both publicly available. Tunnel management for enterprise accounts is at platform.openai.com/settings/organization/tunnels.