5 Tips for Deploying Anthropic MCP Tunnels in a Regulated Enterprise Environment (2026)

Enterprises in regulated industries face a structural problem when deploying Claude with internal tooling: the AI model lives at Anthropic, and your most sensitive data lives behind a firewall. Traditional MCP server deployments require exposing internal infrastructure to the internet, which security teams reject outright. Anthropic MCP Tunnels solves this by inverting the connection direction, and Stacklok provides the enterprise management layer that makes it production-ready.

This guide is written for platform engineers and DevOps teams responsible for deploying AI infrastructure in environments with strict network security requirements: financial services, healthcare, government contractors, and any organization operating under zero-trust network policies.

---

What Anthropic MCP Tunnels begin and end

Anthropic MCP Tunnels eliminate the need for inbound ports by having your infrastructure reach outward to Anthropic, rather than having Anthropic reach into your network. No firewall rules need to change and no inbound ports need to open.

On the Anthropic side, an internal service called Toolbox acts as the MCP client. Toolbox powers MCP calls across the entire Anthropic product surface: Claude Code, Claude Enterprise, and agentic products. Every MCP call from every Anthropic product routes through Toolbox, which means a single tunnel deployment gives your team access to centrally managed MCP servers from any Anthropic surface.

The tunnel handles the secure transport, but there are critical capabilities it does not address:  server lifecycle management, access control policy, identity federation, observability, or the operational path from developer experiment to production Kubernetes workload. That is where Stacklok comes in.

---

Tip 1: Treat the tunnel as the transport layer, not the security layer

The tunnel provides a secure, outbound-only channel between your infrastructure and Anthropic’s Toolbox service, secured with mutual TLS and an additional Anthropic-managed encryption layer on top.

What the tunnel does not do: decide which of your employees can access which tools, enforce policy about which MCP servers are available to which teams, or produce an audit log your compliance team can query.

For regulated environments, those controls are non-negotiable. Plan for a management layer on the customer side of the tunnel that handles identity, policy, and observability independently of the transport. Stacklok sits in this position: it aggregates your MCP servers, enforces access policy via your existing identity provider, and feeds structured audit logs to your SIEM. The tunnel connects Stacklok to Anthropic. Stacklok governs everything behind it.

The architectural principle here is defense in depth. Do not rely on the tunnel alone for security. Build your access controls at the layer you control.

---

Tip 2: Segment tool access by team before you go live

The tunnel gives every Anthropic product surface access to your MCP servers simultaneously. Claude Code, Claude Enterprise, and agentic products all route through the same Toolbox service. This is a feature: configure your tools once, and every surface gets them. But it creates an access control problem if you have not thought through segmentation first.

A developer should not be able to call your HubSpot MCP server. Your marketing team should not be able to reach your internal engineering metrics API. Without deliberate segmentation, a single tunnel deployment exposes every tool to every user.

The right architecture uses a Virtual MCP Server (vMCP) layer to create segmented endpoints before the tunnel connection is established. Each endpoint aggregates a specific subset of your MCP servers and enforces access using your enterprise identity provider group membership. Your engineering team gets one endpoint, while marketing gets another. A shared endpoint covers tools everyone needs, like Slack or Google Drive.

As of May 2026, Stacklok’s vMCP feature handles this segmentation natively, with access gated by Okta, Microsoft Entra ID, or Google Workspace group membership. The decision about which tools belong in which segment should be made with your security team before deployment, not discovered through incident response afterward.

---

Tip 3: Wire in your identity provider on day one

The most operationally painful mistake in early MCP deployments has been credential sprawl: each developer managing their own tokens, each MCP server configured separately per client, credentials stored locally with no rotation policy, etc. The tunnel architecture gives you the opportunity to eliminate this entirely, but only if you connect your enterprise identity provider at the start.

The correct model: authenticate once through your IdP, and that identity governs access to every MCP server, across every Anthropic surface, for every team member. No locally stored credentials or per-device MCP configuration, because there are no local credentials to rotate.

For regulated industries, this is not optional. SOC 2, HIPAA-adjacent, and FedRAMP-adjacent requirements all expect centralized credential management and the ability to revoke access instantly when an employee leaves. A deployment where credentials live on developer laptops fails this requirement by design.

Stacklok’s embedded authorization server supports OIDC and OAuth 2.0, with native integrations for Okta, Microsoft Entra ID, and Google Workspace. Connecting your IdP is a configuration step, not a development project. Do it before any team member connects a real MCP server to a real Anthropic surface.

---

Tip 4: Scope each MCP server’s permissions to the minimum required access

The tunnel and the identity layer control who can call which tools. Container isolation controls what those tools can do once called. These are different threat surfaces, and both need to be addressed.

Every MCP server should run with the minimum permissions required to perform its function. A GitHub MCP server needs outbound HTTPS access to the GitHub API. It does not need access to your internal database subnet, your Slack API credentials, or the local filesystem beyond what its process requires. A misconfigured or compromised MCP server with broad permissions is a significant lateral movement risk.

The practical approach: define network egress rules per MCP server, restricting outbound connections to the specific hosts and ports that server legitimately needs. Set filesystem access to read-only unless a specific write requirement exists. Apply these profiles before the server is accessible through the tunnel.

This matters particularly for supply chain security. MCP servers are software dependencies, and the MCP ecosystem is young. An attacker who compromises an upstream MCP server package gains the permissions you granted it. Minimal permissions limit that blast radius. Stacklok enforces these isolation profiles at the container level, and the team behind it, founded by Craig McLuckie, co-founder of Kubernetes, built supply-chain security into the architecture from the start rather than adding it later.

---

Tip 5: Set up observability before you need it

In a traditional API deployment, you know what your services are doing because you instrumented them. MCP deployments have the same requirement, but most teams skip it during initial rollout. 

The specific observability gap the tunnel creates: tool calls now originate from AI agents, not directly from your developers. A developer running a bad query is visible in your logs and traceable to a person. An AI agent running thousands of tool calls is not visible at all unless you have instrumented the MCP layer. For financial services teams with data access logging requirements, this is not a theoretical concern.

At minimum, instrument three things before go-live. First, request volume per MCP server and per access group, so you can detect anomalous usage patterns. Second, authentication failures, because any unexpected spike indicates either a misconfigured policy or an access attempt outside normal patterns. Third, the full request metadata for tool calls touching sensitive systems, structured and exported to your SIEM.

Stacklok exports OpenTelemetry metrics aligned with the OTel MCP semantic conventions and structured JSON audit logs compatible with Splunk, Datadog, New Relic, and Elastic. 

---

The underlying principle

Each of these tips points at the same underlying architecture decision: the Anthropic tunnel solves the network security problem, and Stacklok solves the enterprise governance problem. Neither is complete without the other for a regulated production deployment.

Teams that deploy the tunnel without the governance layer end up with a fast proof of concept that their security team cannot approve for production. Teams that build governance without the tunnel stay blocked on the inbound port problem. The combination, an outbound-only transport with a Kubernetes-native governance stack on the customer side, is what makes this architecture viable in financial services, healthcare, and other regulated industries.

---

Want to see what Stacklok can do for your organization? Book a demo or get started right away with ToolHive, our open source project. Join the conversation and engage directly with our team on Discord.