Claude agents enter the private network, with execution kept inside

AI 요약

• What happened: Anthropic added self-hosted sandboxes and MCP tunnels to Claude Managed Agents.
  • Sandboxes are in public beta; MCP tunnels are a research preview that requires access.
• The architecture: the agent loop stays with Anthropic, while filesystem access, shell execution, runtime images, and network egress can move into customer-controlled infrastructure.
• Why it matters: private repositories and internal APIs become easier to connect, but audit trails and permission boundaries now span Anthropic, the sandbox, the MCP server, and the tunnel layer.
  • Teams should log MCP tool schema versions, approval state, trace IDs, and redacted arguments at the local boundary.

Anthropic attached two infrastructure features to Claude Managed Agents on May 19, 2026. The first is self-hosted sandboxes: the files an agent reads, the commands it runs, and the network it reaches can now live in an environment the enterprise controls, rather than only in Anthropic-managed containers. The second is MCP tunnels: a way for Claude to call Model Context Protocol servers inside a private network without exposing those servers as public endpoints.

At a glance, this looks like a security update. The more important story is that Anthropic is redrawing the responsibility boundary of enterprise agent platforms. Anthropic keeps the agent loop, orchestration, context management, and recovery logic. Tool execution, filesystem access, runtime image control, network egress, and access to internal services can move to the customer environment or to a sandbox provider the customer chooses. For enterprise teams, this creates a middle path: not fully self-hosted agents, but also not a managed service where every operational hand of the agent lives in the model provider's container.

Anthropic's announcement is direct about that split. Claude Managed Agents can now operate in sandboxes controlled by the customer and connect to non-public MCP servers. The services that the sandbox touches can sit inside an existing security perimeter, runtime policy, and network model. Self-hosted sandboxes are available as a public beta on Claude Platform, while MCP tunnels are a research preview.

Managed Agents already separated the brain from the hands

To understand this update, it helps to go back to how Anthropic described Managed Agents in April. In its engineering write-up, the company framed Managed Agents as a hosted service for long-running agents whose harness can evolve as model behavior changes. One example was "context anxiety." Earlier models tended to wrap up work too early as they approached the context limit, so Anthropic built context reset behavior into the harness. With Claude Opus 4.5, Anthropic said that failure mode had faded enough that the old mitigation became unnecessary weight.

The conclusion was clear: if every development team hand-builds and freezes its own agent harness, that harness can go stale as the underlying models change. Managed Agents is Anthropic's answer. Anthropic operates the loop and the recovery layer, while developers send long-running work through more stable interfaces such as sessions, tools, and outcomes.

That model is attractive to application teams, but hard for security teams to approve without qualification. A long-running agent that does real work needs access to repositories, internal documents, private APIs, databases, tickets, and build systems. Those assets usually sit inside private networks. Files and logs may also be constrained by regulation, customer contracts, or internal data-handling rules. A company may be comfortable calling a cloud model, but still unwilling to send the agent's runtime environment outside its perimeter.

Self-hosted sandboxes are Anthropic's attempt to reduce that tension. Claude can still decide what to do through Anthropic's orchestration layer. But command execution, file access, package installation, builds, and network egress can happen inside a sandbox worker controlled by the customer. Anthropic's documentation describes the same tradeoff in operational terms: orchestration remains with Anthropic, while agent code, filesystem, and network egress do not have to leave the customer environment.

A sandbox is not just a container picker

Anthropic connected self-hosted sandboxes with providers including Cloudflare, Daytona, Modal, and Vercel. That list is more than a partner slide. It shows how the agent runtime market is being split into distinct operating surfaces.

Cloudflare emphasizes Sandboxes, Agents SDK, Browser Run, and Dynamic Workers as agent execution infrastructure. Its integration post says Claude Managed Agents can gain sandbox control, private service connectivity, and observability through that stack. Cloudflare also points to a choice between stateful Linux microVMs and a lighter V8 isolate-based backend. If the agent needs to act like a developer, build full applications, and run Linux tooling, a microVM may fit. If the workload is a burst of tens of thousands of concurrent agents, an isolate model may be more attractive.

Daytona leans toward long-running, composable computers. Anthropic's announcement mentions Clay's GTM engineering agent using a Daytona sandbox to mount a file store and install packages on demand. Modal naturally emphasizes on-demand CPU and GPU capacity for AI workloads. Vercel highlights VM security, VPC peering, bring-your-own-cloud patterns, millisecond startup, and credential injection at the network boundary.

