MCP tunnels just made the internal-data agent cheap

Anthropic shipped MCP tunnels in research preview at Code with Claude London on May 19, 2026. The blog post is short and the marketing copy reads like a routine platform update. It is not. The thing that changed last week is the cost of letting an agent reach the data that lives behind your firewall, and the new cost is low enough that it reorders the decisions on a lot of teams' integration backlogs this quarter.

The before picture

Every team I have worked with in the last 18 months has had at least one version of the same conversation. An agent could do real work if it could see the internal reporting warehouse, or the homegrown ticket system, or the ERP module the vendor will not expose over the public internet. The agent cannot see those systems. The data lives behind the firewall. The MCP servers and APIs that do exist are reachable from inside the corporate network only.

The fixes were all expensive. Stand up a public reverse proxy with auth in front of the internal service, get it through security review, maintain it. Build a VPN-capable agent runtime, get it through security review, maintain it. Move the workload to a self-hosted agent platform inside the perimeter, run a smaller and worse model on it, spend weeks on the operator experience. Each of these is a real project. Most of them cost the same or more than the value of the agent they were supposed to enable, which is why the workflows kept getting tabled.

What changed last week

MCP tunnels collapse the network problem into a single lightweight gateway you deploy on your side of the firewall. The gateway opens one outbound TLS connection to Anthropic's tunnel edge. No inbound firewall rules. No public endpoint. The agent on the Claude Platform calls your private MCP server as if it were any other MCP server, and the traffic flows through the tunnel.

The encryption story is three layers, which matters for the security review that is going to happen before you turn this on for anything serious. Mutual TLS between Anthropic and the tunnel edge. Inner TLS between the Anthropic backend and your proxy. OAuth on each individual MCP server behind the tunnel. The transport is Cloudflare. The administration lives in the Claude Console under workspace settings, gated to org admins.

This is research preview, so you have to request access. The companion release, self-hosted sandboxes, is in public beta and supports Cloudflare, Daytona, Modal, and Vercel as managed providers if you want the tool-execution side inside your perimeter too.

Three workflows that just became afternoon projects

Agent reporting against a private warehouse. Finance ops teams have been asking the same question for a year. Can the agent answer ad-hoc questions against our actuals, by client, by month, without us building a public BI proxy first. The honest answer was no, not without a real project. With MCP tunnels, the path is: a private MCP server that wraps your warehouse with read-only SQL and a small set of named queries, deployed inside the perimeter, registered with the tunnel. Two days of work for a moderately experienced engineer. The agent reaches it through the tunnel. The warehouse never sees the public internet.

Agent triage against a homegrown ticket system. Every operations team has one of these. An internal Rails app or a Filemaker database or a custom Django thing that the company has been running for nine years. It has a perfectly good HTTP API on the inside. It has no public surface, and the team that owns it is not going to add one. The agent can now triage incoming tickets, route them, suggest first responses, and update the record, all without a single public endpoint. A small MCP server in front of the internal API, registered with the tunnel, and the agent does the work.

Agent reconciliation against a vendor ERP module. The vendor sells you the API on the inside of your VPC for an extra license tier. The vendor does not sell you the API on the public internet for any tier. Before last week, the answer was to write the reconciliation script as an internal cron job and forget about the agent. With MCP tunnels, the same internal API becomes a tool the agent can use. The agent reads the open invoices, cross-references with the bank statement, drafts the journal entries, and hands the result to a human for approval through your existing review queue.

The pattern across all three is the same. The integration was always one well-scoped MCP server away from working. The blocker was the network, not the workflow. MCP tunnels remove the network blocker.

The cost picture, before and after

Take the warehouse-reporting case. Before last week, the realistic path was to build a public BI proxy with auth and rate limits, get it past security, and maintain it. Call it three to five weeks of engineering work, plus a yearly maintenance cost in the low thousands of dollars worth of attention. After last week, the gateway install is a half-day of platform work. The MCP server wrapping the warehouse is one to two days of code. Total: under a week, no public attack surface added.

The ratio is similar for the other two cases. The work that used to be most of the project, making the internal system reachable, is now a configuration step. The work that remains, the MCP server itself, is the work that was always actually load-bearing. That is the work you want to be doing anyway.

When MCP tunnels are not the right answer

Three cases where this is the wrong tool.

The vendor is about to ship a hosted MCP server. If the SaaS vendor on the other side of the system has a roadmap commitment to a hosted MCP server this year, the right move is to wait. We wrote about asking that question on the renewal call two weeks ago. A vendor-hosted MCP server arriving in Q3 beats a tunnel you maintain.

The system has no API and no internal one either. If the only way to drive the system is through a browser UI a human clicks through, the right tool is computer-use, not MCP tunnels. We covered the decision rule for computer-use last week. Tunnels assume there is an API on the other end worth wrapping. If there is not, you are wrapping nothing.

Regulated data with a hard residency requirement. The tunnel is encrypted end to end, but the agent itself runs on Anthropic infrastructure. If your compliance posture requires that the model never touch the regulated payload, even encrypted in transit, this is the wrong shape. The right shape is a self-hosted agent runtime inside the perimeter. The self-hosted sandboxes release pairs with tunnels for exactly this case, but the tunnel alone is not the full answer.

The 30-minute exercise to run this week

Open the backlog. Find every integration request from the last twelve months that got tabled with a note like "cannot expose this externally," "security said no," or "needs a VPN-aware runtime." Make a list. For each one, write down what an MCP server in front of that system would expose. Three to six tools per system is the right size.

If the list has more than two systems on it, you have a quarter of work that is now materially cheaper than it was on May 18. The right move is to pick the one with the clearest ROI, request access to MCP tunnels, and prototype against it before the research preview gets repackaged into a paid tier. The cost curve is going to bend back up once this graduates to GA. The work you do now is the cheapest version of it.

If you have a stack with one or two internal systems where the agent conversation keeps getting blocked on the network shape rather than the workflow, reach out. We run the MCP-tunnels-versus-alternatives triage for clients in a single working session.