If you are running an MCP server, you have probably hit the connectivity question: how do agents across the internet reach it? The default answer is usually "put everything on a VPN." It is familiar, it works, and it feels safe. But a VPN is the wrong shape for an MCP server, and the mismatch costs you in surprising ways.
The Problem VPNs Solve (And Why It Looks Like a Fit)
A VPN — Tailscale, ZeroTier, WireGuard with a mesh — solves a real problem: you want machines in different networks to talk as if they were on the same LAN. Every device gets a virtual IP, traffic is encrypted, and the mesh handles routing.
For a developer running a handful of servers and workstations, this works well. You join the VPN, you are in. Endpoints are reachable, traffic is private, and the setup is well understood.
Now apply it to an MCP server. The MCP server runs in one place — a VPS, a home server, a cloud VM. The agents that call it are ephemeral: they spin up, make requests, and disappear. They run in CI pipelines, on user laptops, in serverless functions, across different clouds. Every one of these agents needs a path to the MCP server.
A VPN says: make every agent a member of the VPN. The problem is in that word — member.
Membership vs. Trust — The Critical Difference
VPNs treat membership and trust as the same thing. If you are on the VPN, you are trusted. If you are not on the VPN, you are unreachable. This is fine for a team of known machines. It breaks for an open or semi-open MCP server that serves many clients.
- Every new agent needs a VPN join key. That key is expensive to rotate and hard to scope. Leak it once and every node on the VPN is exposed.
- Revoking a compromised agent means removing it from the VPN. That is a manual operation, and in a mesh VPN, it has to propagate to every peer.
- Ephemeral agents don't fit. A CI runner that calls an MCP server for 30 seconds should not need a persistent VPN membership that lives beyond the job.
This is not a flaw in VPN design. VPNs were built for stable, long-lived connections between known machines. MCP servers serve a fundamentally different pattern: many clients, short sessions, high turnover.
What an MCP Server Actually Needs
An MCP server needs a small set of properties that are surprisingly different from a VPN's feature set:
- Inbound reachability — the server has a stable address that clients can reach, regardless of where it is hosted.
- Per-connection trust — each client authenticates individually; trust is scoped to the session, not to the network.
- No persistent membership — clients connect, do work, and disconnect. No join key, no long-lived assignment.
- UDP-friendly — many MCP calls are short request-response cycles; TCP overhead from VPN tunnels adds latency that compounds.
A VPN gives you (1) and part of (3), but it actively fights (2) by giving every member access to everything on the subnet. And it adds network overhead for (4) that is invisible until you measure it.
Per-Peer Tunnels — The Alternative Shape
The alternative is a per-peer tunnel: instead of joining a shared network, each client establishes a direct encrypted tunnel to the MCP server. The server never exposes a subnet; it exposes exactly one endpoint. Trust is per-handshake, not per-membership.
This pattern has practical advantages that map directly to the MCP use case:
- No join key to distribute. Each agent authenticates on connection with its own credentials. There is no shared secret that, leaked, compromises the whole mesh.
- Revocation is instant. Drop the peer's trust entry on the server. That agent cannot connect again. No propagation delay, no stale membership.
- Ephemeral clients work. An agent that connects for a single query and disappears leaves nothing behind. No cleanup, no lingering tunnel state.
- No subnet exposure. The MCP server appears at a single address. There is no virtual network to scan, no lateral movement possible from a compromised peer.
Pilot Protocol uses exactly this model: per-peer encrypted UDP tunnels with explicit handshake-based trust. An agent finds the MCP server by name (via a rendezvous registry), establishes a tunnel, and communicates — no VPN join, no subnet, no shared key. The trust is bidirectional and individually scoped.
When a VPN Is Still the Right Call
None of this says VPNs are bad. If you run a private MCP server for a fixed team of 5–10 agents that run on known machines, a Tailscale mesh is simple and effective. The overhead is negligible at that scale, and the mental model matches the deployment pattern.
The mismatch appears when the set of calling agents is dynamic — agents that appear and disappear, agents on different clouds, agents operated by different teams or organizations. At that point, the VPN's membership model starts working against you, and per-peer tunnels become simpler, not harder.
The Practical Takeaway
When you design the connectivity for an MCP server, ask yourself: how many entities need access, and how stable are they? If the answer is "a small, fixed set of machines I control," a VPN is the straightforward path. If it is "a growing set of agents I don't fully control, some ephemeral, some persistent," then per-peer tunnels with individual trust are a better architectural fit.
The two patterns are not in competition — they serve different deployment profiles. But confusing one for the other leads to unnecessary complexity, either from managing VPN membership for short-lived agents or from over-engineering tunnels for a static team.
For the agent-native case, Pilot Protocol's overlay network implements the per-peer tunnel model natively — it is built for agents, not for laptops. But the point stands regardless of the implementation: match the connectivity model to the actual agent lifecycle, not to the most familiar tool.
Top comments (0)