Hosted clusters for local MCP servers change identity assumptions

At a glance

What this is: Pomerium Zero’s hosted clusters make local MCP servers reachable over SSH tunnelling, with the key finding that model access still needs identity-aware policy even when infrastructure friction drops.

Why it matters: This matters because MCP access changes the control plane for both NHI and emerging autonomous workflows, and IAM teams need to govern who or what can reach tools, not just which port is open.

👉 Read Pomerium's post on hosted clusters for local MCP server access

Context

Model Context Protocol server access often fails in practice because the server may be local, but the client that needs to reach it is remote. In plain terms, practitioners are trying to bridge a development machine and a public model without building a full production network path. For MCP governance, the question is not only connectivity but how access to tools is exposed, approved, and bounded across the identity stack.

Pomerium’s hosted cluster model removes some transport friction by turning an SSH reverse tunnel into a public HTTPS endpoint, but that does not remove the identity problem. The core issue for NHI and agentic access is that the tool endpoint becomes reachable before governance is mature, so teams need to decide whether the actor is a workload, an autonomous agent, or a human-assisted development flow.

Key questions

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. That means binding sessions to identity, scoping tool permissions, and requiring review for any endpoint that can be called by a model or agent. The control objective is to make exposure intentional, time-bounded, and attributable.

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. The tunnel solves connectivity, but it can also bypass the normal checkpoints that define who may connect, which tools they may invoke, and how long access should exist.

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. That creates overbroad tool invocation, weak accountability, and a larger blast radius if a model, user, or service account invokes the wrong action. Security teams should assume every unscoped tool is a potential privilege amplifier.

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.

Technical breakdown

SSH reverse tunnels and public MCP exposure

An SSH reverse tunnel lets a machine behind NAT or no public IP advertise a reachable endpoint by forwarding traffic back to localhost. In this MCP pattern, the reverse tunnel is the transport layer, while the public HTTPS URL is the access surface that frontier models can call. That simplifies local development, but it also means the exposed endpoint inherits the security properties of the local server, the tunnel session, and whatever policy checks sit in front of the request path. The technical risk is not the tunnel itself. It is treating transport convenience as equivalent to governed access.

Practical implication: treat tunneled MCP endpoints as real access points and require policy controls before tool invocation, not after exposure.

Identity-aware access for MCP tool calls

MCP tool access is not just about whether a model can connect. It is about whether the server can distinguish an approved caller, a scoped session, and a tool permission that matches the task. That is the difference between generic reachability and identity-aware access control. When an endpoint is reachable from a public model, the governance question becomes whether the request is bound to a user, a workload identity, or an autonomous runtime. Without that binding, the server can become a shared execution surface rather than a controlled integration point.

Practical implication: bind MCP sessions to identity context and scope tool permissions explicitly rather than relying on network isolation alone.

Why hosted clusters change the developer security boundary

Hosted clusters reduce the operational burden of getting an MCP server online, but they also collapse the traditional separation between local experimentation and externally reachable service. The local laptop or workstation is no longer just a dev box once it fronts a public endpoint. That makes secrets, tool scope, and request provenance more important than the transport choice. For identity teams, the key architectural lesson is that rapid exposure can outpace lifecycle governance. If the server can be reached immediately, then onboarding, scoping, and offboarding of that access path need to be just as immediate.

Practical implication: put MCP exposure behind lifecycle governance and short-lived access decisions, even during local development.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Tool access scope is the real control plane for MCP, not the tunnel. The tunnel only solves reachability. The security decision is whether each tool, session, and caller context is constrained enough to prevent unintended actions. In OWASP NHI terms, this is a permissions and exposure problem, not a deployment problem. Practitioners should recognise that exposed MCP endpoints create a standing opportunity for overbroad tool invocation unless access is explicitly bounded.

Hosted clusters lower friction, but they also widen the window for shadow AI-style experimentation. The easier it is to publish an MCP endpoint, the more likely teams are to expose tools before governance catches up. That is where unmanaged model-to-tool integrations start to resemble shadow AI from an identity standpoint. The implication is that discovery, policy, and offboarding must cover local-to-public MCP paths, not only sanctioned production services.

Short-lived exposure is not the same as controlled exposure. SSH tunnelling and ephemeral URLs reduce operational burden, but they do not establish durable assurance about caller identity, session scope, or tool intent. A public model can reach a server in seconds, while governance processes often assume slower, change-controlled exposure. Practitioners should re-evaluate whether their current access model still distinguishes between experimentation and authorised integration.

MCP runtime exposure gap: the governance assumption that a local service remains private until formally deployed fails once reverse tunnelling makes it public on demand. That assumption was designed for static environments where network boundaries implied control. The implication is that identity governance has to follow exposure timing, not just deployment status.

From our research:

• 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.
• For a broader control baseline, see Ultimate Guide to NHIs for lifecycle, visibility, rotation, and offboarding patterns that apply to MCP-style NHI exposure.

What this signals

MCP runtime exposure gap: as teams make local services reachable from frontier models, the security question moves from connectivity to authorization. The operational risk is that exposure can happen faster than governance, so discovery and scoping need to happen at the same speed as tunnelling and endpoint creation.

With 53% of MCP servers exposing credentials through hard-coded values in configuration files, per The State of MCP Server Security 2025, identity controls cannot stop at the endpoint. Teams need inventory, session attribution, and offboarding discipline for every temporary integration path.

For practitioners, the next step is to align MCP rollout with the same lifecycle thinking used for service accounts and workload identities. The more models can call tools directly, the more security programmes need explicit ownership, short-lived exposure, and reviewable change records.

For practitioners

• Classify MCP endpoints by actor type Decide whether each endpoint is serving a human developer, an NHI workload, or an autonomous agent. Apply different approval, scoping, and review rules to each class instead of using one blanket onboarding path.
• Require policy before public exposure Do not treat an SSH reverse tunnel or hosted cluster as harmless because it is easy to create. Require explicit tool scoping, caller identity binding, and session-level authorization before the endpoint is reachable from a model.
• Inventory all local-to-public MCP paths Track every workflow that turns localhost into a reachable service, including ad hoc tunnels used for testing. Include these paths in access reviews so experimentation does not become an unmanaged production dependency.
• Separate experimentation from sanctioned integration Use a distinct approval path for temporary developer testing versus long-lived MCP integrations. Temporary exposure should expire automatically, and sanctioned usage should carry documented ownership and offboarding.

Key takeaways

• Hosted MCP access is a governance issue as much as a connectivity issue, because public reachability does not equal authorised use.
• Hard-coded secrets remain common in MCP environments, which means exposure paths and credential hygiene have to be managed together.
• Teams should classify, scope, and offboard MCP endpoints with the same rigor they apply to other non-human identities.

Key terms

• Model Context Protocol: A protocol that lets AI models and agents connect to tools and data sources through a standard interface. In practice, it becomes an identity and access problem because each tool call still needs scoping, attribution, and policy enforcement.
• Reverse Tunnel: A network path that forwards traffic from an internet-reachable endpoint back to a local machine behind NAT or firewall controls. For identity teams, the key issue is that it can make an internal development service publicly reachable before governance catches up.
• 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.
• Tool Scope: The specific set of actions an AI model, workload, or user is allowed to invoke through a tool interface. In a governed environment, scope should be explicit, reviewable, and limited to the minimum needed for the task.

Deepen your knowledge

MCP server security and identity scoping are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are turning local tool exposure into a repeatable access model, this is a strong fit.

This post draws on content published by Pomerium: Hosted Clusters in Pomerium Zero and MCP hacking endpoints from localhost via SSH. Read the original.