Claude Managed Agents Deep Dive: How Self-Hosted Sandboxes and MCP Tunnels Redefine Enterprise AI Security

Core Question: How can you unlock the full potential of AI agents to access sensitive data and internal systems without sacrificing security and control?

The newly released self-hosted sandboxes and MCP tunnels for Claude Managed Agents allow AI agents to execute tools and access services directly within your enterprise infrastructure. Meanwhile, Anthropic’s cloud remains responsible for agent orchestration and context management. This hybrid architecture resolves the fundamental contradiction in enterprise AI adoption: the need for advanced AI capabilities alongside the strict requirement that data never leaves the corporate perimeter.

Why AI Agents Need a “Remote Work” Setup Instead of a “Business Trip”

Core Question: What are the hidden security and control risks in traditional AI agent architectures?

Traditional AI agents operate like employees on a “business trip”: your data and tasks must be sent to the AI provider’s infrastructure for processing, or the AI agent must “enter” your systems to execute operations. Both approaches carry significant risks—the former potentially exposes sensitive data, while the latter introduces unknown access privilege risks.

Self-hosted sandboxes flip this model to a “remote work” setup: Anthropic’s cloud still acts as the brain (handling orchestration, context management, and error recovery), but the hands (tool execution) stay securely within your own infrastructure. This separation allows enterprises to:

• Keep files and code repositories strictly within the enterprise boundary
• Apply existing network policies, audit logs, and security tooling
• Precisely control compute resource allocation to meet diverse task requirements
• Customize the runtime environment according to specific security compliance needs

Author’s Reflection: This architectural shift reminds me of the evolution of outsourcing models. We moved from “fully outsourced” (data + processing leave the building) to “on-site” (people are in your office but follow external workflows), and now to “remote but controlled” (the brain is external, but the tools and environment are entirely yours). Claude’s new features represent the AI version of this final stage, maintaining professional capability while ensuring absolute control.

Choosing Your Sandbox Client: 4 Providers for Different AI Workloads

Core Question: What are the unique characteristics of each sandbox provider, and which use cases do they fit best?

Claude Managed Agents supports multiple sandbox environments, each with distinct architectural advantages and ideal use cases. Choosing the right sandbox is like selecting the right office space for different job functions—some require lightning-fast startup, others need long-running persistence, and some demand massive computational power.

Sandbox Provider Comparison

Provider	Core Characteristics	Startup Speed	Best Fit For	Real-World Example
Cloudflare	MicroVMs + lightweight isolates, zero-trust secrets injection	Milliseconds	Fine-grained network control, high concurrency	Amplitude’s Design Agent
Daytona	Full composable computers, long-running and stateful	Seconds	Long-duration tasks, state preservation	Clay’s Sculptor GTM engineering agent
Modal	Built specifically for AI workloads, on-demand GPU	Fast	Heavy compute tasks, image generation	High-performance AI processing
Vercel	VM security + VPC peering, BYOC support	Milliseconds	Cloud service integration, strict credential handling	Rogo’s financial analyst agent

Cloudflare Sandboxes: The Pinnacle of Network Control

Cloudflare runs sandboxes at scale using microVMs and lighter-weight isolates, offering three critical network control capabilities:

• Zero-trust secrets injection: Credentials are injected at the network boundary and never enter the sandbox environment itself.
• Customizable proxies: Audit, reroute, or modify all egress traffic leaving the sandbox.
• Internal service connections: Securely connect to internal services over Cloudflare’s own network backbone.

Application Scenario: Amplitude is building Design Agent, an internal tool for generating on-brand mockups and providing design critiques. Using Cloudflare sandboxes ensures that their design assets never leave the company network while allowing precise control over which design systems and brand resources the agent can access.

图片来源：Unsplash

Daytona Sandboxes: The Ideal Choice for Long-Running Tasks

Daytona sandboxes function as full composable computers that support long-running, stateful operations. Their unique advantage lies in their persistence:

• The same primitive runs a quick burst of activity or an agent that works continuously for hours.
• The sandbox remains accessible via SSH or an authenticated preview URL while a session runs.
• You can pause the sandbox and restore it later with the full state perfectly preserved.

