Anthropic Introduces 5 Private MCP Tunnels for Agent Access

The Compliance Bottleneck That Slows Agent Deployments

Imagine you are responsible for deploying AI agents at a financial institution bound by strict data residency requirements. Every tool call those agents make, every piece of data they retrieve, and every computation they initiate must remain within your controlled infrastructure. For months, the standard approach required opening inbound ports or routing traffic through externally managed sandboxes, creating friction with compliance teams. Anthropic has now introduced a set of capabilities designed specifically for this scenario: self-hosted sandboxes and what the company calls anthropic mcp tunnels. These two additions aim to remove the tension between the desire for autonomous agent capabilities and the reality of enterprise security controls.

anthropic mcp tunnels

Daksh Trehan captured the sentiment precisely when he noted that the compliance team is the real bottleneck for production agents, not the model itself. Self-hosted sandboxes and MCP tunnels represent the layer that lets agents actually run inside the customer perimeter instead of behind a sandbox that takes security teams weeks to clear. The announcement reflects a growing recognition that enterprise adoption of AI agents depends less on model capability and more on operational controls.

The Five Private Access Models for Agent Execution

Anthropic has partnered with four sandbox providers and introduced MCP tunnels as a fifth access pathway, creating a total of five distinct models for private agent execution. Each model exposes different infrastructure assumptions and serves different use cases. Understanding the differences helps organizations choose the right approach for their specific compliance and workload requirements.

Cloudflare: MicroVMs with Zero-Trust Networking

Cloudflare brings its microVM architecture and zero-trust networking model to the self-hosted sandbox ecosystem. For organizations already invested in Cloudflare Workers or Cloudflare Zero Trust, this integration feels like a natural extension of an existing security posture. The focus is on controlled outbound traffic, meaning agent tool calls initiate connections outward rather than relying on inbound rules that security teams scrutinize for weeks. Each microVM runs in isolation with minimal attack surface, and the zero-trust model ensures that every request undergoes authentication and authorization regardless of its origin.

For a CISO evaluating whether to use Anthropic managed orchestration versus building a custom execution environment, the Cloudflare model offers a compelling middle ground. You retain control over the networking layer while outsourcing the orchestration complexity to Anthropic. The approach works particularly well for organizations that already enforce strict egress-only network policies and need to maintain that posture when deploying AI agents.

Daytona: Long-Running Stateful Environments

Daytona takes a different approach by offering long-running, stateful environments accessible over SSH or preview URLs. This model suits workloads that require persistent state, ongoing processes, or interactive development sessions. If your agent needs to maintain context across multiple tool calls or run processes that span hours, the Daytona integration provides the continuity that ephemeral sandboxes often lack.

Consider a team building an agent that performs code review across a large repository. The agent might need to check out code, run tests, review results, and then iterate based on feedback. A stateless sandbox would restart the environment for each interaction, losing local state and slowing the process. Daytona stateful environments preserve that state, allowing the agent to work with the same filesystem, database, and running processes across multiple interactions. The SSH access also means developers can inspect the environment directly when debugging agent behavior.

Modal: Scalable CPU and GPU for AI Workloads

Modal emphasizes AI-focused workloads with scalable CPU and GPU allocation. For organizations running resource-intensive tasks like large-scale image generation, video processing, or model fine-tuning within agent workflows, the Modal sandbox model provides the compute elasticity that traditional infrastructure struggles to deliver. Instead of provisioning static GPU instances and hoping they remain utilized, Modal allows agent tool calls to spin up compute resources on demand and release them when the task completes.

This model appeals to platform engineering teams that face pressure to deploy AI agents but need to manage compute costs carefully. The pay-per-use model shifts spending from idle capacity to actual compute consumption. For a VP of platform engineering, this means agent deployments no longer require upfront GPU reservations or complex capacity planning. The agent requests compute when it needs it, and the infrastructure scales accordingly.

Vercel: Sandbox Isolation with Network Boundary Controls

Vercel combines sandbox isolation with VPC peering and credential injection at the network boundary. This model suits organizations that already run frontend applications or API services on Vercel and want to extend those security patterns to agent execution. The VPC peering capability allows agent sandboxes to communicate with internal services without traversing the public internet, while credential injection ensures that secrets remain within the customer environment rather than being passed through Anthropic infrastructure.

For a security architect evaluating whether managed agents can access internal databases without opening inbound ports, the Vercel model demonstrates how credential injection at the network boundary solves a longstanding pain point. The agent never sees the raw credential. Instead, the sandbox environment injects the credential at connection time, keeping the secret within the customer perimeter. The approach aligns with zero-trust principles where no component inherently trusts another component.

