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.
Why This Matters for Security Teams
Exposing a Kubernetes-hosted mcp server through a tunnel does not just expand reachability. It changes the trust boundary. If the tunnel credential becomes the only gate, tool execution is implicitly tied to network access rather than to the caller’s actual intent, identity, or task scope. That is especially dangerous for MCP because the server often sits close to secrets, internal APIs, and operational tooling.
NHI Management Group research has shown how often identity assumptions fail in practice, especially when access is broader than intended. In The 52 NHI breaches Report, recurring failure patterns include overexposed credentials and weak scoping around machine-to-machine access. For MCP specifically, OWASP Non-Human Identity Top 10 treats unmanaged service credentials and excessive privilege as first-order risks, not edge cases.
The practical problem is that a tunnel can make an internal service feel “private” while still allowing any holder of the edge token to reach high-value tools. In practice, many security teams discover this only after an agent or external caller has already invoked a capability that was reachable, but never intended to be broadly usable.
How It Works in Practice
A secure MCP deployment needs two separate decisions: can the caller reach the server, and what can the caller do once connected. A tunnel answers only the first question. Without scoped authorization, a Kubernetes service can remain technically internal while functionally exposed to any client that can present the tunnel secret or public endpoint.
That is why current guidance increasingly favors workload identity plus runtime authorization. The server should authenticate the caller as a specific workload or agent, then evaluate permission at the tool level, not just at the network edge. For agentic workflows, this aligns with the control logic described in OWASP Top 10 for Agentic Applications 2026 and the governance model in OWASP Agentic Applications Top 10, where tool misuse is treated as an authorization failure, not just a transport issue.
- Use a distinct identity for the MCP server and for each consuming workload.
- Issue short-lived credentials or tokens per session or per task.
- Enforce tool allowlists, not broad server-wide access.
- Log tool calls, caller identity, and request context for auditability.
- Revocate tunnel access independently from mcp authorization when sessions end.
For Kubernetes, this usually means pairing service identity with policy enforcement at the application layer, and avoiding any assumption that cluster locality equals safety. Mature teams also compare behavior against the attack patterns in the Analysis of Claude Code Security, because tool-bearing agents tend to chain actions faster than human operators expect. These controls tend to break down when the tunnel is shared across many users or agents because the edge credential becomes a de facto master key.
Common Variations and Edge Cases
Tighter authorization often increases deployment and policy overhead, requiring organisations to balance operational speed against blast-radius reduction. That tradeoff becomes sharper in development environments, where teams often expose MCP servers through tunnels for testing, demos, or remote debugging. Best practice is evolving, but there is no universal standard for this yet: a temporary tunnel is not automatically a safe boundary, especially when it fronts tools that can read secrets or mutate infrastructure.
Edge cases appear when one tunnel serves multiple agents, when the MCP server proxies into other internal systems, or when Kubernetes network policies are treated as the primary control. In those setups, a caller may legitimately authenticate to the tunnel but still inherit overly broad capability inside the server. That is exactly the kind of pattern seen in broader NHI failures described in the Ultimate Guide to NHIs.
Current guidance suggests separating public reachability from operational authority, then limiting each tool by context, workload identity, and explicit policy. If the tunnel must exist, treat it as an entry point, not as authorization. The model breaks down most severely when the MCP server has write access to production systems or secret stores, because one exposed edge credential can become a path from simple connectivity to full environment compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Tunnel exposure turns network access into overbroad non-human identity reach. |
| OWASP Agentic AI Top 10 | A2 | Agents can misuse reachable tools when authorization is not runtime-scoped. |
| CSA MAESTRO | CI-2 | MAESTRO addresses control-plane governance for agentic tool execution paths. |
| NIST AI RMF | AI RMF fits the risk of autonomous tool use beyond intended scope. | |
| NIST CSF 2.0 | PR.AC-4 | Least privilege is directly implicated when tunnels expose internal tools. |
Scope each MCP identity to specific tools and revoke any credential that grants blanket server access.
