In May 2026, OpenAI shipped a feature called Secure MCP Tunnel. Weeks later Anthropic shipped one called MCP Tunnels. The mechanics are nearly identical. Both let an autonomous agent reach a private MCP server without anyone opening a port, exposing a service, or whitelisting an IP. Both are encrypted end-to-end. Both include, deliberately, a way to restrict what the agent can do once it's inside.
When two of the most watched AI labs ship the same primitive within weeks of each other, no coordination, no joint announcement, the technology itself is interesting. The signal underneath it is more interesting.
What most teams will read this as
The natural reading is "neat, secure remote access for agents." Like ngrok, but for AI. A way to expose a private API to a hosted model without the public internet getting involved.
That reading is correct as far as it goes. It also misses the point.
What it actually changes
The question most companies have been asking for the last year is some version of "which vendor's MCP server should we plug our agent into?" HubSpot has one. Atlassian has one. Slack has one. Notion has one. You authenticate, the vendor's server talks to the vendor's backend, your agent gets data back. Easy.
That model is fine for what it does. It's also boxed in by design. The vendor's MCP server can only see the vendor's product. It can only do what the vendor decided to ship. It can never join across your other systems, because it doesn't know they exist.
Tunnels shift the question. Now the MCP server doesn't have to be the vendor's. It can be yours. You build it. You run it. You decide what it exposes. The vendor's tunnel is just the connectivity layer between your agent and your server.
That's not a security feature with a few extra benefits. It's a different architecture.
The two models, plainly
A vendor's MCP server lives on the public internet, built by the vendor, scoped to that vendor's product, and exposing whatever tools the vendor chose to ship. It cannot reach anything outside the vendor's perimeter.
Your own MCP server, behind a tunnel, runs wherever you choose to run it. It exposes whatever tools you write. It can read across your CRM, your warehouse, your meeting transcripts, your bespoke order system, and join them together before it returns anything. The raw data stays inside your boundary. Only the structured findings cross.
The differences aren't subtle.
| Axis | Vendor MCP | Your MCP, behind a tunnel |
|---|---|---|
| Built by | Vendor | You |
| Hosted by | Vendor | You |
| Data reachable | Vendor's product only | Anything the server can see |
| Tool surface | Vendor's choice | Your choice |
| Internet exposure | Public, authenticated | Private, outbound only |
| Cross-system joins | No | Yes |
| Preprocessing before exposure | None | Whatever you write |
| Audit trail control | Vendor's | Yours |
Why this is a governance shift, not a plumbing shift
Every tool your MCP server exposes is a decision. Every tool it doesn't expose is a decision. Every join it performs, every value it transforms, every record it refuses to return without an extra check, all decisions. The server is the place where commercial policy actually runs.
That's the bit most teams haven't caught up with yet. When the agent calls your MCP server, your code decides what comes back. Not the vendor's. Yours. If a procurement agent needs to confirm a budget before it commits, that confirmation lives in your server. If a sales agent needs to know whether a deal can be discounted, that ceiling lives in your server. If a customer support agent should never see another customer's records, that boundary lives in your server.
This is what commercial governance looks like at the network layer. It's not a policy document. It's a tool surface, and a refusal to expose tools you haven't approved.
The board-level question
The conversation in most boardrooms has been "is our AI strategy working?" That was the right question last year.
The question now is different. Whose MCP servers are our agents calling? Which of those servers do we own? What can they do that we haven't sanctioned? Who'd notice if that changed?
Most companies cannot answer those questions today. Most are still on the first model: vendor MCP servers, public internet, whatever tools the vendor decided to ship. That works until the agent needs to do something joined up, sensitive, or specific to how this particular business actually operates.
The infrastructure to do better now exists on both major model platforms, shipped within weeks of each other. The assumption that vendor MCP servers are sufficient has just quietly expired.
The MCP server that will matter most to your business is not the one you authenticated into. It's the one you decided to write.