Topic starter
18/08/2026 2:56 pm
TL;DR: Anthropic MCP Tunnels invert the traditional network exposure model by letting internal systems reach out to Claude, while Stacklok adds the policy, segmentation, and orchestration layer needed to make MCP usable in production. The real issue is not connectivity but governance: tool scope, identity controls, and observability must move with the tunnel, or AI access simply recreates old risk in a new path.
Editorial analysis by NHI Mgmt Group, based on content published by Stacklok: “Stacklok and Anthropic MCP Tunnels: securely connect Claude to everything behind your firewall”.
Key questions
Q: How should teams secure AI tool access to internal data through MCP servers?
A: Security teams should treat MCP access as a governed integration, not a convenience layer.
Q: Why can a secure tunnel still leave AI access risk unresolved?
A: Because transport security protects the path, not the decision to expose a tool.
Q: What breaks when MCP servers are shared across multiple AI surfaces without segmentation?
A: Least privilege breaks first, then accountability.
Practitioner guidance
- Define MCP tool groups as governed entitlements Map each virtual MCP server or connector set to a named business role, then assign ownership, review cadence, and revocation responsibility before exposing it to AI surfaces.
- Separate transport security from access policy Use mutual TLS and OAuth as baseline controls, but require explicit authorisation rules for which identities can reach which internal tools and under what conditions.
- Standardise logging for all AI-to-tool actions Record which AI surface invoked which MCP server, which group policy allowed it, and what internal system was reached so the access path remains auditable.
Bottom line: MCP tunnels change where the access boundary sits, but they do not remove the need for explicit identity governance around AI tool use.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
18/08/2026 3:38 pm
MCP tunnels do not remove the governance problem, they relocate it. The security conversation shifts away from inbound exposure and toward the identity decisions that happen after the tunnel is established. That means access scope, approval boundaries, and auditability become the real control plane. Practitioners should stop treating MCP connectivity as a network exception and start treating it as a governed access path.
A few things that frame the scale:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: What is the difference between MCP support and secure MCP governance?
A: MCP support means a client and server can exchange messages successfully. Secure MCP governance means the enterprise has defined which authentication methods, tenant rules, and session constraints are acceptable before the connection is allowed. A working session is not the same thing as a governed session.
👉 Read our full editorial: MCP tunnels shift AI access control behind the firewall