MCP made it easy to give an AI agent a tool. What it didn't come with is much guidance on how to expose that tool safely, and that gap is starting to show. A year ago, most MCP servers were harmless demos: a weather lookup, a to-do list, something running on localhost that nobody but you would ever call. Since then, teams have wired MCP servers into production databases, internal admin panels, and ticketing systems. So a server that used to be a toy can now create, delete, or move real data. The protocol hasn't really changed to reflect that, which means the job of securing it has landed entirely on whoever builds the server.
Why an MCP server is a different kind of risk
A normal internal API is already risky to leave exposed. An MCP server adds a wrinkle: it's meant to be called by a model that decides on its own what to do next, not by a developer writing an explicit, reviewed request.
That changes who's really doing the calling. With a regular API, you know every call site because you wrote them. With an MCP server sitting behind an agent, the caller is a language model interpreting instructions, and some of those instructions might come from content it picked up along the way, like a webpage, a document, or a support ticket. This is the same failure we dug into in AI Guardrails in Production. A malicious instruction doesn’t have to come from the user. It can sit inside a PDF, an email, or a support page that the agent reads along the way, and the model may treat it like a real instruction. A system prompt can’t reliably stop that, because a prompt is a request, not enforcement. A guardrail is a check that runs outside the model, so it works whether or not the model follows your instructions.
There's a simpler risk underneath, too. MCP servers tend to sit in front of the systems that matter most, because that's where they're actually useful. Nobody bothers wrapping a static marketing page in an MCP server. It's usually the database, the CRM, or the deployment pipeline behind it, which is exactly why leaving one on the open internet tends to go badly.
When this actually becomes a problem
None of this matters much while you’re building a proof of concept. An MCP server running on your laptop, reachable only from localhost, is genuinely fine. That’s where our own Browser Automation MCP started: a browser testing agent that tests UI features, and wrapped it in an MCP server so we could use it straight from the coding window. It wasn’t a security problem because only the developer’s own machine could reach it. There was no public URL, no outside caller, and nothing exposed to the internet. That’s the right amount of security for a solo developer testing an idea, which is probably why most tutorials stop right there.
It starts to matter once one of these three things happens:
You need someone else to reach it. A teammate, a hosted agent platform, or a CI pipeline needs to get to the server from outside your machine, and now you have to actually decide how.
· The server touches something sensitive. A read-only weather API leaking isn't a big deal, but a database connector leaking is a breach. How carefully you expose the server should scale with what it can actually do.
· You move from local dev tools to hosted agents. Managed agent platforms like Claude's Managed Agents or ChatGPT's connectors run in someone else's cloud. Reaching an MCP server that's still inside your firewall means getting from their infrastructure to yours, and that's where the real design decision shows up.
Your options, from worst to best
Most teams end up reaching for one of four approaches. Honestly, three of them are compromises you make because they're fast, not because they're right.
• Open a public endpoint. It's the simplest option and also the worst. Anyone with the URL can attempt to connect, and you're relying entirely on whatever authentication you happened to bolt on top.
• Run a third-party tunnel like ngrok. It's fast and fine for demos, but it still creates a public URL. You've also added a company you may not have vetted into the request path for sensitive traffic.
• Stand up a VPN. This does solve the exposure problem, but it's a heavy lift just to connect one hosted AI product to one internal server. Most teams don't want to wait on network provisioning to ship an agent feature.
• Run an outbound-only tunnel. This is the approach that has picked up real traction over the last few months, largely because both OpenAI and Anthropic built dedicated tooling around it. It's worth understanding properly.
How MCP tunneling actually works
Strip away the branding from either vendor's product and the idea is fairly simple: your server stops waiting around for connections and starts making one instead. Here's roughly what happens, step by step.
• A small client runs inside your network. You deploy a lightweight process next to your MCP server, wherever it lives. That could be the same host, the same pod, or just somewhere with a private network path to it.
• The client starts the connection, not the AI provider. It dials out over HTTPS to the provider's infrastructure and keeps that connection open. Because it's outbound, you never have to open an inbound port or touch your firewall rules.
• The provider queues requests instead of reaching in. When Claude or ChatGPT needs to call your tool, the request travels down the tunnel that's already open. The provider never tries to reach into your network on its own.
• The client forwards the request locally. Once the request lands inside your network, the tunnel client hands it to your actual MCP server over a normal local connection, whether that's localhost or an internal address.
• The response travels back the same way. Your server answers, the client picks up the response, and it rides back to the provider over the same open connection. No new inbound connection ever gets created.
• Encryption is usually layered. A well-built setup wraps the traffic twice. One layer secures the path to whatever is carrying the tunnel. The other is an inner layer sealed by a certificate only you hold, so even the transport provider can't read the actual MCP payloads.
• Your server still has to authenticate every request on its own. The tunnel only solves reachability. Whatever OAuth flow, API key, or access control your MCP server already enforces keeps running exactly as before.
The Two vendors building this: OpenAI and Anthropic
This isn't a hypothetical pattern. OpenAI and Anthropic both shipped dedicated tooling for it within weeks of each other. That suggests it's less a clever feature idea and more a response to enterprise teams running into the same wall at roughly the same time.
OpenAI: Secure MCP Tunnel
OpenAI's version ships as an open-source client called tunnel-client, which you run next to your MCP server. It dials out to OpenAI over HTTPS, pulls any queued MCP work, forwards it to your server locally, and sends the response back over that same connection. Because the client is open source, your security team can read through it before signing off on a production deployment, instead of taking OpenAI's word for what it does.
It also includes a smaller feature called Harpoon. It's a scoped-down mode for exposing specific internal REST endpoints by label, aimed at teams that have plain HTTP APIs rather than full MCP servers they want reachable.
The rough edge to know about is OAuth. If your MCP server's authorization server also lives inside your network, the tunnel doesn't automatically make that reachable too. The login step can fail even when the tunnel to your actual MCP server is working fine.
Anthropic: MCP tunnels
Anthropic's version is currently in research preview and is built on Cloudflare's open-source cloudflared as the outbound connector. Traffic lands on a proxy that Anthropic operates, which terminates a second layer of TLS using a certificate that only you hold. Cloudflare never has access to that inner key, so it can carry your traffic without being able to read the actual MCP payloads. It still sees connection metadata, like timing and byte volume, just not the content.
Each private MCP server gets its own hostname under a tunnel domain you control. You then attach that hostname to a Managed Agent session or pass it through the Messages API, the same way you would any other remote MCP server.
Anthropic is fairly explicit that this is meant to be a narrow, configured path, not a general network bridge. Anything your MCP server depends on, like a separate internal service, still needs its own way of being reachable.
Functionally, the two products are close cousins. What really matters when choosing between them is who operates the transport, how much of the client you can audit yourself, and which hosted product you need your servers to talk to.
Where tunnels fall short
Outbound-only tunnels solve the exposure problem well, but they don't solve everything. It's worth being upfront about what's still missing before you build a real dependency on one.
• They're new, so the guarantees aren't fully settled. Anthropic's tunnels are labeled research preview and offered "as-is," with no uptime or support commitment. Neither vendor's offering has anywhere near the track record of a VPN that's been hardened over a decade of production use.
• You're still trusting a third party with your transport layer. Even with layered encryption, whoever carries your tunnel traffic can still see connection metadata like your egress IP, timing, and byte volume. It's less exposure than a public endpoint, but not zero.
• Vendor lock-in shows up right away. An OpenAI tunnel only works with OpenAI products, and an Anthropic tunnel only works with Claude. If you want both talking to the same internal server, you end up running two separate tunnels to it.
• A tunnel doesn't decide who's allowed to call your server. It solves reachability, not authorization. An unprotected MCP server behind a working tunnel is just conveniently reachable from a hosted agent platform instead of the open internet, which isn't much of an improvement.
• They're deliberately narrow, which is good and also inconvenient. A tunnel only reaches the hostnames or targets you configured for it. If your MCP server needs to call another internal service, like a separate auth server, that service needs its own path too. It's easy to assume the tunnel already covers it until something breaks in production.
• Debugging tends to get harder, not easier. There's an extra hop in the traffic path that you don't fully control. When something is slow or failing, you're troubleshooting across your network, the tunnel client, the vendor's proxy, and the server itself. Neither vendor's tooling is quite mature enough yet to make that simple.
None of this means you shouldn't use them. It just means a tunnel works best as one control in a layered setup, not as your entire security model. The real work of deciding who's allowed to do what still has to happen through authentication, scoped permissions, and monitoring on the MCP server itself.
What this means if you're building one today
If your MCP server is still local-only , there’s no need to reach for a tunnel yet. You don’t need one until something outside your own machine actually needs to call it.
Once that changes, it helps to work backward from what the server can actually do. A read-only lookup tool can probably tolerate more exposure than something that can write to production. So match the security model to what's at stake, not to whatever setup is fastest to get running.
And if you're weighing the options above, an outbound-only tunnel is a reasonable default for anything connecting to a hosted agent platform. It's not more secure because a well-known vendor happens to build it. It's more secure because nothing on your side ever has to accept an inbound connection in the first place. That's the same reason this pattern has been trusted in networking for a lot longer than MCP has existed.
