セキュア MCP トンネル（6 分読了）

Secure MCP Tunnel lets you connect private MCP servers to supported OpenAI products without opening inbound firewall ports or exposing those servers to the public internet. Run tunnel-client inside the network that can already reach your MCP server; it opens an outbound HTTPS path to OpenAI, pulls queued MCP work, forwards requests locally, and returns responses through the same tunnel.

An MCP tunnel is an outbound-only connection from a host inside your network to an OpenAI-hosted MCP endpoint. Use it when your MCP server is private, on-premises, or behind a firewall, but ChatGPT, Codex, the Responses API, or another supported OpenAI surface still needs to call it.

Secure MCP Tunnel keeps the MCP server private while giving supported OpenAI products a normal MCP request path. tunnel-client polls OpenAI for work, forwards MCP requests locally, and returns responses through the same tunnel.

• Your MCP server runs on a private network, on-premises, on a developer machine, or behind existing access controls.

• You want ChatGPT, Codex, the Responses API, or another supported OpenAI surface to use that server without making the MCP server public.

• Your network allows the host running tunnel-client to make outbound HTTPS requests to api.openai.com:443 by default, or mtls.api.openai.com:443 when control-plane mTLS is configured, and reach the private MCP server.

• Start with the MCP and Connectors guide for general MCP concepts.

• Create or manage an OpenAI-hosted MCP tunnel endpoint in Platform tunnel settings.

• Run tunnel-client inside the network that can reach your private MCP server.

• Configure tunnel-client with the tunnel identity and the private MCP server address.

• OpenAI products send MCP requests to the OpenAI-hosted tunnel endpoint.

• tunnel-client long-polls for queued work, forwards each JSON-RPC request to the private MCP server, and posts the response back through the tunnel.

The private MCP server does not need a public listener. The OpenAI-hosted endpoint gives supported products a normal MCP request path, while the network initiation point stays inside your boundary. When a connector asks for streamed results, the tunnel path can forward intermediate server-sent events.

You need:

• A tunnel_id from Platform tunnel settings.

• A runtime API key for tunnel-client. The key principal needs Tunnels Read + Use for the target tunnel.

• A tunnel manager with Tunnels Read + Manage if you need to create or edit tunnel metadata.

• An MCP server that tunnel-client can reach over stdio or HTTP from inside your network.

tunnel-client does not need inbound internet access. It needs outbound HTTPS to OpenAI and local reachability to the private MCP server:

FromToUsed for

Host running tunnel-clientapi.openai.com:443 over HTTPS on /v1/tunnel/*Default polling and response posting.

Host running tunnel-clientmtls.api.openai.com:443 over HTTPS on /v1/tunnel/*Polling and response posting when control-plane mTLS is configured.

Host running tunnel-clientThe configured stdio command or MCP server URLForwarding MCP requests from inside your network.

Open Platform tunnel settings, then use the download link there or the latest public tunnel-client release from openai/tunnel-client. Keep your runbook pointed at the latest-release URL instead of hard-coding a specific release URL.

If you already have a binary, start with tunnel-client help quickstart. For a named local stdio profile, use:

1
2
3
4
5
6
7
8
9
10
export CONTROL_PLANE_API_KEY="sk-..."

tunnel-client init \
  --sample sample_mcp_stdio_local \
  --profile local-stdio \
  --tunnel-id tunnel_0123456789abcdef0123456789abcdef \
  --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, use --mcp-server-url https://mcp.internal.example.com/mcp instead of --mcp-command.

Keep tunnel-client run ... healthy while you create or test the connector. Connector discovery and MCP tool calls depend on the running client.

Run tunnel-client in the same trust boundary that can already reach the private MCP server. Common deployment patterns are:

• Kubernetes sidecar: Run tunnel-client beside the MCP server in one Pod and connect over localhost.

• Dedicated Kubernetes deployment: Run tunnel-client separately when the MCP server is already reachable through a private Service.

• VM or systemd service: Run tunnel-client on a host that can reach the MCP server over private networking.

Open ChatGPT connector settings, create a custom connector, and choose Tunnel under Connection. Select an available tunnel when ChatGPT lists it, or paste a valid tunnel_id if you already have one.

If the tunnel does not appear in ChatGPT, verify that the tunnel is associated with the target workspace and that the connector operator has Tunnels Read + Use.

• The MCP server address stays private and is used only from inside the environment where tunnel-client runs.

• tunnel-client authenticates to the OpenAI tunnel control plane; supported OpenAI products use the OpenAI-hosted tunnel endpoint.

• Tunnel access follows the existing organization and workspace context instead of introducing a separate public ingress path.

• tunnel-client supports enterprise networking requirements such as outbound proxies, custom CA bundles, control-plane client certificates, and MCP-side mTLS.

Secure MCP Tunnel can also support narrowly scoped HTTP callouts from supported agent or API flows into a customer network. tunnel-client includes an embedded MCP server, Harpoon, that exposes configured HTTP targets by label and lets callers invoke them through the tunnel with bounded request/response limits.

Use this when you need to reach a small set of private REST endpoints without exposing them publicly. Harpoon is not a general-purpose proxy: callers cannot choose arbitrary hosts, and requests are limited to the targets and methods configured by the customer.

• Tunnel not visible in ChatGPT: Check the tunnel workspace scope and the connector operator’s Tunnels Use permission.

• Connector discovery or tool calls fail: Confirm that tunnel-client run ... is still running, then re-run tunnel-client doctor --profile <name> --explain.

• You can inspect a tunnel but cannot edit it: The operator likely has Tunnels Read but not Tunnels Manage.

• tunnel-client exposes /healthz, /readyz, /metrics, and a local admin UI at /ui.

• The admin UI is loopback-only by default. Expose it remotely only when you intentionally need an operator network to reach it.

• Use those surfaces to confirm that the client is healthy, ready, and polling before testing from ChatGPT, Codex, or an API flow.

• If the client is not connected, requests through the tunnel fail until tunnel-client reconnects.

• Raw HTTP logging is disabled by default, and support exports are redacted.

• OAuth discovery can travel through the tunnel path so the MCP server itself can remain private.

• The tunnel preserves the upstream authorization server metadata needed for browser-facing OAuth flows.

• The authorization server itself is not automatically tunneled. If it 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.

• Manage OpenAI-hosted MCP tunnel endpoints in Platform tunnel settings.

• Use a tunnel when creating a connector from ChatGPT connector settings.

• For Codex or API flows, use the tunnel-backed MCP target exposed by the supported product surface.

• Create or manage the tunnel in Platform tunnel settings.

• Validate your tunnel-client profile with tunnel-client doctor --profile <profile> --explain.

• Connect the tunnel from ChatGPT connector settings or the supported OpenAI surface you are using.