TL;DR: Hosted clusters in Pomerium Zero let local MCP servers expose a public HTTPS endpoint over an SSH reverse tunnel, removing the need for manual tunnelling, TLS setup, or brittle ephemeral URLs so frontier models can call tools directly, according to Pomerium. The broader issue is that MCP access now depends on identity and policy decisions at runtime, not just network reachability.
NHIMG editorial — based on content published by Pomerium: Hosted Clusters in Pomerium Zero and MCP hacking endpoints from localhost via SSH
Questions worth separating out
Q: How should security teams govern local MCP servers that become publicly reachable?
A: They should treat public reachability as a governed access decision, not a networking shortcut.
Q: Why do reverse tunnels change MCP security risk?
A: Reverse tunnels change the risk because they convert a private local service into an externally reachable endpoint without forcing the same deployment controls as production.
Q: What breaks when MCP tool access is not scoped tightly enough?
A: Unscoped MCP access turns a narrow integration into a general-purpose execution surface.
Practitioner guidance
- Classify MCP endpoints by actor type Decide whether each endpoint is serving a human developer, an NHI workload, or an autonomous agent.
- Require policy before public exposure Do not treat an SSH reverse tunnel or hosted cluster as harmless because it is easy to create.
- Inventory all local-to-public MCP paths Track every workflow that turns localhost into a reachable service, including ad hoc tunnels used for testing.
What's in the full article
Pomerium's full post covers the operational detail this post intentionally leaves for the source:
- Step-by-step SSH reverse tunnel setup for hosted MCP exposure
- Local MCP development flow using ChatGPT's Apps SDK template
- Guidance on how the hosted cluster forwards to localhost over pom.run
- Practical notes on using the beta workflow for remote MCP servers
👉 Read Pomerium's post on hosted clusters for local MCP server access →
Local MCP servers over SSH tunnels: are your controls keeping up?
Explore further
Public MCP reachability is an identity problem before it is a networking problem. Once a local server can be called by a frontier model, the question shifts from transport setup to who or what is authorised to invoke tools. That matters because MCP collapses the distance between a local developer environment and a remotely reachable execution surface. The practitioner conclusion is simple: treat model-to-tool access as governed identity traffic, not as a convenience feature.
A few things that frame the scale:
- 53% of MCP servers expose credentials through hard-coded values in configuration files, according to The State of MCP Server Security 2025.
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, according to The State of MCP Server Security 2025.
A question worth separating out:
Q: How do you know whether MCP exposure is still controlled?
A: You know it is controlled when every reachable endpoint has a named owner, a specific caller identity, explicit tool limits, and a documented offboarding path. If the team cannot answer who can call it, which tools they can use, and when access expires, the exposure is not controlled.
👉 Read our full editorial: Hosted clusters for local MCP servers change identity assumptions
Public MCP reachability is an identity problem before it is a networking problem. Once a local server can be called by a frontier model, the question shifts from transport setup to who or what is authorised to invoke tools. That matters because MCP collapses the distance between a local developer environment and a remotely reachable execution surface. The practitioner conclusion is simple: treat model-to-tool access as governed identity traffic, not as a convenience feature.
A few things that frame the scale:
- 53% of MCP servers expose credentials through hard-coded values in configuration files, according to The State of MCP Server Security 2025.
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, according to The State of MCP Server Security 2025.
A question worth separating out:
Q: How do you know whether MCP exposure is still controlled?
A: You know it is controlled when every reachable endpoint has a named owner, a specific caller identity, explicit tool limits, and a documented offboarding path. If the team cannot answer who can call it, which tools they can use, and when access expires, the exposure is not controlled.
👉 Read our full editorial: Hosted clusters for local MCP servers change identity assumptions