Anthropic Lets You Self-Host Claude Managed Agents, in Private Beta

On 12 November 2026 Anthropic opened a private beta of self-hosted Claude Managed Agents, which moves the whole agent service, not just the sandboxes, onto infrastructure you run. The API server, the agent loop, the store of agents and sessions, and the workers that execute shell and file tools all sit inside your network; what leaves is the model call itself. Access is by request through an Anthropic account team, and no price for the self-hosted version has been published. For platform teams that were told "no agent SaaS touches our data", this is the first time a frontier lab has offered its managed agent runtime as software you install.

What happened

The announcement appeared on the Claude blog and in the platform release notes, both dated 12 November, with setup documentation published the same day. The article's headline promise is to "operate Claude Managed Agents inside your security perimeter".

This builds on two earlier steps. Claude Managed Agents launched in beta on 8 April 2026 as a hosted service, and self-hosted sandboxes followed on 19 May, letting tool execution run in your cloud while Anthropic hosted the rest. Both dates are from the release notes page, where I could only read those older entries in summary form. The new beta closes the gap. In the docs' own words, self-hosted sandboxes moved tool execution to you, and the new offering means "you host the service too."

What runs where

Packaging is what you would expect from something meant to land in a regulated estate: a cma-sandboxes Helm chart and a Docker Compose stack that start one worker per session in its own pod or container, a cma-server-admin CLI for Linux (x86-64 and Arm) and Apple silicon macOS, and release archives you install yourself, each with an operator-guide.md. The server ships under a separate "Software License Agreement: Claude Managed Agents Server", so this is licensed software, not open source.

The docs split credentials three ways: a server API key for your applications, an inference credential that only the server holds, and an environment key that only workers hold. That is a sensible blast-radius split. A compromised worker should not be able to call the model on your bill, and a compromised client should not be able to register workers.

What does not change

Your data still goes to a model provider on every turn. The server sends the full conversation, tool inputs and outputs included, to whichever inference endpoint you configure, and a Claude API call also carries the session, agent and environment IDs. The blog post says zero data retention, where you have it, "applies to the requests sent to Claude". So the honest summary is: state at rest moves to you, prompts in flight do not, unless you route inference through Bedrock, Google Cloud or Foundry under a contract you already have.

The other thing that does not change is isolation. The docs are blunt that the agent's bash tool is "a real shell" and that the worker itself does not sandbox it. Isolation is whatever your container, pod or VM gives you. If your workers run as ordinary pods on a shared node pool, an agent shell is one kernel bug away from its neighbours. I write about that trade-off a lot, and gVisor vs microVM vs Containers for AI Agent Isolation covers the options. Disclosure: I build PandaStack, a Firecracker microVM platform for running agent code, so I have a view here.

Why it matters

My take: this is less about features and more about procurement. Most enterprises I talk to can accept a model API call under a data processing agreement. What they struggle to accept is a third party storing months of agent session history, which is effectively a log of every file, ticket and query the agent touched. Self-hosting the session store removes that objection, and it puts audit, retention and deletion under the same controls as the rest of your data.

It also changes who is on call. A hosted agent service is Anthropic's pager; a self-hosted one is yours. You now own Postgres backups for session history, upgrades you install by hand, worker capacity, and an identity provider integration for the console. None of that is hard, but it is real work, and the beta has no published SLA or price to weigh it against.

What sceptics say

The strongest objection is that the most sensitive data still leaves. Every tool result an agent reads, from a customer record to a stack trace with secrets in it, is in the next model request. Self-hosting the loop does not change that, and teams that need prompts to stay on-premises will still need an open-weight model behind a gateway, which the docs allow but Anthropic does not position as the main path.

The second is lock-in in a new place. The server is proprietary and licensed, sessions live in Anthropic's schema in your Postgres, and the agent definitions are Managed Agents objects. Compare that with the Claude Agent SDK, where the loop is a library in your own code. And it is a private beta: no public sign-up, no price, and a product that changes per release.

What to do this week

• Decide whether you need it. If your blocker was session history at rest in a vendor cloud, request access. If your blocker was prompts leaving the network, this does not solve it on its own.
• Plan isolation before the Helm install. Put agent worker pods on a dedicated node pool with a stronger runtime class (gVisor or a microVM runtime), tight NetworkPolicies and no cloud metadata access. The Kubernetes NetworkPolicies guide has a default-deny starting point.
• Treat the session database as sensitive. It is a transcript of everything the agent saw. Encrypt it, back it up with point-in-time recovery, and set a retention policy on day one.
• Keep the three credentials separate in your secrets manager, with the inference credential readable only by the server's service account.
• Watch the agent incident record. Agent runtimes and the inference engines behind them have had a busy month, including this week's NEAR AI breach through SGLang. The AI agent security incident log is where I record each one.

FAQ

What is self-hosted Claude Managed Agents?

It is a private beta, announced on 12 November 2026, in which you run the Managed Agents server, its PostgreSQL database, the web console and the tool-executing workers on your own cloud or on-premises infrastructure. Model inference still goes to the Claude API or another configured provider such as Amazon Bedrock.

How much does self-hosted Claude Managed Agents cost?

Anthropic has not published a price for the self-hosted version. The hosted version is priced at token rates plus $0.08 for each hour a session runs, with no platform or seat fees, according to the product page.

Can it run on Kubernetes?

Yes. The documentation describes a cma-sandboxes Helm chart that starts each session's worker in its own pod, and a Docker Compose stack for smaller setups. The worker does not isolate the agent's shell itself, so the pod's runtime and network policy are your isolation boundary.

Related: AI Agent Security Incident Log, gVisor vs microVM vs Containers for AI Agent Isolation and OpenAI DevDay 2026: Agents API Gets Computer Use, Codex Moves to the Cloud.