Inside Anthropic’s MCP tunnels: where authentication actually ends

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Tego AI's blog post: Anthropic's MCP tunnel architecture ends authentication at the edge, leaving the internal proxy reachable without credentials if network controls are weak.

Why it matters: It matters because IAM and NHI teams need to treat tunnel proxies, upstream MCP servers, and internal segmentation as part of the trust boundary, not just the public entry point.

Context

MCP tunnels solve a practical access problem, but they do not remove the need to define where trust actually begins and ends. In this setup, the public edge can be protected while the internal proxy still becomes the real enforcement point for non-human identity traffic.

The core issue is not tunnelling itself but the assumption that edge authentication covers the entire path. If a private MCP proxy accepts traffic from anything that can reach it on the internal network, the identity model shifts from protocol trust to internal proxy segmentation.

That makes the tunnel a governance problem as much as a transport problem. Security teams need to understand which layer is authenticating the caller, which layer is only routing, and where the private network becomes the de facto control plane.

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. Any internal workload that can reach the proxy may be able to impersonate the intended backend caller, which turns segmentation into the only effective control. That creates an identity problem, because the proxy is trusting network location instead of validating who is actually acting.

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. If authentication happens before the traffic enters the tunnel, but the proxy accepts internal connections without checking those credentials again, then a laterally positioned workload can bypass the original trust decision and reach private tools.

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. That hop is where the actual request, arguments, and response are visible, so it is the only place that can tell you what the agent really did. Administrative logs alone do not reconstruct usage.

Q: Should organisations treat MCP proxies as privileged infrastructure or simple routing components?

A: They should treat them as privileged infrastructure. The proxy is the point where routed identity, policy, and visibility all converge, so a weakly protected proxy can become a hidden control plane for private tool access. Routing alone is not a sufficient security model when the proxy can impersonate the trusted caller.

Technical breakdown

Where the MCP tunnel trust boundary actually sits

The tunnel stack separates public-edge authentication from private-network routing. Cloudflare Access can validate the caller before the request enters the tunnel, but mcp-proxy is a separate component that may not re-check that identity once traffic reaches port 8080. That means the proxy is not the same trust domain as the edge, even if the traffic looks end-to-end protected in transit. In practice, the control boundary moves inward to the internal network, where any host that can reach the proxy may be able to impersonate the intended caller unless the deployment isolates that path. See the NHI Authentication Guide.

Practical implication: Treat the proxy as a separate protected service, not as an extension of the public edge.

Why plaintext appears between the proxy and the upstream MCP server

The article shows that the mcp-proxy to upstream hop carries plain HTTP after the inner TLS session is terminated at the proxy. That creates a deliberate inspection point: the proxy can route, rewrite, and forward tool calls, but the upstream leg is where policy, audit, and credential handling become visible. This is a classic choke point for NHI governance because it is the first place where tool arguments, headers, and responses can be observed in cleartext. If that hop is trusted too broadly, the architecture becomes easy to traverse but hard to govern.

Practical implication: Place policy and audit controls at the proxy-to-upstream boundary, not only at the tunnel edge.

Why internal network reach changes the authentication model

The article's key finding is that the proxy checks whether a WebSocket upgrade arrives on the correct port, not whether the caller still has the original edge credentials. That means a workload inside the customer network can skip the public authentication layer entirely and still present itself as Anthropic to the proxy. This is a non-human identity problem because the identity being trusted is the backend caller, not a human user. Once network reach becomes the deciding factor, authentication and segmentation are no longer separate concerns; segmentation is now part of identity enforcement.

Practical implication: Restrict which workloads can reach the proxy, because network adjacency becomes an authentication substitute.

Threat narrative

Attacker objective: The attacker wants to use the private MCP path as if they were Anthropic's backend, gaining unauthorized tool access and protocol reach into the customer's upstream server.

1. Entry occurs when an internal workload or container reaches mcp-proxy:8080 without needing the original edge identity checks.
2. Credential access is bypassed because the proxy does not revalidate the Cloudflare Access JWT or client certificate once the connection is inside the network.
3. Escalation happens when the caller can impersonate Anthropic's backend and drive the upstream MCP server through normal tool flows.
4. Impact is the ability to execute tool calls and inspect responses through the private MCP path without the intended authentication boundary.

