MCP tunnels shift AI access control behind the firewall

At a glance

What this is: Stacklok’s post explains how Anthropic MCP Tunnels invert the access path so internal systems can connect outward to Claude, with governance still needed around tool scope, identity, and observability.

Why it matters: IAM, PAM, and NHI teams need to treat MCP as an access-governance problem, not just a connectivity problem, because the tunnel changes the boundary but not the control requirements.

Context

Model Context Protocol, or MCP, is the integration layer that lets Claude and other AI surfaces call internal tools and data sources. In this architecture, the security question is not whether the model can connect, but how access is scoped, authenticated, and observed once the connection exists.

Stacklok frames the issue as a deployment problem for enterprises that want AI to reach internal systems without opening inbound network exposure. That moves the focus from perimeter exceptions to identity policy, segmented tool access, and the governance needed to promote experimental MCP servers into production.

The article is about a common enterprise pattern: useful AI tooling loses value if it is isolated from internal systems, but regulated environments will not accept the traditional way of exposing those systems. The starting position is typical for any organisation trying to operationalise AI against internal data and tools.

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. Scope tool permissions tightly, authenticate with strong identity controls such as OAuth and SSO, and limit what data sources an AI tool can query. For self-hosted deployments, keep the server inside the trusted environment and apply logging, review, and access boundaries to reduce accidental exposure.

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. If identity policy, tool segmentation, and audit logging are loose, the tunnel can still give an AI surface broad reach into internal systems with very little governance evidence.

Q: What breaks when MCP servers are shared across multiple AI surfaces without segmentation?

A: Least privilege breaks first, then accountability. Shared tool sets make it hard to prove which team or identity was supposed to have access, which means revocation, review, and incident analysis all become slower and less reliable.

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.

Technical breakdown

Why MCP tunnels change the network trust boundary

MCP tunnels reverse the usual client-server assumption. Instead of Anthropic reaching into a customer network, the customer network initiates the connection outward, which avoids inbound exposure while still allowing Claude to invoke internal tools. That is a meaningful architectural change because the trust boundary is no longer defined by a firewall exception alone. The transport can be protected with mutual TLS, while OAuth and platform policy handle higher-layer authorisation. For security teams, the important detail is that transport security does not equal governance. A safe tunnel can still expose too much if tool discovery, identity scoping, and auditability are loose.

Practical implication: Treat the tunnel as connectivity plumbing and separately govern which internal tools, identities, and sessions are actually allowed to use it.

How vMCP segmentation controls tool exposure

Stacklok’s virtual MCP Server aggregates multiple MCP servers behind a single endpoint and segments access by group. That matters because MCP can otherwise turn every connected tool into a shared blast radius. Group-based segmentation lets different teams see different tool sets, which is closer to identity governance than to simple integration management. The architectural pattern is familiar: one ingress, multiple policy domains, and a need to preserve least privilege across shared infrastructure. The challenge is that agentic access looks dynamic from the user’s point of view, but the controls still need stable ownership, revocation, and audit paths.

Practical implication: Model each MCP tool group as a governed entitlement set with explicit owners, review cycles, and revocation paths.

Why production-ready MCP needs policy and observability beyond the tunnel

The tunnel solves the reachability problem, not the operational problem. Enterprises still need to know which servers are available, who can use them, what each tool can access, and how those decisions are logged and reviewed. That is why the article places Stacklok on the customer side of the tunnel as the orchestration layer. In practice, this is where experimental AI access becomes an identity programme issue: configuration sprawl, inconsistent client setups, and unmanaged role-to-tool mappings all create hidden exposure. Without an operating model, the tunnel simply relocates the risk instead of reducing it.

Practical implication: Establish logging, health, and entitlement review for every MCP server before treating the tunnel as production infrastructure.

NHI Mgmt Group analysis

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.

Segmented MCP exposure is the right control pattern, but only if it is tied to identity lifecycle. Group-based tool segregation maps cleanly to least privilege, yet that privilege still has to be owned, reviewed, and revoked like any other entitlement. The article’s vMCP model is most useful when it is treated as an entitlement boundary rather than a convenience layer. The practitioner implication is to align tool groups with real business roles, not with ad hoc developer preferences.

Tool reachability without observability creates an identity blind spot. Once Claude or another AI surface can call internal systems, security teams need to see which tools were exposed, which identities were eligible, and which actions were actually taken. That is a governance issue, not just a logging issue. The implication is that MCP programmes need policy evidence, not only connectivity evidence.

AI access behind the firewall is now an operating model question. Enterprises can no longer assume that useful AI must be either isolated from internal systems or given broad, unmanaged access. The new middle ground is a controlled connection with explicit segmentation and enterprise identity policy. Practitioners should prepare for MCP to be managed as part of IAM and NHI governance, not as a separate AI integration project.

What this topic really exposes is identity fragmentation across AI surfaces. The article describes access across Claude Code, Claude Enterprise, and other Anthropic surfaces as if they were one operational domain, but that only works when the underlying identity policy is consistent. Without that consistency, teams end up with scattered approvals and uneven control strength. The implication is to standardise policy once and enforce it across every AI entry point.

From our research library:

• 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.
• Read next: MCP Security Guide

What this signals

Identity controls have to move with AI reachability: once a model can call internal systems through a tunnel, the operational question becomes which entitlements are exposed, not whether the firewall stayed closed. That shifts MCP into the same governance class as other non-human access paths, where ownership, review, and revocation matter more than the transport mechanism.

Tool segmentation is the real blast-radius control: group-based access to MCP servers is only useful if teams align it to business roles and keep it consistent across every AI surface. Otherwise, a single integration layer can quietly recreate the same overexposure that direct network access once caused.

For practitioners

• 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.
• Promote experimental connectors only through production controls Require health checks, monitoring, and change ownership for any MCP server moving from personal use into an organisation-wide deployment model.

Key takeaways

• MCP tunnels change where the access boundary sits, but they do not remove the need for explicit identity governance around AI tool use.
• Group-based tool segmentation is the central control pattern in this architecture because it limits how far any one AI surface can reach.
• Enterprises should manage MCP servers as governed entitlements with logging, ownership, and revocation, not as simple integration endpoints.

Key terms

• MCP tunnel: An MCP tunnel is a communication path that lets an AI agent reach tools or data through the Model Context Protocol. Technically, it is a controlled transport layer or relay that carries MCP messages between a client and a server, often across network boundaries, while preserving authentication, authorization, and session integrity.
• Virtual MCP: Virtual MCP is a curated access layer that exposes selected tool definitions through role-based endpoints instead of giving every client direct access to every available connector. It helps teams reduce tool sprawl, approve capabilities before use, and present a narrower, policy-controlled surface to agents. This supports safer deployment of enterprise tool access.
• Tool segmentation: The practice of limiting which tools an AI surface can reach based on role, group, or purpose. For AI-connected environments, segmentation is the difference between controlled access and a broad entitlement set that behaves like standing privilege.
• AI Access Event Governance: AI access event governance is the practice of treating every meaningful AI tool action as part of the identity and audit model. It links access, lifecycle, and evidence so that AI usage is governed as an enterprise control surface rather than an informal productivity layer.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.