That distinction matters for teams building agent products. "Claude runs our code" breaks into several architecture questions. Does each session need a clean filesystem? Should long-running state survive between tasks? Can build cache be reused? Does the agent need internal network access? Will it automate a browser? Does it need a GPU? Should every customer have an isolated runtime image? Self-hosted sandboxes let Anthropic avoid owning every combination directly, while opening the execution plane to customer infrastructure and specialized sandbox providers.

The official docs compare Anthropic-managed cloud environments and self-hosted sandboxes across practical boundaries. In a cloud environment, tools run in Anthropic-managed containers, while network reach, file mounts, and lifecycle are also managed by Anthropic. In a self-hosted sandbox, tools run in customer infrastructure, and network policy, repository mounts, runtime image, cache, and lifecycle become customer-managed concerns. That table is the core of the announcement. The model provider that supplies the agent's intelligence and the perimeter that holds the agent's execution authority are now separable choices.

MCP tunnels delegate a path, not just a tool

The second feature, MCP tunnels, addresses a more sensitive problem. MCP has spread quickly as a standard for connecting models to external tools. In enterprise environments, however, the hard question is not only how to describe a tool. It is where the tool server should live. A ticketing system, billing API, customer database, or internal security scanner can be wrapped as an MCP server, but publishing that server to the internet creates a new security project. VPNs, allowlists, reverse proxies, OAuth, secret rotation, and audit logging all become part of the deployment.

Anthropic's MCP tunnels try to solve that with an outbound-only connection. The customer deploys a small tunnel stack inside the private network. That stack connects outward to an Anthropic-operated tunnel edge. Anthropic's docs say this avoids opening inbound firewall ports, exposing MCP servers to the public internet, or allowlisting Anthropic IP ranges at the origin.

The security layering is worth reading carefully. Anthropic documents outer mTLS, inner TLS, and per-MCP-server OAuth as separate layers. Transport uses the Cloudflare network, but inner TLS terminates at the customer's proxy using a certificate the customer controls. Anthropic says this means Cloudflare cannot read request and response payloads. It can still see connection metadata such as the egress IP of the cloudflared host, host fingerprint, connection timing, byte volume, and assigned tunnel subdomain. That is not "nobody sees anything." It is a distinction between payload visibility and metadata visibility.

MCP tunnels are supported not only by Managed Agents but also by the Messages API. That positioning matters. Anthropic is treating private MCP connectivity as a layer for the Claude API, not merely as a feature inside one agent product. Tunnels are also independent of self-hosted sandboxes. A session running in an Anthropic cloud container can access a private MCP server through a tunnel. A self-hosted session can use a tunneled MCP server or a public MCP server. Used together, the two features let teams keep both execution and tool access closer to their own boundary.

The good news is that security teams get a surface to inspect

For development teams, the benefit is straightforward. When an agent needs to clone internal repositories, install private packages, call internal APIs, run long builds, or work with customer-specific credentials, the question "can all this run in Anthropic's container?" becomes less absolute. Teams can route egress through existing proxies, build sandbox images around internal standards, send runtime logs to their own SIEM, and isolate environments by customer or workload.

AI agents have a wider execution surface than traditional API clients. They do not just send a single request and receive a response. They read repositories, run tests, interpret failures, call other tools, write files, and preserve intermediate work. In such a system, "what did the model decide?" and "what authority executed that decision?" are separate audit questions. A self-hosted sandbox gives more of the second surface back to the customer.

But this is not a complete answer to enterprise agent security. In some ways, it increases the amount of correlation the operator must design. The agent loop sits with Anthropic. Tool execution runs in the customer sandbox. MCP servers sit inside the private network. Tunnel transport may cross Cloudflare infrastructure. After an incident, reconstructing why a refund, access change, code push, or data export happened requires traces across all of those systems.

This concern appeared in developer discussion around the architecture as well. If the agent loop remains with Anthropic, decision context, model revision, prompt template, and retrieval hits may live in Anthropic traces. Credential use and tool execution live locally. Auditing a later business action requires joining the two sides. In practice, local MCP servers should record resolved tool schemas, parent span IDs, approval policies, tool schema versions, and redacted arguments at the boundary.

