Private MCP Tunnels Need Asset Registers

A developer points a Cloudflare Tunnel at a local PostgreSQL instance, wraps it in an MCP server, and hands the URL to a cloud-hosted LLM. The agent starts answering questions about real data. Setup took an afternoon, maybe less. Nobody logged it, and nobody owns it. Meanwhile it’s a hole into a data store the firewall team believes is unreachable from outside.

The tunnel did its job. That’s the problem.

The Connectivity Illusion

MCP tunnels solve network routing. They don’t solve access control.

A tunnel encrypts traffic between the agent platform and your machine. It says nothing about whether the agent on the other end should reach this particular tool, with this particular scope, today. Encryption in transit stops someone from reading the pipe. It doesn’t stop the party who legitimately holds the other end.

Legacy networks taught the same lesson. A VPN gets treated as a security control when it’s only transport. One credential opens a flat network, and everything behind it is exposed. Swap “VPN concentrator” for “outbound tunnel” and the failure mode is identical. The tunnel is the road. You still need the gate.

Some tunnel products ship an identity-aware gate of their own, such as access policies in front of the endpoint. Those help. But they only govern who can reach the tunnel, not what the agent may do once inside, and they only work if someone turns them on and writes down that they did.

The Anatomy of Agentic Shadow IT

Shadow IT used to mean an unapproved SaaS subscription. The newer version is quieter. Developers expose internal tools and private data to cloud agents by routing around the corporate firewall, because an outbound tunnel needs neither an inbound rule nor a change ticket.

Look at it from the network team’s side. They see persistent outbound traffic to a tunnel provider, with nothing attached to it. No owner, no purpose, no data classification. The usual response to a mystery pipe is to block it. The developer’s workflow breaks, they find another route, and the cycle starts again with less visibility each time.

A breach at the agent provider raises the stakes. Incident responders need one answer fast: which of our internal systems could that provider reach? If the tunnels were never registered, the answer is “we don’t know yet.” That’s an expensive thing to say inside a regulatory notification window.

So the rule is short. An MCP tunnel without an owner is a rogue asset. Treat it like one.

Borrowing Governance from Medical Integrations

In locked-down healthcare integrations, the useful rule is blunt: no secure tunnel goes live unless it maps back to a named human data custodian. No custodian, no tunnel. It feels slow. It’s also the reason you can answer an auditor’s questions without a week of archaeology.

The same requirement fits agentic development. Keep an MCP asset register with six columns:

• Endpoint owner: the engineer accountable for the tunnel. A named person, not a team alias.
• Data class: the sensitivity of what the tool exposes. A ticket-status lookup and a patient-adjacent table are not the same row.
• Network path: the local host and port the tunnel resolves to, plus any hostnames it can reach beyond that.
• Auth mode: how the agent authenticates to the MCP server. Static token, OAuth, mutual TLS, or nothing. “Nothing” is acceptable as an entry only because it’s then visible, and someone can challenge it.
• Revocation path: the exact command or API call that kills this tunnel.
• Expiry date: a hard TTL. If nobody renews the row, the endpoint dies.

None of this is exotic. It’s a spreadsheet, or better, a file in version control with a CI check. The format matters less than the rule: no row, no tunnel.

The register has limits. It records what people declare, so it won’t catch a tunnel started by someone who skips the process. Pair it with egress monitoring that flags traffic to known tunnel providers with no matching row. The register tells you what should exist. The monitoring tells you what does.

The expiry column does the most quiet work. Proofs of concept have a habit of outliving their authors. A TTL forces someone to stand up on a given date and say that yes, this thing is still needed.

Designing the Granular Kill Switch

Agents hallucinate. Prompts get injected. Credentials leak. Design as if each of these will happen to you eventually, because over a long enough horizon at least one probably will.

Poor architecture answers by shutting down the main network gateway. The compromised tool goes dark, and so does every other tool the agent crew uses. People then hesitate to pull the lever, since pulling it stops the business. A kill switch nobody wants to use isn’t a control.

Better architecture kills only the compromised tool. This is where the register pays off. Each row carries its own revocation path, so security can sever the tunnel for a read-write database tool while a read-only ticketing tool stays online. The agent loses one capability and keeps working with the rest.

That only holds if the separation exists at design time. Use one tunnel per tool, or at minimum per data class, with credentials scoped to match. If five tools share one tunnel and one token, your revocation path is “kill all five” and the register is decoration. The trade-off is real: more tunnels mean more credentials to rotate and more rows to maintain. For low-sensitivity tools, grouping by data class is a fair compromise. For anything that can write, it isn’t.

My position: do not open an MCP tunnel unless you have a tested API call or script that kills it. Tested means someone ran it against a live tunnel and confirmed the agent lost access. An untested revocation procedure is a hope.

Plumbing Becomes Audit Evidence

The plumbing you build for a proof of concept can end up as audit evidence. It rarely happens on your schedule. More likely, procurement or a client security questionnaire asks how your agents access internal systems, and the question arrives with a deadline.

The directive is simple. Treat MCP endpoints like physical servers or public DNS records. They get an owner, a classification, a documented path, and a decommission date. Few people would argue with that for a rack-mounted machine. A tunnel is a server’s front door, and it deserves the same handling.

Then, when the review team asks for agent access controls, you hand over a populated register with tested revocation paths. What would have been a compliance blocker becomes routine IT procedure. Teams that skip the register can still reach an answer, but they’ll rebuild the inventory from network logs, under pressure, with the clock running.

Write the row before you start the tunnel. It takes less time than the tunnel did.