MCP Tunnels: Connecting to Private Servers Without Public Exposure

The fifth model, and arguably the most architecturally interesting, is the MCP tunnel. Anthropic MCP tunnels enable Managed Agents and the Messages API to connect to private Model Context Protocol servers without exposing those servers to the public internet. Instead of opening inbound firewall rules, organizations deploy a lightweight gateway that establishes an outbound encrypted connection to Anthropic infrastructure. This inversion of the network trust model means internal databases, REST APIs, ticketing systems, and knowledge bases become accessible to agents while remaining behind the corporate firewall.

The MCP tunnel approach matters because it addresses the fundamental asymmetry of network security. Inbound connections require open ports, exposed endpoints, and the associated attack surface. Outbound connections, when properly controlled, present a smaller risk profile. By tunneling through an outbound encrypted channel, organizations can grant agents access to internal systems without rearchitecting their network perimeter. The feature is managed through organization settings in the Claude Console, giving administrators visibility into which tunnels exist and which agents use them.

How MCP Tunnels Work Under the Hood

The technical architecture of anthropic mcp tunnels deserves closer examination because it represents a meaningful departure from how agent-server connections have typically worked. In the conventional model, an agent running in a managed environment needs to reach an internal server. That requires either exposing the server with an inbound firewall rule or running a relay service that both the agent and the server can reach. Both approaches create operational complexity and security concerns.

MCP tunnels solve this by deploying a lightweight gateway within the customer network. This gateway establishes an outbound encrypted connection to Anthropic infrastructure. The gateway does not accept inbound connections, so no ports need to be opened in the corporate firewall. Once the outbound tunnel is established, the Anthropic managed agent or Messages API can route requests through the tunnel to reach MCP servers running inside the customer network.

The tunnel protocol itself is based on the Model Context Protocol, which defines how agents interact with tools and data sources. By tunneling MCP traffic over an outbound encrypted channel, organizations expose internal databases, APIs, and knowledge bases to agents while maintaining existing security boundaries. The approach effectively inverts the trust model: instead of the agent being allowed to reach the server, the server makes itself available to the agent through a controlled outbound tunnel.

One developer in the community raised an important question about how MCP tunnels integrate with Anthropic connectors that run through Anthropic infrastructure. The answer lies in understanding that the tunnel operates at the network level, while connectors operate at the protocol level. The tunnel provides the secure channel. The connector defines how the agent interprets and uses the data flowing through that channel. Organizations can use tunnels with existing Anthropic connectors or build custom connectors for proprietary systems.

Resource-Intensive Tasks and Custom Compute

A common question from platform engineering teams concerns whether self-hosted sandboxes support resource-intensive tasks like long-running builds on custom GPU clusters. The answer depends on which sandbox model you choose. Modal explicitly targets AI workloads with scalable CPU and GPU allocation, making it suitable for image generation, video processing, and machine learning inference tasks. Daytona stateful environments can run long build processes that span minutes or hours, provided you configure the environment with sufficient resources.

For organizations that already operate their own GPU clusters, the MCP tunnel model offers an interesting alternative. Instead of running agent tool execution within a sandbox, you can expose your existing compute infrastructure as MCP servers. The agent connects to these servers through the tunnel, submits workloads, and retrieves results. This approach keeps your existing compute investment intact while adding agent-driven orchestration on top of it.

The ability to manage compute sizing and runtime images for resource-intensive tasks represents a significant operational advantage. In a managed sandbox environment, you are limited to the compute options the provider offers. With self-hosted sandboxes or MCP tunnels, you configure the exact compute resources your workloads require. If your agent needs 16 GB of GPU memory and 8 CPU cores for a specific task, you provision exactly that. You do not pay for overprovisioned capacity or suffer from underprovisioned performance.

The Orchestration-Execution Separation as an Architectural Trend

The approach Anthropic has taken with self-hosted sandboxes and MCP tunnels reflects a broader architectural trend in the AI industry. The separation of orchestration from execution allows each layer to evolve independently and to be optimized for its specific role. Orchestration focuses on coordination, context management, and decision logic. Execution focuses on computation, data access, and tool operation.

You may also enjoy reading: Microsoft Automatically Rolls Back Faulty Drivers.

