MCP tunnels and proxy trust boundaries: what do teams miss?

TL;DR: Anthropic's MCP tunnel design authenticates callers at the edge, but mcp-proxy accepts any WebSocket connection that can reach port 8080 inside the customer network, shifting the real trust boundary to internal segmentation and upstream controls, according to Tego AI. The practical lesson is that tunnel security depends on where authentication stops, not on the presence of tunnelling itself.

Editorial analysis by NHI Mgmt Group, based on content published by Tego AI: “Inside Anthropic's MCP tunnels”.

Key questions

Q: What breaks when an MCP proxy is reachable from inside the network without reauthentication?

A: The public authentication boundary stops protecting the private path.

Q: Why do internal MCP tunnels create risk even when the edge is authenticated?

A: Because the edge and the proxy are not the same control point.

Q: How should teams audit MCP traffic when the proxy forwards plaintext to the upstream server?

A: They should capture tool calls at the proxy-to-upstream hop, not just tunnel lifecycle events.

Practitioner guidance

• Isolate the MCP proxy from lateral network reach Allow only the tunnel daemon and approved control-plane components to reach mcp-proxy:8080.
• Require upstream authentication for every MCP server Make OAuth or an equivalent upstream control mandatory on each private MCP server so that a caller who reaches the proxy still cannot invoke tools without separate authorization.
• Instrument the proxy-to-upstream hop Log tool names, arguments, responses, and caller context at the point where the proxy forwards requests to the private server, because edge lifecycle logs alone do not show actual tool use.

Bottom line: The central risk is not the tunnel itself, but the gap between edge authentication and internal proxy trust.

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →  |  Read the full analysis →