The dependency shape matters more than the private-network headline

This update also shows Anthropic moving deeper into the enterprise agent stack. Its recent Stainless acquisition strengthened SDK and MCP server generation, the plumbing that connects APIs to tools. Managed Agents gives Anthropic the orchestration layer for long-running work. Self-hosted sandboxes and MCP tunnels extend that layer to the place where orchestration meets private data and runtime authority.

The combination is powerful, but it also raises dependency questions. A fully self-hosted framework such as LangGraph or an internal agent runner can keep the agent loop, trace storage, execution environment, and tool gateway under one operating model. The cost is that the customer must own session recovery, long-horizon orchestration, prompt caching, harness updates as model behavior changes, and event-stream management. Claude Managed Agents turns those responsibilities into a service, but the agent loop and some decision traces remain on Anthropic's side.

So the choice is not simply whether this is "more secure" or "less secure." The better question is which boundary belongs to whom. Do you want model calls and the agent loop managed by Anthropic? Should filesystem and shell execution only happen in your runner? Should MCP servers be reachable only through outbound tunnels rather than public endpoints? Are Cloudflare, Daytona, Modal, or Vercel acceptable parts of the operational boundary? If your organization uses Claude Platform on AWS, how do you treat the current limitation that self-hosted sandboxes are not yet supported there?

For enterprise AI teams, these questions become architecture review items. If an agent can call internal APIs, the gateway should distinguish agent identity from human accounts. If an agent can access a repository, branch protection, commit signing, and secret scanning need to be part of the same design. If an agent can read internal databases, row-level policy and query audit should survive at the MCP tool level. If an agent runs long tasks, session timeout and human approval checkpoints need to be explicit.

What developers should check now

First, separate work that really needs a self-hosted sandbox from work that is fine in a cloud environment. Analysis jobs that touch only public packages and temporary files may be simpler in Anthropic-managed containers. Work involving internal repositories, private package registries, internal services, regulated data, or customer-specific credentials is where a self-hosted sandbox deserves review.

Second, do not treat MCP tunnels as merely a convenient way to open internal APIs. Tunnel tokens, TLS private keys, and MCP server OAuth settings are all high-value secrets. Anthropic's docs warn that if the tunnel token and TLS private key leak together, proxy impersonation and payload exposure become real risks. Adopting tunnels should include certificate management, rotation, proxy access logs, and security ownership across networking and platform teams.

Third, make trace correlation a product requirement. Seeing that an agent called a tool is not enough. Local systems should identify the agent session, model configuration, tool schema version, user request, policy decision, and approval state behind that call. An MCP server should not merely say "request handled." It should record what was allowed, under which agent authority, and with which redactions.

Fourth, choose a sandbox provider for the workload, not just for cost or startup time. MicroVM isolation, V8 isolates, long-running state, SSH access, preview URLs, VPC peering, secret injection, egress proxies, log export, and region control all differ. A coding assistant, an internal operations agent, a financial analysis agent, and a browser-driving QA agent do not need the same runtime.

Agent platform competition is moving outside the model

The significance of this release is not just that Claude can call more tools. In 2026, agent competition is increasingly shaped by long-running sessions, sandboxing, credentials, private networks, observability, audit, recovery, and cost control. Anthropic has the agent loop through Managed Agents, SDK and MCP plumbing through Stainless, and now a clearer execution and private-tool boundary through self-hosted sandboxes and MCP tunnels.

Still, teams should not read "runs inside the enterprise boundary" too literally. This design is a division of labor. The brain remains with Anthropic. The hands can move into customer infrastructure. Private tools can be connected through outbound tunnels. That division is practical, but audit and responsibility are divided too. You need to know why Claude made a decision, what the sandbox executed, which authority an MCP server used to respond, and what metadata the transport provider saw.

The first thing to draw is not the demo flow. It is the security boundary map. Which data reaches Anthropic? Which files stay in the sandbox? Which credentials live in the tunnel proxy and MCP server? Which logs land in which system? If that map is clear, these Claude Managed Agents features can make enterprise agent deployment more realistic. If it is not clear, private-network access may add complexity faster than it adds control.

Sources: Anthropic announcement, self-hosted sandboxes documentation, MCP tunnels documentation, Cloudflare integration announcement, Managed Agents engineering post.