Anthropic has launched a private beta for self-hosted Claude Managed Agents, allowing enterprises to run the agent service, database, and execution sandboxes within their own infrastructure. While this grants organizations control over session history, credential handling, and network isolation, it does not move the model itself. Model inference still occurs at Anthropic or a selected provider, meaning data sent during requests remains subject to external retention policies.
This deployment model shifts significant operational responsibility to the customer, requiring them to manage PostgreSQL databases, secure worker containers, and handle ongoing software updates. It is best suited for organizations with strict data residency requirements.
Anthropic opened self-hosted Claude Managed Agents in private beta on November 12, 2026, allowing customers to run the service, database and execution sandboxes in their own cloud account or on-premises environment. Access is available by request through Anthropic account teams, according to the company’s announcement. Pricing and a general-availability timeline were not disclosed.
The key boundary is between running the agent platform and running the model. Customers take over the infrastructure that coordinates agents, stores session history, handles credentials and executes tools. Claude model requests still go to Anthropic or another supported inference provider.
That distinction makes this a meaningful deployment change for enterprises with strict infrastructure and data requirements. It also creates a substantial operations commitment: customers must secure the server, maintain its database, isolate tool execution and install releases themselves.
What Self-Hosting Actually Moves
Claude Managed Agents supplies the machinery around an autonomous agent: an API, an agent loop, execution environments, credential handling and persistent session history. Developers define an agent, start a session and exchange events while it works.
Previously, customers could move execution sandboxes onto their infrastructure while leaving the service with Anthropic. The private beta moves the service as well.
The customer-hosted service includes the API and agent loop, plus storage for agent definitions, sessions and session history. Credentials and execution sandboxes also sit within the customer’s environment.
The server, called , coordinates work and calls the inference provider whenever the agent needs the model. Workers execute the agent’s shell and file tools in sandboxes. The server itself never runs those tools.
The practical gain is control over both the agent’s working environment and its operational record. A company can keep session storage inside its own infrastructure without building an agent orchestration service from scratch.
I’d treat the service column in that table as the deciding factor. If the requirement is simply to run tools against private code or internal systems, self-hosted sandboxes may already cover it. Moving the whole service makes more sense when the agent’s stored state or inference-routing requirements also need to come under customer control.
Model Inference Still Has Its Own Boundary
The November 12 platform release notes identify Anthropic as the default inference provider. Customers can choose another supported destination.
The announcement lists direct Anthropic access, Amazon Bedrock, Google’s agent platform, Microsoft Foundry and a customer-controlled gateway. The documentation describes Google’s option as Claude Models on Google Cloud, Google managed.
A gateway is a routing choice. It does not, by itself, mean Claude’s model weights run on customer hardware. The documentation explicitly places the model at Anthropic or a chosen provider.
That produces three separate questions for a security or procurement review:
Storage: Where are agent definitions, session history and other persistent records kept?
Execution: Where do shell commands and file operations run?
Inference: Where does the server send requests when it needs Claude?
Self-hosted Managed Agents puts the first two under customer operation. It adds provider choice for the third.
The data-residency implication follows from those boundaries: storing history locally does not keep every piece of agent context inside the network. Whatever information the server includes in a model request still goes to the selected inference endpoint. Teams need to assess that request path alongside their database location.
Local History Does Not Set Model Retention
Anthropic says an organization’s existing zero data retention agreement applies to requests sent to Claude in the same way as other Messages API calls. That is separate from storing session history in the customer’s database.
Model-specific conditions still matter. The November 9 release notes, for example, say Claude Fable 5.2 and Claude Mythos 5.2 require 30-day retention and are unavailable under zero data retention unless Anthropic expressly authorizes it.
The useful takeaway is to verify the selected model and provider’s retention terms independently of the hosting decision. “Self-hosted” describes ownership of the agent infrastructure; it is not a blanket retention policy.
The Security Split Depends on Real Sandbox Isolation
Anthropic’s announcement describes a separation between the harness, which coordinates the agent and calls Claude, and the sandbox, where agent-generated code runs.
The agent loop, session history and vault secrets stay outside the sandbox. History is stored as an event log, so the session does not depend on one sandbox surviving its entire run. Sandboxes start when a tool needs them.
That separation is useful, but the implementation detail that deserves the most attention is in the deployment documentation:
“The worker doesn’t isolate that shell.”
The agent’s bash tool is a real shell with the worker process’s permissions and network access. Isolation comes from the container, virtual machine or other environment surrounding the worker.
Anthropic says its Docker Compose stack and cma-sandboxes Helm chart start each session’s worker in a separate container or pod. Customers starting workers themselves are instructed to use disposable containers or virtual machines containing nothing they need to protect.
My view is that this is the most consequential operational detail in the launch. A team can correctly deploy the server and still create an unsafe execution environment by placing a worker on a machine with sensitive files, broad permissions or unrestricted network access. The server-worker split provides an architectural boundary; the customer must supply the isolation around the worker.
Credentials and Network Controls Stay Important
Anthropic describes additional protections:
Credential handling: For MCP tools and supported API calls, a proxy outside the sandbox adds credentials to requests. Self-hosted deployments can also use the customer’s secrets manager.
Network restrictions: Customers hosting sandboxes apply network limits through their own firewall.
Session records: Managed Agents records tool calls and their results, with export over OpenTelemetry for existing monitoring systems.
The credential protection has a defined scope: MCP tools and supported API calls. It should not be read as a guarantee that every possible shell-based workflow automatically keeps secrets outside the sandbox.
These are Anthropic’s documented security mechanisms; the launch materials provide no independent security evaluation.
Infrastructure Control Comes With an Operations Job
Anthropic explicitly assigns customers responsibility for running and securing the server, database and sandboxes, and for installing each release. The documentation also transfers responsibilities such as hosting memory stores and detecting unusual usage from Anthropic to the operator.
Several details deserve attention before a production deployment.
Persistent storage requires PostgreSQL 16 or later. Without a database, the server stores data in memory and loses it on restart. An in-memory configuration may be useful for initial exploration, but it cannot provide durable session history.
For long-running agents, that distinction matters. A session record can contain the context needed to understand what the agent attempted and which tools it used. Database backup, recovery and availability planning therefore become part of operating the agent service.
Trust levels require separate deployments. Anthropic says each trust level needs its own deployment, extending beyond the separate workspaces and environments described for self-hosted sandboxes. Teams planning to share one installation across differently trusted workloads should account for that boundary before settling on an infrastructure design.
Monitoring becomes a customer responsibility. OpenTelemetry export gives teams a route into their existing observability tools. It still takes operational work to decide which behavior should trigger an alert, who investigates it and how a session is stopped or contained.
Updates are customer-installed. Release installation now belongs in the organization’s maintenance process. Teams need an owner for reviewing changes and scheduling upgrades, alongside the people responsible for database health and sandbox configuration.
The tradeoff is clearest when framed as a transfer of responsibility. Customers gain control over infrastructure placement, stored agent data and network policy. They also inherit the work needed to keep those controls effective.
I’d evaluate this as an application platform to operate, not as a deployment toggle. The strongest fit is an organization with a concrete residency or isolation requirement and a team ready to own the supporting service.
Shared APIs Help, but Feature Parity Needs Checking
Anthropic says the hosted and self-hosted services use the same core APIs. The SDK and ant CLI can work with the customer’s server, and most Managed Agents documentation continues to apply.
That continuity should reduce application changes for teams already using the hosted service. Developers still work with agents, sessions and events instead of adopting a separate orchestration model.
However, Anthropic also states that some features exist only on the hosted service and directs customers to its documented differences before choosing self-hosting. API compatibility is not a promise of complete feature parity.
A practical evaluation should therefore start with three checks:
Identify the feature set the application actually depends on.
Confirm the chosen inference destination, model availability and retention conditions.
Assign ownership for persistent storage, worker isolation, monitoring and upgrades.
Those checks distinguish a deployment that satisfies a security requirement from one that merely relocates infrastructure. The beta gives enterprises a broader control boundary, while leaving model access and platform operations as explicit decisions.
Frequently Asked Questions
3 questions
1
Who Can Access the Private Beta?
Organizations can request access through their Anthropic account team. Anthropic has not announced general availability or public pricing.
2
Does Self-Hosting Run Claude Locally?
No. Customers host the agent service and sandboxes. Model inference runs at Anthropic or a selected provider; a customer-controlled gateway can route requests.
3
When Are Self-Hosted Sandboxes Enough?
They may be enough when only tool execution needs to happen on customer infrastructure. Full self-hosting also moves the service, database and session history under customer operation.
