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 are also deliberately scoped: the tunnel is transport, and the upstream MCP server still owns its own auth and decides what the agent can do.
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 can stay inside your boundary; the server can return only structured findings.
Vendor MCP servers will keep doing what they do well: product-scoped tasks within their own perimeter. Your own MCP server matters when the work is cross-system, sensitive, or specific to how the business actually operates.
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 experience layer just shrank
There's a quieter consequence sitting next to the governance one. Once your MCP server is reachable from any compliant chat client, the chat itself becomes a viable UI for most of what a CRM does. "Which deals close this week and which are stalled" is a chat question. So is "draft a follow-up to everyone I met last Wednesday." So is "show me what's changed on the deal you're worried about." None of those need a custom screen.
This doesn't kill custom UI. It shrinks the part of the job custom UI is for. The chat handles the long tail, the multi-step reasoning, the net-new questions you didn't predict. Screens still win for the things screens are good at: at-a-glance state, triage queues, bulk operations, push notifications. But the ratio shifts. Maybe more than half of what people open a CRM for becomes conversational. The rest stays visible.
That has a consequence for where value lives. If most of the experience layer can be served by any compliant chat client, building the experience layer stops being defensible as a place to win. What becomes valuable is the MCP server underneath: the tools you chose to expose, the joins you decided to run, the governance you baked in, the things you refused to expose without a check. The screen is interchangeable. The server is not.
This isn't just a security primitive. It's where the value migrates to when chat eats the screen.
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? And which layer of this are we still trying to build ourselves?
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.
The defensible layer is no longer the screen. It's the governed tool surface underneath the agent.