OpenAI Secure MCP Tunnels: Full Guide (2026)

One-sentence definition

Secure MCP Tunnel is an outbound-only relay pattern where a customer-run daemon (tunnel-client) pulls MCP requests from OpenAI, forwards them to a private MCP server, and returns responses without exposing that server on the public internet.

Why this exists now

The adoption blocker for remote MCP in enterprises has not been protocol support; it has been network policy. Security teams often reject opening inbound firewall rules to internal tool servers, even when OAuth and mTLS are available, because public reachability still expands the attack surface and operational burden.

Secure MCP Tunnel addresses that exact boundary: OpenAI-hosted products keep a normal MCP request path, while the customer environment only makes outbound HTTPS calls. In practical terms, this means no public DNS for the MCP server, no inbound NAT rules, and no externally reachable MCP endpoint to maintain.

Mental model and data path

Treat the tunnel as two linked surfaces with one identity (tunnel_id):

• OpenAI side: an OpenAI-hosted MCP tunnel endpoint used by ChatGPT connectors, Codex, or API-backed surfaces.
• Customer side: tunnel-client running close to your private MCP server.

OpenAI product (ChatGPT / Codex / Responses)
                |
                v
OpenAI-hosted MCP tunnel endpoint (/v1/mcp/{tunnel_id})
                ^
                |  outbound HTTPS long-poll + response
                |
tunnel-client in customer network
                |
                v
private MCP server (stdio or streamable-http)

The queue-and-poll shape matters: the private server is not listening to internet traffic. The daemon pulls work, then posts results back. This is why tunnel mode can satisfy stricter network controls while preserving MCP semantics.

Smallest end-to-end setup

This is the shortest operational path from private MCP to an OpenAI product surface.

# 1) Set tunnel identity and runtime key
export CONTROL_PLANE_TUNNEL_ID="tunnel_0123456789abcdef0123456789abcdef"
export CONTROL_PLANE_API_KEY="sk-..."

# 2) Init a profile that points to local stdio MCP
tunnel-client init   --sample sample_mcp_stdio_local   --profile local-stdio   --tunnel-id "$CONTROL_PLANE_TUNNEL_ID"   --mcp-command "python /path/to/server.py"

# 3) Validate before runtime
tunnel-client doctor --profile local-stdio --explain

# 4) Start daemon
tunnel-client run --profile local-stdio

In ChatGPT connector settings, choose Tunnel mode and select or paste the same tunnel_id. You do not expose your internal MCP URL in connector setup.

Deep dive: each moving part

1) Identity and permissions model

Two control responsibilities are split by design:

• Runtime key for the long-running daemon (CONTROL_PLANE_API_KEY) with tunnel read/use.
• Admin key for tunnel CRUD workflows (OPENAI_ADMIN_KEY) with manage scope.

Keep these separate. Reusing admin keys in long-lived daemons creates unnecessary blast radius.

2) Control plane polling behavior

tunnel-client long-polls OpenAI control-plane endpoints for work, then posts responses using request IDs. This introduces backpressure controls at both queue and daemon layers, with defaults like max inflight request windows.

Opinionated takeaway: tune concurrency only after observing real tool latency and MCP server limits. Prematurely raising inflight values often hurts stability more than throughput.

3) MCP-side transport flexibility

The private-side hop can still be stdio or streamable-http. That means tunnel mode is not a rewrite of your MCP implementation; it is a reachability pattern in front of it.

For local compute servers and agents on the same host, stdio is usually simplest. For internal shared MCP services, streamable- http with internal auth and optional mTLS can fit better.

4) mTLS and cert boundary gotchas

There are two certificate contexts that teams mix up:

• CONTROL_PLANE_CLIENT_CERT / CONTROL_PLANE_CLIENT_KEY for the OpenAI hop.
• MCP_CLIENT_CERT / MCP_CLIENT_KEY for the private MCP hop.

Do not reuse certs across those links. The onboarding docs call this out because it is a frequent enterprise onboarding failure.

5) Observability and operations

Unlike ad-hoc SSH tunnels, tunnel-client includes operator-friendly endpoints (/healthz, /readyz, /metrics) and an admin UI. This is crucial for production because connector setup can look healthy while runtime routing is not.

Treat readiness as a gating signal for connector tests. If/readyz is not healthy, debugging in ChatGPT UI is usually wasted effort.

What teams get wrong first

1) They think tunnel mode removes auth design work. It removes inbound exposure, not authorization discipline. You still need scope boundaries, key lifecycle controls, and least- privilege server behavior.

2) They treat tunnel setup as a one-time integration task. In reality, it is runtime infrastructure. You need health checks, restart strategy, and ownership for key/cert rotation.

3) They confuse “private network” with “safe by default.” Tool injection, over-broad write operations, and weak prompt boundaries can still happen entirely inside private perimeter.

Wrong vs right patterns

Common mistakes

• Creating the tunnel in one workspace and configuring connector in another, so tunnel selection never appears.
• Assuming a healthy daemon implies healthy MCP server; always validate actual tool execution path.
• Running multiple active daemons on the same tunnel id without explicit architecture intent.
• Logging raw request/response payloads in production, which can leak sensitive content and tokens.
• Ignoring upstream MCP auth hardening because tunnel mode “feels internal”; token validation and scope control still apply.

Performance and scaling notes

Secure MCP Tunnel adds one queue + poll relay hop. In exchange for private reachability, you accept a small latency tax versus direct in-network calls. In most enterprise assistant workflows, this is acceptable compared to the governance win of no public ingress.

• Keep MCP tool handlers idempotent where possible; retries are easier to reason about when queue edges are involved.
• Start with default inflight settings and measure before tuning.
• Use readiness probes in container runtimes to avoid routing work to a daemon that cannot reach MCP backend.

Who this is for

Community and contrarian view

OpenAI Developer relations framed this release in plain operational terms: private MCP servers can stay inside customer networks while OpenAI products connect through outbound-only HTTPS. That message resonated because it maps directly to enterprise security approvals.

The contrarian take is useful: tunnel mode solves perimeter exposure, but it is not an all-in-one MCP security framework. The broader MCP security discussion still emphasizes token audience binding, no token passthrough, and strict authorization handling for HTTP-based MCP servers.

The verdict

Frequently asked questions

Glossary

All sources and links

Primary sources

• OpenAI Secure MCP Tunnel guide
• openai/tunnel-client repository
• Enterprise customer onboarding doc
• tunnel-client README

Community and launch signal

• OpenAIDevs launch post on X
• Digg mirrored discussion summary

Security and protocol context

• MCP Authorization specification
• MCP Apps compatibility in ChatGPT

Related on MCP.Directory

• OAuth 2.1 for remote MCP servers
• What is MCP
• Remote MCP servers
• Browse MCP servers