Anthropic has opened a private beta of self-hosted Claude Managed Agents. In a post from ClaudeDevs, and in an article dated 12 November 2026, the company says you can run the agent harness, sandboxes, credentials and session history in your own cloud or on-premises, and choose where requests to the model are sent. Access is through your Anthropic account team.
Self-hosted Claude Managed Agents is now in private beta. You can host the agent harness, sandboxes, and session history, in your own cloud or on-premises, and choose where requests to Claude are sent.
November 12, 2026
Claude Managed Agents is Anthropic’s hosted agent service: you define an agent, start a session, and exchange events with it while it works, including while it runs commands or edits files in an isolated sandbox. Until now, the default was that Anthropic ran that service. For teams that needed the tools to stay in their own environment, the company already offered self-hosted sandboxes, where you host only the containers and Anthropic still runs the API, the agent loop and the session archive. The new option goes further. You host the service as well.
| Option | Sandboxes | Service | Model |
|---|---|---|---|
| Cloud sandboxes (default) | Anthropic | Anthropic | Anthropic |
| Self-hosted sandboxes | You | Anthropic | Anthropic |
| Self-hosted Managed Agents | You | You | Anthropic, or a provider you choose |
That’s the split in Anthropic’s self-hosted docs. “Until now, that meant building the platform themselves,” the company writes, of teams that wanted the whole service in their own environment.
What you run, and what still leaves
A deployment is a server, its database, and your sandboxes. The server, cma-server, serves the API, runs the agent loop, and stores agents, sessions and session history. It never runs the agent’s shell or file tools. Those run in workers, as an ant beta:worker command or an SDK worker, inside containers or VMs you provide. The database is PostgreSQL 16 or later. Without one, the server keeps that data in memory, and a restart erases it. There’s also a console on your server, where people sign in through your identity provider, and an admin CLI, cma-server-admin, that creates environments and their keys.
The model still runs outside that perimeter. For each call, the server sends the conversation so far, including tool inputs and tool results, to an inference provider. The default is the Claude API. You can point it instead at Amazon Bedrock, Claude Models on Google Cloud, Microsoft Foundry, or a model gateway you run. The official announcement also calls the Google option “Google’s Agent Platform.” Under every value except anthropic, the server needs no Claude API key.
Anthropic’s data and access page says the company has no remote access to the server or its log, and that the server connects to Anthropic only when the Claude API is the provider. It also sets out what those Claude API calls carry, and none of it is optional: headers with the IDs of the session, the agent and the environment; a User-Agent that names the server software and its version; and, on some providers, a metadata.user_id label that defaults to cma-server. An ID holds no name and no content, the docs say, but it does encode the time when your server created it. Anthropic can use the headers and the label to attribute usage.
If your organisation has a zero-data-retention arrangement with Anthropic, the company’s article says it applies to the requests sent to Claude “in the same way as any other Messages API call.” The docs add a distinction the article skips: when Anthropic runs the service, it stores session transcripts, and that’s why the API’s data-retention page lists Managed Agents as not covered by ZDR. When you run the service, you store those transcripts yourself. What the model sees, and what it returns, still falls under your agreement with whichever provider serves the model.
Same API, with a list of exceptions
A self-hosted server has the same core API as the hosted service, so the official SDK and the ant CLI work when you point them at your server’s address. Nothing is copied across from the hosted service, session history included. You create agents, skills, vault credentials and memory stores again on your server. If you already run self-hosted sandboxes, the worker software is the same and can connect to the new server. A worker that starts from a webhook doesn’t, because the self-hosted server sends no webhooks.
The docs also list features that exist only on your server: a choice of inference provider, OpenID Connect single sign-on, storage of new vault secrets in your own secret manager, and short-lived tokens that can identify an agent to an MCP server. A longer list is missing, or behaves differently. The server doesn’t serve the rest of the Claude API, such as Messages or Models. It has no Files API, no mcp_oauth credentials, no prebuilt docx, pdf, pptx or xlsx skills, no scheduled deployments, and no “dreams.” Cloud environments return a 400 error. Differences from the hosted service is the page to read before you move an application across.
For a first look, the release archive includes a Docker Compose stack: the server, PostgreSQL, and workers that give each session its own sandbox container. Anthropic says that stack is for development, not production. It serves plain HTTP, and by default publishes port 8400 only on the host’s loopback address. For production, the docs recommend the release’s two Helm charts. The agent’s bash tool is a real shell with the worker’s permissions and network access; isolation comes from the container or VM you run that worker in, and Anthropic says you should use a disposable environment that holds nothing you need to protect.
Discover more from Sulat AI & Tech News
Subscribe to get the latest posts sent to your email.
