Notifications
Clear all
Topic starter
20/08/2026 5:38 pm
TL;DR: A Kubernetes-hosted MCP server can be exposed through ToolHive, port-forwarding, and ngrok with Basic Auth, highlighting how quickly internal tool access can cross a trust boundary, according to Stacklok’s walkthrough. The larger issue is that MCP connectivity turns workload identity, transport exposure, and tool authorization into one governance problem that existing IAM patterns do not fully cover.
NHIMG editorial — based on content published by Stacklok: Blog Integrations Exposing a Kubernetes-hosted MCP server with ToolHive + ngrok
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.
Questions worth separating out
A: The main failure is that network reachability becomes confused with permission.
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.
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.
Practitioner guidance
- 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.
- 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.
- Shorten temporary exposure windows Set expiry and review criteria for tunnels created for demos, tests, and partner access.
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
👉 Read Stacklok's walkthrough on exposing a Kubernetes-hosted MCP server →
Kubernetes-hosted MCP exposure: are your controls ready for it?
Explore further
20/08/2026 6:23 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Kubernetes-hosted MCP exposure raises new identity governance gaps
