OpenAI's Secure MCP Tunnel Retires "It's Only on the Internal Network"

OpenAI has shipped the Secure MCP Tunnel into alpha, and the engineering is sound. It solves a real problem in the way a security-conscious team would solve it, and the failure modes worth discussing are not in the tunnel. They are on either end of it.

The design

The problem: enterprises run MCP servers inside private networks, and hosted products cannot reach them. The obvious answer is an inbound path, and every competent security team refuses to provide one.

OpenAI's answer inverts the connection. The private side makes the first move. OpenAI products send MCP requests to an OpenAI-hosted tunnel endpoint, and a customer-run client already sitting beside the private MCP server picks them up over long-polled outbound HTTPS. That client, tunnel-client, is open source and customer-deployed. It receives requests, forwards them to an approved local server, and returns responses and notifications over the same connection. As OpenAI puts it, outbound HTTPS is already familiar to enterprise firewalls, proxy environments and platform teams.

The boundaries are explicit. Calls stay bounded by customer-owned target registration, allowed methods and response-size limits. OpenAI states directly that this is not a general-purpose network bridge. Authentication works with OAuth, private certificate authorities, outbound proxies or client certificates, and OAuth discovery for the target server travels through the tunnel path so the hosted product can learn how to authenticate. Codex has an integrated plugin workflow on top.

There is also Harpoon, an extension that widens the same path to approved REST targets, so private APIs that were never MCP servers become reachable too.

No inbound listener, no new port, no exposed service. The tunnel is not the risk. The risk is that it makes something reachable that was built on the assumption that nothing could reach it.

What was actually protecting your internal MCP servers

Look at the shape of published MCP server vulnerabilities over the past eighteen months. They are not exotic. They are missing authentication, empty default secrets, unauthenticated message endpoints, tool restrictions enforced in the wrong layer, and STDIO transports that execute whatever they are handed. We have written up a long run of these, and the pattern in how MCP servers expose enterprise secrets is representative: the server holds broad credentials and authenticates callers weakly or not at all.

Those deployments were not secure. They were unreachable, which looked the same from the inside. Network position was doing the work that authentication was supposed to do, and that arrangement held for as long as the only callers were on the same segment.

A tunnel changes the population of callers without changing a single line of the server. The compensating control evaporates and the original flaw becomes the entire control surface. This is the oldest pattern in enterprise security, arriving in a new protocol: implicit network trust meets an explicit remote caller. It also raises the stakes on where tool restrictions are enforced, because a restriction applied in the client rather than at execution is bypassable by any caller that skips the client, which is the failure behind the mcp-server-kubernetes tool restriction bypass.

The approval checkpoint that does not exist

Historically, making an internal service reachable from outside required a firewall change. That request went to a team whose job included asking why, and the conversation was the control. It was a slow control and frequently an annoying one, and it caught things.

The tunnel needs no firewall change. tunnel-client is open source, runs next to the server, and requires only outbound HTTPS, which is already permitted everywhere. An engineer who wants ChatGPT to query an internal service can deploy it in an afternoon and will not encounter anyone positioned to ask why. That is the same property that makes it adoptable, and it is why the governance has to move from the network review that will not happen to target registration and endpoint inventory, which can.

This is the argument for an MCP server registry becoming a hard requirement rather than a good practice. A registry with an owner per server, a declared credential scope and a recorded approval is the only thing standing between a tunnelled internal service and nobody knowing it is tunnelled.

Authentication has to move to the server

OpenAI supports OAuth, private CAs, outbound proxies and client certificates, and routes OAuth discovery through the tunnel so the hosted product can authenticate properly. Use it. The specific thing to avoid is the pattern where the tunnel authenticates and the server behind it does not, on the grounds that only the tunnel can reach it. That is the internal-network assumption rebuilt one layer up, and it fails the same way.

The identity question underneath is whose authority the agent is acting with. If the tunnel presents a single service credential, every user of the hosted product acts as that credential, and your audit trail records the service rather than the person. The distinction between token exchange and passthrough matters here, and AI gateways and user-level OAuth for MCP servers covers the tradeoffs. OAuth for MCP servers explained is the primer if the 2026 spec is not yet familiar.

What to do now

• Register tunnelled targets before anyone tunnels. Target registration is customer-owned, which means it is your control and only works if you operate it. An owner, a credential scope and a written approval per target.
• Authenticate at the MCP server. Do not rely on the tunnel being the only caller. Assume a second caller will exist eventually, because one usually does.
• Audit the servers you are about to expose, before you expose them. Run through the list in Model Context Protocol security explained. Unauthenticated internal servers are common, and finding one after the tunnel is up is the wrong order.
• Inventory tunnel-client processes across the fleet. This is the detection that matters, because the network layer will not tell you. A tunnel-client is an outbound HTTPS process like thousands of others.
• Cover Harpoon targets in the same policy. Private REST APIs behind implicit network trust are a larger and older population than your MCP servers.
• Decide on identity now. Service credential or per-user token. Choose deliberately, because retrofitting per-user identity onto a tunnel that has been live for six months is a migration, not a setting.

The convergence

Anthropic shipped enterprise-managed MCP connectors to bind connector authorisation to the identity provider. OpenAI shipped a tunnel to solve reachability. The 2026-07-28 specification changed how identity travels in stateless deployments, covered in stateless MCP. Different vendors, adjacent problems, one direction of travel: MCP is becoming the enterprise integration layer.

Integration layers inherit the governance problems of everything they integrate. The useful thing about being early is that the inventory is still small enough to build. In eighteen months the question will not be whether to tunnel an internal MCP server. It will be how many are already tunnelled, and by whom. If you want to query that inventory conversationally rather than through a console, our own MCP server and its OpenAPI description are on the developer resources page.