This separation has implications beyond security compliance. It enables enterprises to mix and match orchestration providers with execution environments. An organization could use Anthropic for orchestration while running execution on AWS Lambda, Google Cloud Run, or even on-premises servers. The MCP tunnel model makes this flexibility possible by providing a standardized protocol for communication between the orchestration layer and the execution layer.

The trend also addresses a fundamental tension in managed AI platforms. Platform providers want to offer integrated experiences that abstract away infrastructure complexity. Enterprise customers want control over their data, compute, and network security. The separation of orchestration from execution resolves this tension by allowing each stakeholder to control what they care about most. Anthropic manages the agent intelligence and coordination. The customer manages the infrastructure where the agent operates.

Questions Around Integration and Future Direction

The community response to the announcement has included practical questions about how the new capabilities integrate with existing Anthropic infrastructure. One developer asked specifically about how MCP tunnels work with Anthropic connectors that route through Anthropic infrastructure. The answer involves understanding that tunnels and connectors operate at different layers of the stack. Connectors define how agents interact with specific tool types. Tunnels define how network connectivity is established. The two can coexist, with tunnels providing the secure channel and connectors providing the protocol translation.

Organizations already using Anthropic connectors for public-facing integrations can extend those same connectors to private servers through MCP tunnels. The connector configuration remains the same. Only the network path changes. Instead of the agent reaching the server through a public endpoint, the agent reaches the server through the encrypted outbound tunnel.

Looking forward, the question of whether Anthropic will expand the sandbox provider ecosystem is one that enterprise customers will watch closely. The initial four providers cover a range of infrastructure models, but many organizations have existing investments in other platforms. AWS, Google Cloud, and Microsoft Azure are notably absent from the initial list, though the architecture does not preclude future additions. The MCP tunnel model provides an alternative path for organizations that want to use their existing cloud infrastructure without waiting for a formal sandbox integration.

A Practical Decision Framework for Enterprise Teams

For teams evaluating whether and how to adopt these new capabilities, a structured decision framework can help clarify the options. Start by identifying your primary constraint. Is it data residency, network security, compute flexibility, or audit logging requirements? Each constraint points toward different sandbox models or a combination of models.

If data residency is your primary constraint, focus on self-hosted sandbox models that run within your chosen geographic boundary. Cloudflare and Modal offer regional deployment options that can align with regulatory requirements. If you need complete control over data location, consider running your own execution environment and connecting it through MCP tunnels.

If network security is your primary constraint, evaluate the MCP tunnel model first. By avoiding inbound firewall rules entirely, tunnels eliminate the most common source of security review friction. The outbound-only connection model aligns with zero-trust networking principles and simplifies the security approval process. If your security team has been blocking agent deployments due to network exposure concerns, MCP tunnels provide a clear path forward.

If compute flexibility is your primary constraint, consider Modal for GPU-accelerated workloads or Daytona for long-running stateful processes. Both models provide the elasticity and resource control that resource-intensive agent tasks require. If you already manage a compute cluster, the MCP tunnel model allows you to expose that cluster to agents without migrating workloads to a new platform.

If audit logging is your primary constraint, evaluate all five models based on their logging capabilities. Self-hosted sandboxes running on your infrastructure provide logs within your existing logging pipeline. MCP tunnels route traffic through a gateway you control, so you can capture all agent-server interactions at the gateway level. Managed sandboxes provide provider-specific logging that may or may not integrate with your existing logging infrastructure.

The Real Bottleneck Is Operational Control, Not Model Capability

The underlying message of this release is that enterprise adoption of AI agents has shifted from a capability problem to an operational control problem. Models are capable enough. The barrier is whether organizations can deploy those models within their security and compliance boundaries. Self-hosted sandboxes and MCP tunnels address that barrier directly by giving enterprises the controls they need without requiring them to build their own orchestration layer from scratch.

For the security architect evaluating whether managed AI agents can access internal databases without opening inbound ports, MCP tunnels provide a clear technical answer. For the VP of platform engineering facing pressure to deploy AI agents while enforcing strict audit logging and data residency, self-hosted sandboxes provide the operational framework. For the CISO who must decide between using Anthropic managed orchestration and building a custom execution environment, the separation of orchestration from execution means they can choose the best of both worlds.

The compliance team is indeed the real bottleneck for production agents. But with self-hosted sandboxes and MCP tunnels, that bottleneck becomes manageable. Organizations can now deploy agents in regulated environments, keep data within their perimeter, and maintain control over compute and network resources while still benefiting from sophisticated agent orchestration. The release reflects a maturing understanding of what enterprise AI deployments actually require: not just capability, but control.

Add Comment