Hosted clusters for local MCP servers change identity assumptions

At a glance

What this is: This is a Pomerium post about Hosted Clusters for local MCP servers, showing how an SSH reverse tunnel can publish a localhost tool endpoint as public HTTPS without manual infrastructure work.

Why it matters: It matters because MCP access control is shifting from simple network exposure to runtime identity and policy decisions, which changes how IAM and NHI teams think about tool access, trust boundaries, and sign-in enforcement.

Context

MCP changes the access problem by making tools reachable through model-facing endpoints rather than only through internal developer workflows. When a local server is exposed for external model calls, the security question is no longer just whether the network path exists, but whether identity, policy, and approval boundaries still hold at the moment the tool is invoked.

Hosted Clusters in Pomerium Zero address that transition by giving localhost MCP servers a public HTTPS URL over an SSH reverse tunnel. That improves developer convenience, but it also moves the governance boundary to runtime access control, where authentication, policy enforcement, and endpoint exposure need to be treated as part of the identity model, not as an afterthought.

For teams operating early MCP deployments, this is a typical pressure point rather than an edge case: the more usable the tool endpoint becomes, the more the programme must rely on governed access rather than assumptions about private reachability.

Key questions

Q: What breaks when private MCP servers are reachable only through shared tunnels?

A: Governance breaks when the access path can move traffic but cannot attribute the request to a person or enforce policy at the tool boundary. Shared tunnels may solve connectivity, but they leave auditing, approval, and accountability incomplete. The result is reach without meaningful identity control.

Q: Why do mixed public and private MCP tools create governance risk?

A: They collapse different trust levels into one runtime surface. A public health-check tool may share helpers, context, or deployment logic with a sensitive data tool, which can blur the real privilege boundary. Teams need to decide whether the mixed design is intentional, documented, and enforceable at tool level.

Q: How should teams handle secrets in MCP development workflows?

A: Treat secrets in MCP configs, scripts, and templates as operational credentials, not temporary developer clutter. Scan for embedded tokens, API keys, and certificates before a tool is exposed externally, and remove any credential that makes the tunnel reusable outside the original session. The goal is to avoid turning a local prototype into a durable secret store.

Q: When should organisations retire an exposed MCP tunnel?

A: Retire it as soon as the local server is no longer the active owner of that access path, such as after a rebuild, handoff, or project shutdown. The tunnel is part of the service lifecycle, so teardown should happen with offboarding rather than later. That prevents temporary exposure from becoming a standing route to the tool.

Technical breakdown

How SSH reverse tunnels change MCP exposure

An SSH reverse tunnel lets the remote side publish a local listener outward without opening inbound firewall paths. In this pattern, the MCP server still runs on localhost, but the tunnel terminates at a public endpoint that forwards traffic back to the developer machine. That removes the need for NAT traversal hacks, VPN clients, or ad hoc tunnelling services, but it also means the security boundary is now the authenticated tunnel session and the policy applied at the exposure layer, not the original local bind address.

Practical implication: Treat the tunnel as a governed access path and review who can establish it, not just what port the local server binds to.

Why public HTTPS endpoints change MCP trust assumptions

Frontier models and MCP clients generally expect an HTTPS endpoint they can reach directly. Once a local server is fronted by a public URL, the trust model shifts from private loopback usage to externally reachable service identity. That means authentication, authorization, and policy have to be enforced consistently at the edge, because the endpoint is now part of a broader tool ecosystem rather than a private developer-only process. The important change is not the transport itself, but the fact that reachability and authorization are no longer the same control.

Practical implication: Verify that external reachability does not bypass the same authentication and policy rules you would require for any other tool endpoint.

Why MCP dev loops create secret and policy sprawl

MCP development often involves quickly wiring together local servers, API-backed tools, and model clients while iterating on prompts or workflows. That speed creates pressure to use temporary URLs, short-lived tunnel services, or copied credentials in configuration files. The risk is not just exposure of a single endpoint but the accumulation of secrets, ad hoc access paths, and unclear ownership across the development loop. Once the tool becomes callable by an LLM, the identity and policy layer has to be treated as part of the software lifecycle, not as a separate deployment concern.

Practical implication: Inventory the secrets and access paths used in MCP development before they become the default production pattern.

Threat narrative

Attacker objective: The attacker objective is to reach a locally developed MCP tool through an externally exposed path and use that access to interact with its functions outside the intended trust boundary.