Application Scenario: Clay’s GTM engineering agent, Sculptor, builds, tests, and monitors workflows autonomously. These tasks can span several hours, requiring state persistence and the ability to recover gracefully from interruptions. Daytona’s long-running capabilities perfectly satisfy these demands.

Modal Sandboxes: The Specialist for AI Workloads

Modal is a cloud platform built explicitly for AI workloads. Its sandboxes share the same foundation as Modal’s functions, storage, and networking primitives:

• A custom container runtime delivers fast startup times on any container image.
• The infrastructure scales seamlessly to hundreds of thousands of concurrent sandboxes.
• CPU and GPU resources are allocated on demand.

Application Scenario: When a Claude agent needs to execute compute-heavy tasks like image generation or building large-scale code repositories, Modal can provision GPU resources instantly. Once the task completes, those resources are immediately released, preventing unnecessary cloud spend.

Vercel Sandboxes: The Bridge to Cloud Services

Vercel sandboxes combine VM-level security with VPC peering and “bring your own cloud” (BYOC) architectures:

• Millisecond startup times.
• Managed Agents handles the model, tools, and session state, while the Vercel Sandbox firewall injects credentials at the network boundary.
• Credentials never actually enter the sandbox execution environment.

Application Scenario: Rogo, an AI platform for institutional finance, is building an analyst agent on Managed Agents and the Vercel Sandbox. The highly sensitive nature of financial data demands strict security controls. Vercel sandboxes ensure database credentials never enter the agent environment, while VPC peering allows secure access to proprietary financial data sources.

MCP Tunnels: Safely Piercing the Firewall for AI Agents

Core Question: How can AI agents access internal services without exposing them to the public internet?

MCP (Model Context Protocol) tunnels solve the critical challenge of connecting AI agents to enterprise internal services. Traditional methods require either opening public endpoints (a massive security risk) or configuring complex VPN setups (an operational burden). MCP tunnels offer a much more elegant solution.

How MCP Tunnels Work

MCP tunnels establish secure access to internal services through a lightweight gateway:

1. The gateway is deployed inside your enterprise network.
2. It establishes a single outbound connection to Claude’s services.
3. No inbound firewall rules are required.
4. No public endpoints are exposed.
5. All traffic is encrypted end-to-end.

This design functions like a “one-way door”—the AI agent can reach into your network to access specific services, but the outside world cannot use this channel to enter your network.

Supported Internal Service Types

With MCP tunnels, the following internal systems become direct tools your agents can call:

• Internal Databases: Query enterprise data warehouses or operational databases directly.
• Private APIs: Access internal API endpoints that are not exposed to the public internet.
• Knowledge Bases: Connect securely to internal document management and wiki systems.
• Ticketing Systems: Integrate with internal trackers like Jira or ServiceNow.

Application Scenario: An enterprise can allow a Claude agent to access their internal Jira instance via an MCP tunnel to analyze project velocity, identify bottlenecks, and generate status reports. This happens without ever exposing the Jira instance to the public internet or forcing developers to manage complex VPN configurations.

Author’s Reflection: MCP tunnels represent a paradigm shift in enterprise integration. Instead of building brittle, exposed webhooks to accommodate external AI tools, enterprises simply open a secure, outbound-only pipe. It respects the fundamental security principle of minimizing the attack surface while still enabling deep system integration.

Implementation Path: From Zero to Production

Core Question: How do you deploy and configure self-hosted sandboxes and MCP tunnels in a real-world environment?

Implementing the new Claude Managed Agents features requires understanding a few key components and configuration steps. Below is the complete implementation path.

Prerequisites and Access

Self-hosted sandboxes are currently in Public Beta, while MCP tunnels are in Research Preview.

• Self-hosted sandboxes: Directly available on the Claude Platform.
• MCP tunnels: Requires requesting access via the Claude Managed Agents form.

Basic Architecture Understanding

Before configuring anything, it is vital to understand the fundamental split in the Claude Managed Agents architecture:

