Kubernetes-hosted MCP exposure raises new identity governance gaps

At a glance

What this is: This is a how-to for exposing a Kubernetes-hosted MCP server externally, and the key finding is that simple tunnelling and edge auth can still leave identity governance fragmented.

Why it matters: It matters because IAM, PAM, and NHI teams now have to govern how AI-tool infrastructure is exposed, authenticated, and monitored across cluster, host, and internet boundaries.

By the numbers:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
• 53% of MCP servers expose credentials through hard-coded values in configuration files.

👉 Read Stacklok's walkthrough on exposing a Kubernetes-hosted MCP server

Context

MCP server exposure is not just a networking choice. It is an identity and authorization problem because the moment an internal tool surface becomes reachable outside the cluster, the question shifts from service reachability to who or what is allowed to invoke tools, under which controls, and with what audit trail.

For Kubernetes-hosted MCP deployments, the governance gap is usually split across teams. Platform teams own the cluster, identity teams own credentials and access policy, and AI teams own the tool chain, but the resulting exposure path crosses all three. That makes ad hoc tunnelling and local forwarding risky unless the full access path is treated as governed NHI infrastructure.

This pattern is typical for early-stage MCP adoption, where convenience for testing and demos arrives before formal access scoping, lifecycle controls, and runtime monitoring have been defined.

Key questions

Q: What breaks when a Kubernetes-hosted MCP server is exposed through a tunnel without scoped authorization?

A: The main failure is that network reachability becomes confused with permission. A public tunnel can make an internal MCP server reachable, but without tool-level scoping, any caller with the edge credential may invoke more capability than intended. That creates a wider blast radius than the operator usually expects.

Q: Why do MCP servers create new NHI governance concerns?

A: MCP servers create new NHI governance concerns because they expose application capability to non-human callers through tools and prompts that can be invoked at runtime. That shifts the question from who can reach an API to what an agent is allowed to decide and execute. The governance challenge is preventing the agent from inheriting broader privilege than the user or workflow intended.

Q: How do security teams know if an MCP deployment is outside its intended boundary?

A: Look for any server that is reachable beyond its expected network scope, accepts tool calls without strong identity proof, or can act on systems it was not explicitly scoped to touch. Strong warning signs include localhost servers accessible from the browser, public endpoints with no auth, and tool catalogs that exceed the intended use case.

Q: Who should be accountable for exposing MCP servers in Kubernetes?

A: Accountability should sit with the team that owns the workload, but it must be shared across platform, identity, and application stakeholders. If one team can open the tunnel while another owns the credentials and a third owns the tools, then the operating model needs explicit approval and revocation rules before production use.

Technical breakdown

How Kubernetes exposure changes MCP trust boundaries

A Kubernetes-hosted MCP server begins as an in-cluster workload with a limited service boundary, but port-forwarding and tunnelling deliberately extend that boundary to a host or internet edge. The technical issue is not the tunnel itself. It is that the server now depends on multiple layers of access control, first at the Kubernetes service level, then at the transport layer, then at the MCP tool layer. If those layers are not aligned, the effective trust boundary is wider than the operator thinks.

Practical implication: treat the tunnel path as part of the identity perimeter, not just the network path.

Why edge authentication is not the same as tool authorization

Basic Auth at the ngrok edge validates a request before it reaches the tunnel, but it does not answer whether the caller should be allowed to invoke a specific MCP tool or access a specific data source. In MCP environments, transport authentication, application authentication, and tool-level authorization are separate controls. A valid header can prove a shared secret, yet still leave overbroad tool access untouched if the server itself does not enforce scoping and auditability.

Practical implication: separate edge access checks from per-tool authorization and review both independently.

Declarative Kubernetes resources create a governed identity surface

ToolHive’s operator model turns MCP servers into Kubernetes resources, which helps with repeatability and management, but also means identity state is now expressed in manifests and runtime objects. That is useful for governance because it gives teams a place to inspect desired state, drift, and exposure. The catch is that declarative deployment does not equal governance by itself. Access scope, credential handling, and revocation still need explicit lifecycle controls around the server and its tunnel.

Practical implication: define ownership, expiry, and review rules for MCP deployments the same way you would for other non-human identities.

Threat narrative

Attacker objective: The attacker objective is to reach an externally exposed MCP tool endpoint and use it as a foothold into internal data sources or workflows.

1. Entry occurs when a Kubernetes-hosted MCP server is bridged from an in-cluster ClusterIP service to localhost and then to a public ngrok endpoint. Escalation occurs if the exposed endpoint relies on a shared Basic Auth secret rather than per-caller or per-tool authorization. Impact occurs when anyone with the exposed credential can reach the tool surface and invoke cluster-backed capabilities outside the original trust boundary.

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

MCP exposure is now an NHI governance problem, not a developer convenience pattern. Once a Kubernetes-hosted MCP server is tunneled beyond the cluster, the real control question becomes how service identity, transport exposure, and tool permissions are governed together. A shared edge secret may be enough for a demo, but it is not a complete identity model for production access. Practitioners should treat exposed MCP endpoints as managed non-human identities with explicit lifecycle and policy boundaries.