Breaches seen in the wild

• Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Authentication that ends at the edge is not end-to-end authentication. The article shows that the tunnel validates the caller before the proxy, but the proxy itself does not re-run those checks. That means the real trust boundary is not the public hostname, it is the internal network path to mcp-proxy:8080. Practitioners should treat edge identity as necessary but insufficient when a private proxy can still be reached from inside the environment.

Internal network reach becomes an identity control when the proxy trusts transport more than caller identity. Once any sibling container or adjacent workload can reach the proxy, the network layer is doing the work that authentication was assumed to do. That is a governance failure, not just a deployment mistake, because the organisation has implicitly converted segmentation into identity assurance. The right mental model is that access to the proxy is itself privileged access.

Plaintext between proxy and upstream creates the audit seam that most MCP deployments will miss. The proxy-to-upstream hop is where tool calls, arguments, and responses become inspectable, which makes it the natural place for logging and policy enforcement. Without that control point, teams may know that a tunnel exists but not what happened through it. That gap is especially serious when MCP access reaches internal systems, because attribution and containment both depend on the same hop.

Tool access control for MCP tunnels is a non-human identity problem, not just a network problem. The article's design shows that the caller on the inner path is effectively a service identity with delegated authority, even when the public edge handles the initial authentication. That means the governance question is who or what can act through the proxy, under what scope, and with what evidence. Internal trust without identity revalidation is where delegated access becomes unbounded.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• Read next: MCP Security Guide

What this signals

Internal proxy trust will become the weak point in many MCP deployments. The public edge may look well controlled, but the operational risk shifts to whatever can reach the private proxy inside the environment. Teams should expect that segmentation, not just authentication, will define whether MCP access is governable in practice.

Proxy-centric governance is now the right model for MCP. The security question is no longer whether a tunnel exists, but whether the proxy can prove who is connecting, what it forwards, and where it stops trusting the caller. That is why MCP programmes need control points at the internal boundary, not only at the public edge.

Identity blast radius: the scope of trust expands when a routed identity can cross from edge-authenticated traffic into unauthenticated internal access. Once that boundary collapses, a single network path can expose both tool invocation and audit blind spots. Practitioners should assume that MCP visibility and containment must be designed at the same hop.

For practitioners

• Isolate the MCP proxy from lateral network reach Allow only the tunnel daemon and approved control-plane components to reach mcp-proxy:8080. Use network policy, host firewalling, or segment-level ACLs so that sibling containers and other internal workloads cannot impersonate the upstream caller.
• 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.
• Validate the trust boundary with a direct connectivity test From an internal host that should not be privileged, attempt to reach the proxy and confirm that the connection fails before any WebSocket upgrade can succeed.

Key takeaways

• The central risk is not the tunnel itself, but the gap between edge authentication and internal proxy trust.
• The article shows that a reachable proxy can accept connections without revalidating the original caller identity.
• The practical control is to combine strict network segmentation with upstream authentication and proxy-level audit logging.

Related NHI Mgmt Group resources: MCP Security Guide · NHI Authentication Guide · AI Agent Observability, Audit and Incident Response Guide · OWASP Agentic Applications Top 10

Key terms

• MCP tunnel: An MCP tunnel is a communication path that lets an AI agent reach tools or data through the Model Context Protocol. Technically, it is a controlled transport layer or relay that carries MCP messages between a client and a server, often across network boundaries, while preserving authentication, authorization, and session integrity.
• Proxy Trust: Proxy trust is the assumption that traffic forwarded by a reverse proxy can be treated as internal or local. That assumption can fail when forwarded headers, client identity, and source address are not verified. In agent systems, bad proxy trust can turn external requests into privileged ones.
• Delegated Support Authority: The limited permission given to help desk or service desk staff to change identity attributes, reset credentials, or confirm access. It is a governance concept, not a technical feature, and it must be tightly scoped because it can function like privileged access when abused.
• Internal segmentation: Internal segmentation is the practice of separating systems, data, and trust zones inside the network so compromise in one area does not automatically expose another. It is not just a routing design, but an access-control and monitoring strategy that limits blast radius after initial intrusion.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.