┌─────────────────────────────────────────────────────────────┐
│                    Anthropic Cloud Infrastructure           │
│  ┌─────────────────────────────────────────────────────┐    │
│  │              Agent Loop (The Brain)                  │    │
│  │  - Orchestration                                     │    │
│  │  - Context Management                                │    │
│  │  - Error Recovery                                    │    │
│  └─────────────────────────────────────────────────────┘    │
└──────────────────────────┬──────────────────────────────────┘
                           │ Control Channel
                           ▼
┌─────────────────────────────────────────────────────────────┐
│                   Your Enterprise Infrastructure             │
│  ┌─────────────────────────────────────────────────────┐    │
│  │         Self-Hosted Sandbox (The Hands)              │    │
│  │  - Tool Execution                                    │    │
│  │  - File Access                                       │    │
│  │  - Package Management                                │    │
│  └─────────────────────────────────────────────────────┘    │
│                                                             │
│  ┌─────────────────────────────────────────────────────┐    │
│  │         MCP Tunnel Gateway (The Bridge)              │    │
│  │  - Internal Database Connections                      │    │
│  │  - Private API Access                                │    │
│  │  - Knowledge Base Integration                         │    │
│  └─────────────────────────────────────────────────────┘    │
└─────────────────────────────────────────────────────────────┘

Self-Hosted Sandbox Configuration Steps

Using Cloudflare as an example, the configuration workflow looks like this:

1. Prepare your provider account: Register or log in to your Cloudflare account and ensure you have permissions to create and manage sandboxes.
2. Configure in Claude Console: Navigate to the Managed Agents section in the Claude Console, select “Self-hosted sandboxes,” and choose Cloudflare as your provider.
3. Set network policies: Define outbound network rules, configure zero-trust secrets injection, and set up custom proxies if traffic auditing is required.
4. Define the runtime environment: Specify the base container image, configure resource limits (CPU and memory), and install necessary dependencies.
5. Test and validate: Run a simple agent task to test the sandbox connection, verify that network policies block unauthorized traffic, and confirm that audit logs are recording activity correctly.

MCP Tunnel Configuration Steps

1. Deploy the MCP tunnel gateway: Install the lightweight gateway within your internal corporate network.
2. Register the tunnel in Claude Console: Navigate to workspace settings, add a new MCP tunnel configuration, and input the gateway identifier and authentication details.
3. Configure accessible services: Define exactly which internal services the agent is allowed to interact with. Set service-specific access controls.
4. Test the tunnel connection: Verify the outbound connection between the gateway and Claude’s services. Test agent access to the internal services and monitor tunnel latency and stability.

Real-World Application Scenarios and Case Analysis

Core Question: How do self-hosted sandboxes and MCP tunnels translate into tangible business value?

Understanding the technical features is only half the battle; applying them to real business scenarios is where the true value lies. Based on the documented cases and logical derivations, here is a detailed analysis of practical applications.

Scenario 1: Brand-Consistent Design and Content Generation

Business Problem: A marketing team needs AI assistance to generate on-brand designs and content. However, brand assets and design systems are highly sensitive and cannot leave the corporate network.

Solution: Build a Design Agent using Cloudflare Sandboxes.

Implementation Details:

• Deploy design tools and brand assets inside a Cloudflare sandbox.
• Configure zero-trust secrets injection so API keys for design software never touch the sandbox environment.
• Set up a customizable proxy to monitor all access to brand resource libraries.
• The Claude agent loop handles the creative requests, but all rendering and asset manipulation happen inside the sandbox.

Value Realized:

• Brand assets never leave the enterprise network.
• All design activities generate a complete, immutable audit log.
• Administrators can strictly control which versions of the design system the agent is allowed to reference.

Author’s Reflection: This scenario perfectly illustrates the balance of “control without constraint.” The AI agent retains its full creative capabilities, but the act of creation happens within a tightly governed environment. It is akin to giving a designer a dedicated, offline workstation inside the office rather than letting them take all proprietary files home.

Scenario 2: Complex Workflow Automation

Business Problem: A Go-To-Market (GTM) team needs to automate complex marketing workflows involving building, testing, and monitoring. These tasks can last for hours and require persistent state.

Solution: Build a GTM engineering agent using Daytona Sandboxes.

Implementation Details:

