Anthropic Opens Self-Hosted Claude Managed Agents Beta | Zeniteq
Loading
Loading article
Zeniteq is now available on mobile for iPhone, iPad and Apple Watch.Download nowLearn more
Anthropic Opens Self-Hosted Claude Managed Agents Beta
Enterprises can bring Claude’s agent service inside their own infrastructure, but inference still crosses a separate boundary and production deployment becomes their responsibility.
Anthropic has launched a private beta for self-hosted Managed Agents, allowing enterprises to run the agent control plane, session history, and tool sandboxes within their own infrastructure. While customers now own the operational stack—requiring PostgreSQL 16 for data persistence and Kubernetes for production deployments—this does not localize inference. Model calls still transmit data to external providers like Claude or Amazon Bedrock. Organizations must now manage their own security boundaries, as the agent's Bash tool executes with worker-level permissions, shifting the burden of infrastructure isolation and credential management entirely onto the customer.
Anthropic announced self-hosted Claude Managed Agents in private beta on November 12, 2026, giving customers a way to run the agent control plane, sandboxes, credentials, and session history in their own cloud or on-premises environment. Access requires contacting an Anthropic account team. Anthropic’s announcement describes this as a new deployment option for Managed Agents, its APIs for building and running autonomous agents.
The shift is about who operates the service around Claude. Customers can now own the infrastructure that coordinates agent work and stores its history, while choosing where model requests go. They also inherit responsibility for securing that infrastructure, maintaining workers, and installing releases.
Anthropic provides a Docker Compose starting point, but explicitly reserves it for development. Production deployments should use the release’s two Helm charts on Kubernetes. This analysis draws on Anthropic’s published documentation, not independent testing.
What Actually Moves Inside Your Network
Managed Agents separates the service that coordinates an agent from the sandbox where its tools execute. Previously, customers could bring the sandbox onto their infrastructure while Anthropic continued operating the service. The private beta moves both components under customer control.
The self-hosted server, cma-server, exposes the API, runs the agent loop, and stores agents, sessions, and session history. Workers poll it for work and execute shell and file tools inside sandboxes. The server itself never executes those tools.
Persistent storage requires PostgreSQL 16 or later. Without a database, the server stores data in memory and loses it on restart. That makes database configuration a durability requirement, not an optional operational improvement.
Customers can route inference through Anthropic, supported cloud providers including Amazon Bedrock, Google Cloud, and Microsoft Foundry, or their own model gateway.
Local Storage Does Not Mean Local Inference
Every model call sends the conversation so far, including tool inputs and results, to the configured inference provider. The Claude API is the default destination. Self-hosting this service does not put Claude’s model weights on a customer’s servers. Anthropic’s overview documents that outbound boundary.
My view is that this distinction should lead any security assessment: where history is stored and where its contents are processed are separate decisions. An agent can keep its session database inside a company network while sending sensitive tool output to an inference endpoint.
Anthropic says an organization’s existing zero data retention arrangement applies to Claude requests as it does to other Messages API calls. That is conditional on having the arrangement; self-hosting alone does not create it. See the announcement’s data-handling explanation.
Security Controls Come With New Operator Duties
Anthropic describes four security principles across its Managed Agents deployment options:
Separate the harness from the sandbox. The agent loop, history, and vault secrets stay outside the workspace executing agent code.
Keep credentials outside the sandbox where supported. An external proxy adds credentials to MCP and supported API requests. Self-hosted deployments can also use a customer’s secrets manager.
Restrict network access. Hosted environments support allowed-host lists; customer-hosted sandboxes require corresponding controls in the customer’s network.
Record agent activity. Session records include tool calls and their results, with OpenTelemetry export for monitoring systems.
These are Anthropic’s documented design principles, not a guarantee that every deployment is safely configured. The announcement describes the architecture; the operator must enforce its boundaries.
The most consequential warning appears in the self-hosted overview: the agent’s Bash tool is a real shell with the worker process’s permissions and network access. The worker does not provide isolation by itself. Isolation comes from its container, pod, VM, or other execution environment.
The supplied Compose stack and cma-sandboxes Helm chart give each session a separate container or pod. Anyone starting workers manually needs to supply an appropriate disposable boundary. Anthropic also says different trust levels need separate deployments.
I would treat deployment separation as an early design decision. If two workloads should not share a security boundary, placing them in different sessions is insufficient under the documented model.
Authentication also has three distinct layers:
Credential
Holder and purpose
Server API key
Applications and administrative tools use it to authenticate to the customer’s server
Inference credential
The server uses it to call Claude or another configured provider
Environment key
Workers use it to access one environment’s queue and sessions
Applications and workers do not need the inference credential. Keeping these roles separate limits unnecessary distribution of provider access.
Hosted API Compatibility Has Important Exceptions
The self-hosted server uses the same core Managed Agents API, but moving an application requires more than changing its base URL. Anthropic says nothing transfers automatically: agents, skills, vault credentials, memory stores, and session history must be recreated on the new server.
Use a separate client pointed at Claude or the provider
Files API and file session resources
Unavailable
Stage files in the worker directory; send model-facing images or PDFs as base64
Webhooks
No webhook delivery
Follow session events or poll
Scheduled deployments
Unavailable
Start sessions from an external scheduler
MCP OAuth vault credentials
Rejected
Use a static bearer credential and refresh it before expiry
Prebuilt document skills
Not included
Upload their sources as custom skills
Self-hosting adds options too: OpenID Connect single sign-on, external secret storage, configurable inference providers, and short-lived agent identity tokens for MCP calls.
Other capabilities require explicit configuration. Git hosts and MCP hosts need allowlist entries. Web search and web fetch start disabled. Multiagent orchestration supports predefined subagents through a coordinator configuration, with 1 to 20 listed agents; the hosted examples’ dynamic configuration is not interchangeable.
A subtle operational difference deserves attention: model turns can run without a worker polling the environment. The first tool call then waits without an error until a worker becomes available.
That means a successful API response is a weak migration check. I would verify that a session reaches a tool, a worker executes it, and the application receives the resulting events. An integration that previously depended on webhooks needs a separate event-consumption path before that test can succeed.
Exact Requirements for the Private Beta Quickstart
Release archive: request download access through an Anthropic account team.
Claude API key: the documented quickstart uses it for model calls, even though other inference configurations are supported separately.
Current Docker Engine and the Compose plugin: use docker compose, not the older docker-compose executable.
An x86-64 or Arm host with at least two CPUs: on a smaller host, set CMA_SANDBOX_CPUS to its CPU count in .env.
Initial network access: the first build pulls from Docker Hub, Alpine package repositories, and GitHub releases.
Local tools: install openssl and the ant CLI on the Docker host.
The initial downloads matter for restricted environments. The documented quickstart assumes outbound access during setup, so a fully disconnected first boot needs planning beyond those instructions.
Keep the Development Stack Off Sensitive Hosts
The Compose stack contains the server, PostgreSQL, and sandbox workers. It serves plain HTTP and publishes port 8400 on 127.0.0.1 by default.
Anthropic warns that under some Docker Engine releases before 28.3.3, other machines on the host’s local network can reach that port despite the loopback binding. Its instructions also say to use a machine holding nothing that needs protection because agent tools execute in containers on that host. The quickstart is explicit about both limitations.
I would use a disposable development machine or VM with no production credentials. A localhost address is not enough to override a documented exposure caveat.
A Practical First Run
Extract the release and enter its Compose directory. Anthropic notes that an extraction umask stricter than 022 can prevent binaries from being executable by the users inside the server container. If that applies, reset the umask and extract again.
Create .env using the quickstart’s supplied block. It generates the PostgreSQL password, server API key, and stored-credential encryption key. Replace the Claude API key placeholder with your inference key, then restrict the file to owner-only access with chmod 600.
These keys serve different purposes. In particular, the server API key is what your application presents to your deployment; it is not the Claude API key used for inference.
Build the stack and check readiness. The documented commands are:
The first starts the containers; the second follows server logs. Stop following once the server reports that it is listening, then run the readiness request. A healthy response reports ready; degraded can appear briefly during startup.
Configure the CLI in a second terminal. Point ANTHROPIC_BASE_URL at the local server and set that terminal’s ANTHROPIC_API_KEY to the generated server API key. Use the quickstart’s supplied agent file and CLI workflow to create an agent, run a session, and verify sandbox tool execution.
Keep Compose commands in the original terminal. Anthropic warns that starting Compose from the CLI-configured terminal passes those environment overrides into the server, causing it to call itself instead of Claude. The quickstart provides the exact configuration sequence.
For production, move to the two recommended Helm charts and plan server security, database persistence, worker isolation, monitoring, and release upgrades. If the requirement is only to run tools inside an internal network, Anthropic’s environment-selection guide points to self-hosted sandboxes as the smaller operational commitment.
Frequently Asked Questions
3 questions
1
Is Self-Hosted Claude Managed Agents Generally Available?
No. Anthropic announced a private beta, with access requested through an Anthropic account team.
2
Does Self-Hosting Keep Every Piece of Data Inside the Network?
No. Session history is stored locally, but model calls send conversation content and tool results to the configured inference provider.
3
Can the Docker Compose Stack Be Used for Production?
Anthropic explicitly designates it for development. It recommends the release’s two Helm charts for production Kubernetes deployments.