1. Entry occurs when a local MCP server is exposed through a public HTTPS endpoint instead of remaining bound to localhost.
2. Credential or tunnel abuse can follow if the SSH-based exposure path is reused without clear ownership or policy review.
3. Impact is the expansion of tool reachability to model clients and other external callers that can invoke the server directly.

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

Hosted MCP exposure turns local development into an identity problem, not just a networking problem. Once a localhost tool is published through a public HTTPS endpoint, network reachability becomes the easy part. The harder question is whether the access path has an accountable identity, a policy decision, and a reviewable control point. Practitioners should treat MCP publishing as governed access provisioning, not as temporary plumbing.

MCP identity assumptions were built for controlled tool access, and that assumption weakens when a model can call the server directly. Traditional developer workflows assume a human operator, a bounded session, and a relatively stable access path. When the caller is an LLM client reaching a publicly exposed endpoint, those assumptions no longer describe the real runtime behaviour. The implication is that access governance must move closer to issuance and policy evaluation, because the old perimeter is gone.

Ephemeral tunnel convenience creates durable governance debt. The easier it becomes to publish a local MCP server, the more likely teams are to accumulate one-off exposure paths, copied credentials, and undocumented service ownership. That is the kind of pattern that breaks lifecycle control, because nobody can confidently attest who can still reach what. Practitioners should reframe convenience tunnelling as a managed identity surface.

Local MCP endpoints need the same offboarding logic as any other externally reachable service. A hosted tunnel may feel temporary, but temporary access often becomes the path of least resistance. If ownership changes, a tool is retired, or the local server is rebuilt, the exposure route must be revoked with the same discipline used for other non-human identities and delegated access paths. The issue is lifecycle control, not just connectivity.

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

Hosted tunnel convenience creates a new MCP governance surface: once a local server is reachable over a public URL, access review has to include the exposure path, not just the tool itself. That is where many early MCP programmes will miss ownership, because the server still feels local even after the endpoint becomes public.

The practical shift is toward issuance-time control and endpoint inventory. If a developer can publish a localhost tool for external model calls with a single tunnel command, the programme needs a policy model that tracks who can expose it, who can invoke it, and when that exposure is revoked.

MCP exposure is already producing measurable secret sprawl, with 24,008 unique secrets exposed in configuration files in 2025 alone, according to the State of Secrets Sprawl 2026. That number reinforces the same lesson for practitioners: the faster the tool path, the more important it is to govern the credentials and tunnel lifecycle behind it.

For practitioners

• Govern MCP exposure as a managed access path Treat any public endpoint for a local MCP server as an explicit access channel with ownership, approval, and revocation rules. Document who may publish the tunnel, which model clients may reach it, and how the exposure is withdrawn when development ends.
• Separate development convenience from persistent trust Do not let temporary tunnel workflows become the default pattern for tool access. Require a named owner, a reviewable policy, and a traceable endpoint record before a local server can be called by external clients.
• Inventory secrets used in MCP configuration Scan local MCP configs, templates, and helper scripts for embedded API keys, tokens, or other credentials that make the tunnel path usable. Remove any hard-coded secret before the endpoint is shared beyond the developer machine.
• Tie tunnel teardown to lifecycle offboarding When an MCP server is retired, rebuilt, or handed to another owner, revoke the public tunnel and any related access configuration at the same time. Temporary exposure should not survive the server that justified it.

Key takeaways

• Public exposure of local MCP servers changes the problem from simple connectivity to governed identity and policy enforcement.
• Tunnel-based convenience can hide a larger lifecycle issue, because the access path often outlives the server or the developer session that created it.
• Practitioners should inventory tunnel ownership, review embedded secrets, and tie endpoint teardown to offboarding of the underlying tool.

Key terms

• Hosted MCP: Hosted MCP is a deployment model where a Model Context Protocol server runs in a managed or remote environment rather than on the local machine. It exposes tools, data, or actions to AI agents through MCP interfaces, while the host controls availability, authentication, logging, and operational boundaries.
• Reverse SSH Tunnel: A reverse SSH tunnel is an outbound connection initiated from one system to another so that remote access can be established without opening inbound firewall rules. In this article, it is used to create controlled connectivity for session protocols and API traffic while avoiding direct internet exposure of internal infrastructure.
• MCP Exposure Surface: The set of endpoints, tools, and sessions that can be reached through an MCP integration. It is broader than the network path alone because it includes identity context, tool permissions, and the lifetime of the access path.
• Runtime Access Decision: An access decision made using live context at the moment a request is evaluated or enforced. It combines identity data with current security signals so the control can respond to present risk instead of relying only on a prior approval or certification.

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 building or maturing an IAM programme, it is worth exploring.