• Deploy a complete workflow environment inside a Daytona sandbox.
• Leverage Daytona’s long-running capabilities to handle tasks that span several hours.
• Configure state preservation so tasks can be paused if the system needs maintenance and resumed seamlessly.
• Allow the engineering team to monitor progress via SSH or an authenticated preview URL.

Value Realized:

• Eliminates API timeout errors associated with long-running tasks.
• Workflows can recover seamlessly from interruptions without losing progress.
• The team gains real-time visibility into automated workflow execution.

Scenario 3: Sensitive Data Analysis and Reporting

Business Problem: A financial institution needs an AI agent to analyze proprietary data and generate reports, but regulatory requirements dictate that this data must never leave the corporate boundary.

Solution: Build an analyst agent using Vercel Sandboxes combined with MCP Tunnels.

Implementation Details:

• Deploy an MCP tunnel gateway to connect securely to internal financial data sources.
• Configure the analysis environment inside a Vercel sandbox.
• Use VPC peering to securely access cloud-hosted data silos.
• Inject database credentials strictly at the network boundary so they never enter the sandbox execution layer.

Value Realized:

• Proprietary financial data remains entirely within the enterprise perimeter.
• Database credentials are shielded from the AI agent environment, mitigating credential leakage risks.
• Every data query generates an audit trail required for regulatory compliance.

Technical Limitations and Considerations

Core Question: What technical limitations must be accounted for when implementing self-hosted sandboxes and MCP tunnels?

While self-hosted sandboxes and MCP tunnels offer powerful capabilities, several technical limitations and considerations require attention in production environments.

Current Status and Availability

Feature	Current Status	Access Method	Stability Expectation
Self-hosted sandboxes	Public Beta	Directly available on Claude Platform	Production-ready, but minor functional adjustments may occur
MCP tunnels	Research Preview	Requires access request	Experimental; not recommended for mission-critical production environments yet

Architectural Limitations

1. The agent loop remains in the cloud: Orchestration, context management, and error recovery still happen on Anthropic’s infrastructure. This means some metadata (though not content data) will interact with the cloud. Environments with extreme isolation requirements need to account for this.
2. Network dependency: Both sandboxes and tunnels require a stable outbound network connection. Network interruptions will directly impact agent execution. You must consider network redundancy and failover mechanisms.
3. Resource planning complexity: Self-hosting means you are responsible for forecasting and provisioning compute resources. Different tasks will have wildly different resource footprints, requiring thoughtful resource pooling and allocation strategies.

Security Considerations

1. Credential management: Even when utilizing zero-trust injection, you must rigorously manage credential lifecycles. Implement credential rotation strategies and monitor usage patterns to detect anomalies.
2. Audit log integration: Ensure that sandbox activity logs are properly federated into your enterprise SIEM (Security Information and Event Management) system. Define clear log retention policies and set up alert rules based on log data.
3. Principle of least privilege: Precisely configure the minimum permissions the agent requires to complete its task. Regularly audit these permission sets and consider revoking access immediately after task completion.

Author’s Reflection: Technical limitations are often glossed over in product announcements, but they become the primary roadblocks during actual deployment. Understanding these constraints early—especially the fact that MCP tunnels are still in Research Preview—allows teams to build appropriate fallback plans rather than being caught off guard in a production crisis.

Practical Summary and Action Checklist

Quick Implementation Checklist

Setting Up Self-Hosted Sandboxes:

• [ ] Evaluate the characteristics of different sandbox providers and select the best fit for your workload.
• [ ] Prepare the necessary accounts and permissions for your chosen provider.
• [ ] Configure the self-hosted sandbox in the Claude Console.
• [ ] Define the runtime environment, including base images and resource limits.
• [ ] Configure network policies, egress rules, and access controls.
• [ ] Deploy a test agent to validate functionality and connectivity.
• [ ] Set up monitoring and integrate logs with your existing SIEM tools.
• [ ] Draft a failover plan for sandbox or network outages.

Setting Up MCP Tunnels:

• [ ] Request access to the MCP tunnels Research Preview.
• [ ] Map out internal service access requirements and dependencies.
• [ ] Deploy the MCP tunnel gateway inside your internal network.
• [ ] Register the tunnel in the Claude Console workspace settings.
• [ ] Configure the explicit list of internal services the agent is allowed to reach.
• [ ] Test tunnel connectivity, latency, and DNS resolution.
• [ ] Set up access auditing and real-time monitoring for the gateway.
• [ ] Define a fallback strategy for when the tunnel connection drops.

One-Page Summary

Core Value: Enables Claude agents to execute tools and access services within your enterprise infrastructure, resolving the contradiction between data security and AI utility.

Key Components:

1. Self-Hosted Sandboxes: Executes agent tools in an environment fully controlled by your enterprise.
2. MCP Tunnels: Securely connects agents to internal services without exposing them to the public internet.

Primary Benefits:

• Data never leaves the enterprise boundary.
• Existing security policies and tooling apply natively.
• Compute resources are precisely controlled and sized for the task.
• Internal systems are accessible without opening public endpoints or managing complex VPNs.

Ideal Use Cases:

• AI applications processing highly sensitive data.
• Tasks requiring long-running, stateful execution.
• Industries subject to strict regulatory compliance (e.g., finance, healthcare).
• Environments requiring granular, proxy-level network control.

Implementation Path:

1. Select a sandbox provider aligned with your compute and network needs.
2. Configure the self-hosted sandbox environment and runtime.
3. Set up an MCP tunnel if internal service access is required.
4. Deploy a low-stakes test agent to validate the integration.
5. Gradually roll out to production workloads.

Frequently Asked Questions

Q1: Do self-hosted sandboxes introduce significant latency?
A: Latency depends on network connection quality, the sandbox provider’s architecture, and the task type. Providers like Cloudflare and Vercel offer millisecond startup times, minimizing impact for most tasks. However, workloads requiring massive data transfer may require network path optimization.

Q2: Do MCP tunnels support all types of internal enterprise services?
A: MCP tunnels are designed primarily to connect MCP-compatible services, including databases, APIs, and knowledge bases. Non-standard protocols may require an additional adaptation layer. Currently, the primary supported service types are internal databases, private APIs, knowledge bases, and ticketing systems.

Q3: How do I prevent a self-hosted sandbox agent from accessing unauthorized resources?
A: This is achieved through a multi-layered approach: network-level egress rules restrict external resources the sandbox can reach; internal sandbox permissions limit file and process access; and Claude agent-level tool permissions restrict the specific functions the agent can invoke. These three layers work together to enforce strict access control.

Q4: Do self-hosted sandboxes support GPU acceleration?
A: Yes, but this depends entirely on the chosen sandbox provider. For example, Modal sandboxes are built specifically for AI workloads and offer on-demand GPU allocation. Other providers, like Cloudflare and Vercel, primarily optimize for CPU workloads and may not be suitable for GPU-intensive tasks like image generation.

Q5: Do MCP tunnels support bidirectional communication, such as internal systems proactively notifying the agent?
A: Currently, MCP tunnels are designed for an agent-initiated request-response model. They do not support internal systems proactively pushing notifications to the agent. If you require event-driven architectures, you would need to combine MCP tunnels with an internal message queue system.

Q6: How can I monitor resource usage within a self-hosted sandbox?
A: Resource monitoring happens on two levels: the native monitoring dashboards provided by the sandbox vendor (e.g., Cloudflare analytics or Modal logs) and integration with your existing enterprise monitoring stack by forwarding sandbox logs to your SIEM or observability platform. Combining both provides the most comprehensive visibility.

Q7: Are self-hosted sandboxes suitable for multi-tenant isolation?
A: Yes, though the implementation varies by provider. Cloudflare uses microVMs and isolated containers for strong isolation. Daytona provides isolation through full composable computers, and Modal uses its custom container runtime. When evaluating a provider for multi-tenant use, you should assess the strength of their specific isolation primitives.

Q8: Where is the performance bottleneck in an MCP tunnel?
A: The primary bottlenecks are typically network latency and encryption overhead. Because all traffic is encrypted end-to-end, the encryption and decryption processes introduce minor latency. For high-frequency, small-payload interactions, this is negligible, but for large data transfers, you may need to consider optimizations like data compression or batch processing.