Transport authentication does not resolve tool authorization drift. The article’s Basic Auth step proves a caller knows a secret, but it does not prove the caller should access every exposed tool path or backend source. That is the same failure mode seen in many NHI environments: one control is applied at the edge, while the actual permission boundary remains implicit. The field should stop treating tunnel access as equivalent to governed execution.

Declarative deployment changes the ownership model for MCP, but not the governance burden. When MCP servers become Kubernetes resources, they inherit the same lifecycle questions as other machine identities: who approves exposure, who reviews it, and when it is revoked. The new concept here is a temporary exposure window, where a workload is externally reachable for testing or integration long before its access model is mature. That window must be managed as a policy object, not a side effect.

Access scoping is the missing control plane for MCP adoption. The most important gap is not whether the server can be reached, but whether each tool invocation can be bounded to the minimum necessary access. In practice, many teams will solve connectivity first and defer scoping, which creates governance debt that compounds as more AI agents and integrations depend on the same endpoint. Security teams should expect MCP to accelerate NHI sprawl unless they define scoping early.

This pattern links workload identity and agentic AI governance. MCP is often discussed as plumbing, but in practice it is the access fabric for AI tools, backend services, and data sources. That makes it relevant to both NHI governance and agentic AI oversight because the same exposed endpoint may later be consumed by autonomous systems. Practitioners should evaluate MCP exposure as part of the broader identity plane, not as an isolated integration choice.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• That visibility gap is why teams should pair exposure reviews with a second read on Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs when they move MCP servers toward production.

What this signals

Temporary exposure windows: Kubernetes-hosted MCP servers are likely to become a normal part of AI integration work, which means security teams need a distinct governance model for time-bound external access. The practical issue is not whether a tunnel exists, but whether it is owned, expiring, and audited as part of the identity programme. That is the point at which NHI lifecycle controls stop being theoretical and become operational.

The broader signal is that agent-adjacent infrastructure is collapsing the old line between app exposure and identity governance. When a tool endpoint can be surfaced for a demo, a branch office, or a test integration in minutes, the organisation needs policy that follows the endpoint, not just the cluster. For workload identity and access scoping patterns, the SPIFFE workload identity specification remains a useful reference point.

For practitioners

• Define MCP exposure as governed identity surface Classify every externally reachable MCP endpoint as a managed non-human identity with an owner, review date, and explicit revocation path. Include the tunnel endpoint, the Kubernetes service, and any edge policy in the same inventory so exposure does not outlive the original use case.
• Separate edge authentication from tool permissions Use edge authentication only as a gate, then enforce per-tool and per-backend authorization inside the MCP layer. Review whether a caller with a valid tunnel credential can still reach tools that should be isolated, especially where the server fronts internal data sources.
• Shorten temporary exposure windows Set expiry and review criteria for tunnels created for demos, tests, and partner access. A temporary public URL should be treated as a time-bound exception with explicit teardown, not as a reusable access path that quietly becomes part of normal operations.
• Add audit evidence to MCP access Log who opened the tunnel, which credentials were used, which tools were invoked, and when the endpoint was revoked. If the team cannot reconstruct that chain, the MCP deployment is not ready for production use.

Key takeaways

• Kubernetes-hosted MCP exposure turns a network shortcut into an identity governance decision because access, scope, and audit all move together.
• Basic Auth at the tunnel edge can authenticate a caller, but it does not by itself limit what that caller can invoke inside the MCP tool surface.
• Treat temporary public endpoints as governed NHI exceptions, with ownership, expiry, and revocation defined before the server is exposed.

Key terms

• Mcp Endpoint Exposure: The act of making an MCP server reachable beyond its original trust boundary, usually through tunnelling, proxying, or cloud networking. In practice, exposure changes the control problem from service availability to governed access, because the endpoint can now be invoked by callers outside the cluster or host boundary.
• Exposure Window: The period in which a credential, session, or privilege grant can be exploited before it is revoked or expires. Shorter windows help, but they do not solve the deeper question of whether the access remains justified for the full time it is active.
• Tool-level Authorization: Tool-level authorization is the practice of checking permissions on each discrete action a client asks an MCP server to perform. It matters because LLMs can generate dynamic requests, so access control must be enforced where the action is executed, not only where the request is formed.

What's in the full article

Stacklok's full blog post covers the operational detail this post intentionally leaves for the source:

• Exact kubectl and thv proxy commands for deploying the ToolHive operator and opening the tunnel
• The sample ngrok traffic policy file used to enforce Basic Auth at the public edge
• The exact request and response behaviour for authorised versus unauthorised calls
• The implementation sequence for bridging a ClusterIP service to localhost before exposing it externally

👉 Stacklok's full post shows the deployment sequence, tunnel configuration, and edge policy details.

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.