Product
MCP tunnels: govern private servers without exposing them
Thomas Rooney
June 30, 2026 - 4 min read
The internal MCP registry let you point Speakeasy at any MCP server you could reach by URL and govern it alongside everything else. But the servers that most need governing are usually the ones you can’t reach by URL: a Postgres MCP that runs queries against production. An admin MCP that can set a user’s license or flip a feature flag. These run deep inside your network, behind a firewall, and they should never touch the public internet. Bringing them under governance used to mean exposing them first — which defeats the reason they’re private in the first place.
MCP tunnels close that gap. Run a tunnel client inside the network that already reaches your server, and it opens an outbound-only connection to Speakeasy. We proxy full MCP traffic to the server through that tunnel. No inbound firewall ports, no public hostname, no new trust into your environment — and the server joins your registry like any other source.
How it works
A tunnel is an outbound-only path from a host inside your network to the Speakeasy control plane. The tunnel client runs somewhere that can already reach your MCP server, dials out over HTTPS, and pulls MCP work from the queue. When an agent calls a tool, the request travels down the established connection, the client forwards it to the server locally, and the response returns the same way.
A private server, reached without exposing it.
The governed path.
Agent surfaces reach the private server only through the Speakeasy control plane. The tunnel client sits inside the network and dials out over HTTPS, so no inbound port is ever opened across the firewall.
Because the connection is outbound-only, you never open an inbound port or put the server on the public internet. There’s no second address that quietly bypasses the tunnel. Traffic is held to hard tenant isolation, and the trust boundary doesn’t move: Speakeasy reaches your server only through the path you opened, and nothing on the outside can reach in.
Governance for the servers that need it most
Once a tunneled server is in your registry, it inherits the model you already use. Authorization scopes what each role can call, down to the individual tool. Every call is tied to a real identity and written to the same audit trail as the rest of your servers, and the activity view shows the traffic flowing through the tunnel next to everything else.
That’s what makes high-risk internal MCPs usable. Teams want to point agents at important (but sensitive) data sources because that’s where the leverage is. A tunnel lets them do it as auditable, policy-governed activity instead of an ungoverned connection nobody can see.
Set it up once, for every agent
Anthropic and OpenAI both ship their own MCP tunnels, but each is a closed loop to that vendor’s infrastructure — a Claude tunnel only works inside Claude, an OpenAI tunnel only inside OpenAI — and neither is aware of the end user behind a call.
A Speakeasy tunnel is vendor-neutral. You define the identity, logging, and trust boundaries once, and the tunneled server becomes reachable from any agent surface your team uses. Stand it up a single time instead of running a separate tunnel client per vendor, then connect Claude, ChatGPT, the Responses API, or your own agents through the same governed path. Together with network-level access, it gives you an internal AI service mesh: private servers your agents can reach, invisible to everyone else.
When you turn on tunnels, your team can:
- See private MCP server traffic in the same observability view as the rest of your registry.
- Apply access controls and security policy to servers that never leave your network.
- Replace per-vendor tunnels with one cross-platform connection.
Rolling out
MCP tunnels are rolling out per organization. Reach out to have them enabled for yours.
Get started
Tunnels are configured as a source in your Speakeasy dashboard. Add a tunneled source, run the tunnel client inside the network that reaches your MCP server, and once it dials out the server joins your registry — governed, audited, and observable next to everything else you run.
Have internal MCP servers too sensitive to expose? Book time with our team and we’ll help you bring them under one roof.