OpenAI's Secure MCP Tunnel: Connect Private MCP Servers Over Outbound-Only HTTPS

OpenAI published a Secure MCP Tunnel guide that connects private and on-prem MCP servers to OpenAI products "without opening inbound firewall ports or exposing those servers to the public internet." The mechanism is a tunnel-client that makes outbound-only HTTPS connections: it "polls OpenAI for work, forwards MCP requests locally, and returns responses through the same tunnel."

This lands the same enterprise problem Anthropic addressed with MCP tunnels for Claude Managed Agents, and it pairs naturally with OpenAI's broader automation push around Codex hooks and programmatic access tokens. For where each vendor's agent runtime sits architecturally, our Codex CLI vs Claude Code vs Cursor comparison is the right anchor.

Key Takeaways

• Outbound-only HTTPS, no inbound ports. The tunnel-client long-polls an OpenAI-hosted endpoint, forwards JSON-RPC requests to the local MCP server, and posts responses back through the same connection.
• The private server stays internal. OpenAI's docs say the private MCP server address remains internal-only; OpenAI products talk to the OpenAI-hosted endpoint, not directly to your server.
• API-key auth with scoped permissions. A runtime key needs Tunnels Read + Use; optional manager credentials need Tunnels Read + Manage.
• Works with stdio and HTTP MCP servers. Use --mcp-command for stdio servers or --mcp-server-url for HTTP servers.
• ChatGPT, Codex, and API surfaces can all target a tunnel-backed MCP server per the docs.
• Enterprise networking is first-class. The docs cite outbound proxies, custom CA bundles, control-plane client certificates, and MCP-side mTLS.

What the Secure MCP Tunnel Is

OpenAI's Secure MCP Tunnel connects private MCP servers to OpenAI products without exposing those servers to the public internet. Instead of opening an inbound firewall port so OpenAI can reach your server, you run a client inside your network that reaches out to OpenAI. Per the docs, the client "polls OpenAI for work, forwards MCP requests locally, and returns responses through the same tunnel." The private server address never leaves your perimeter.

The result is a connectivity model security teams can sign off on: there is no public endpoint to defend, and all traffic to OpenAI originates as an outbound HTTPS request from inside the network.

How the Tunnel Works

The flow OpenAI documents has five steps. First, you create and manage an OpenAI-hosted tunnel endpoint in Platform settings. Second, you run tunnel-client inside your network where it can reach the private MCP server. Third, you configure the client with the tunnel identity and the server address. Fourth, OpenAI products send MCP requests to the OpenAI-hosted endpoint. Fifth, the client long-polls for queued work, forwards JSON-RPC requests locally, and posts responses back.

The data path is request-response over a persistent outbound channel. Because the client initiates the connection, the only network rule you add is outbound HTTPS to api.openai.com:443 (the default) or mtls.api.openai.com:443 when mTLS is enabled.

Prerequisites and Permissions

Per the docs, you need a tunnel_id from the Platform tunnel settings, a runtime API key carrying Tunnels Read and Use permissions, and a private MCP server reachable over stdio or HTTP. Tunnel-manager operations are separated out: managing endpoints uses credentials with Tunnels Read and Manage. The split keeps the credential that runs a tunnel distinct from the credential that creates or changes one.

Network-wise, the client needs outbound HTTPS to OpenAI and local reachability to the MCP server. Nothing inbound is required.

Setup Commands

The docs walk through initializing and running the client. The stdio path looks like this:

export CONTROL_PLANE_API_KEY="sk-..."

tunnel-client init \
  --sample sample_mcp_stdio_local \
  --profile local-stdio \
  --tunnel-id tunnel_0123... \
  --mcp-command "python /path/to/server.py"

tunnel-client doctor --profile local-stdio --explain
tunnel-client run --profile local-stdio

For an HTTP MCP server, swap --mcp-command for --mcp-server-url. The doctor subcommand validates a profile before you run it, and --explain prints why each check passed or failed.

Deployment Patterns and Integration

OpenAI documents three deployment shapes: a Kubernetes sidecar (tunnel-client beside the MCP server in one Pod), a dedicated Kubernetes deployment (the tunnel runs separately from the server), and a VM or systemd service at the host level. The right one depends on how your MCP servers already run.

On the product side, ChatGPT connects by creating a custom connector and selecting Tunnel under Connection. Codex and API flows can target a tunnel-backed MCP server from supported product surfaces. Endpoints are managed from Platform tunnel settings.

Security and Operations

The tunnel is built for enterprise network constraints. Per the docs, it supports outbound proxies, custom CA bundles, control-plane client certificates, and MCP-side mTLS, and OAuth discovery can traverse the tunnel while keeping the authorization-server requirements separate. The private MCP server address remains internal-only throughout.

For operations, the client exposes /healthz, /readyz, and /metrics endpoints plus a local admin UI at /ui showing health, readiness, metadata, and channel status. HTTP logging is disabled by default and support exports are redacted, which keeps request contents out of diagnostic bundles.

When to Use It

Reach for the Secure MCP Tunnel when an MCP server holds data or capabilities that cannot be published to the public internet -- an internal ticketing system, a database gateway, a code-search service behind the VPN -- and you still want ChatGPT or Codex to use it. The trade for that reach is running and monitoring a client process inside your network, scoping its API key to Tunnels Use, and treating the key like any other production secret.

Sources

• OpenAI Developers, "Secure MCP Tunnel" guide: https://developers.openai.com/api/docs/guides/secure-mcp-tunnels
• OpenAI Developers announcement post (May 27, 2026): https://x.com/OpenAIDevs/status/2059703536825565499