Self-hosted Claude Managed Agents: what you run, what still leaves your network and what the licence asks

On 12 November 2026 Anthropic announced a private beta that lets companies self-host Claude Managed Agents. Access is through your Anthropic account team. Managed Agents is Anthropic's set of APIs for building and deploying autonomous agents. It supplies the software that runs each agent, the sandboxes agents work in, credential handling and session history.

The service first launched as a hosted service on the Claude Platform, with Anthropic running the infrastructure. Anthropic then added self-hosted sandboxes for teams whose code had to stay in their own environment. With this beta, the whole service can run in your own cloud or on your own premises. Developers build with the same core APIs as on the hosted service.

Anthropic's documentation sets out three options. Cloud sandboxes, the default, leave the sandboxes, the service and the model with Anthropic. Under self-hosted sandboxes, you host the sandboxes and Anthropic hosts the rest. Self-hosted Managed Agents puts the sandboxes and the service with you, and the model comes from Anthropic or a provider you choose.

You run a server called cma-server, a PostgreSQL 16 or later database and workers, the machines where agents run shell and file tools. A console on your server lets people sign in through your identity provider, and an admin command-line tool comes with it. Without a database, the server keeps data in memory and a restart erases it.

Model requests can go to Anthropic directly, to Amazon Bedrock, to Claude Models on Google Cloud, to Microsoft Foundry or to your own model gateway. Anthropic names fixing broken builds, testing releases, triaging alerts and working through a bug backlog as examples of the work these agents do.

Anthropic's documentation says to self-host the whole service if you must store agents, sessions and session history yourself. It also fits teams whose model calls must go to a cloud provider or their own gateway. If the only need is for tools to run on your own machines, Anthropic points to self-hosted sandboxes instead.

For a regulated firm, the model route can matter as much as where the server runs. A firm that already uses Claude through Amazon Bedrock or Microsoft Foundry can send agent model calls the same way. The agent records then sit in a database the firm runs, backs up and audits itself.

Anthropic's docs say you run and secure the server, its database and your sandboxes, and you install each release yourself. A named team has to own that work. The licence's update deadlines, covered below, set how fast it must move.

Session history is stored in your own database. Each model call still sends the conversation so far, including tool inputs and tool results, to your inference provider. The default provider is the Claude API.

The documentation says the server connects to Anthropic only when the Claude API is the provider. Anthropic has no remote access to the server or its log. With the Claude API, each model call carries up to three headers with IDs your server generated, for the session, the agent and the environment.

An ID holds no name and no content, but it encodes when it was created. Anthropic can use the IDs to attribute usage, and no setting turns them off. They are never sent to any other provider.

Requests to the Claude API also carry a User-Agent naming the server software and its version. Calls to the Claude API, Microsoft Foundry and Claude-API-compatible gateways carry a fixed label, cma-server, which is the same on every server. The label is not sent to Amazon Bedrock or Claude Models on Google Cloud.

Sessions and history stay in your database until you delete them, and the server does not delete anything by age. A delete does not reach backups, exported logs and traces, or memory stores.

Anthropic's data retention page lists Claude Managed Agents as not covered by zero data retention (ZDR). That is because the hosted service stores session transcripts until you delete them. When you run the service, you store them yourself. If you have ZDR with Anthropic, model calls to the Claude API fall under it like any other Messages API call.

For a regulated firm, zero data retention is probably the main reason to take on the work. The hosted service keeps transcripts and so sits outside ZDR. Self-hosted, the transcripts sit in your own database, and model calls to the Claude API can fall under a ZDR arrangement you already hold.

The conversation still leaves your network on every call, tool results included, so the model provider sees what the agent sees. A data protection officer is likely to want each provider, and the route to it, on the record of processing.

The server keeps everything until someone deletes it, so a retention policy needs a scheduled delete. That job also has to cover backups, exported traces and memory stores, which a delete on the server does not reach.

The self-hosted server has the same API as the hosted one, apart from listed differences. Nothing is copied from the hosted service, session history included. Agents, skills, vault credentials and memory stores must be created again on your server.

Four features exist only on a self-hosted server. You choose the inference provider and can use your own secret manager. People sign in through your OpenID Connect identity provider, with roles taken from groups. Agent identity sends a short-lived signed token with an agent's calls to an MCP server, which agents use to reach tools.

Several hosted features are missing, among them cloud environments, the Messages API and Models API, the Files API, scheduled deployments and webhooks. MCP OAuth vault credentials are not available, because there is no OAuth refresh flow. You use a static bearer token and rotate it. The prebuilt docx, pdf, pptx and xlsx skills must be uploaded as custom skills.

Four things behave differently. The Claude Console at platform.claude.com does not show what is on your server. The server connects only to MCP hosts you list. Web search and web fetch stay off until you turn them on, and an agent can delegate only to subagents you list.

The documentation warns that the agent's bash tool is a real shell with the worker process's permissions and network access. The worker does not isolate it. Isolation comes from the container or virtual machine the worker runs in.

Anthropic's security page for self-hosted sandboxes gives some duties to Anthropic. Self-hosted, they become yours, including securing the server, hosting memory stores and detecting unusual usage. Each deployment serves one tenant at one trust level, and the server API key reaches every environment. The docs say to give each tenant its own deployment, database, server API key and workers.

Anthropic's article sets out four design principles for all three options. The part that runs the agent's reasoning is kept apart from the sandbox where it acts. Credentials stay out of the sandbox, added by a proxy outside it, and self-hosting lets you keep them in your own secrets manager. Network access can be limited to a list of allowed hosts. Every session keeps a record of each step and tool call, which can be exported over OpenTelemetry.

Scheduled deployments and webhooks are missing on a self-hosted server. A workflow that starts on a schedule or reports back through a webhook is likely to need its own scheduler and callback. Teams already on the hosted service have agents, skills, credentials and memory stores to rebuild, because nothing carries over.

The worker does not isolate an agent's shell, so the container or virtual machine is the only boundary around it. A security team can then design and test that boundary before the first agent runs.

A firm that runs agents for several business units, or for its own customers, likely needs a server, database and key for each. Each one has to be patched and watched.

The server software comes under Anthropic's Software License Agreement for the Claude Managed Agents Server, effective 12 November 2026. The licence is limited, non-exclusive, non-transferable and royalty-free, and covers binary code only. You contract with Anthropic Ireland, Limited if you are in the EEA, Switzerland or the UK, and with Anthropic, PBC elsewhere.

It covers an internal deployment, for your own business and products, and a managed service to your customers. Anthropic may limit a licensee to one of the two by written notice. You may not modify the code or disable its safety, security or access control functions. You also may not use it with a third-party model, except as the documentation permits.

Anthropic may deliver updates but does not have to, and it does not have to support any version. A licensee must deploy a safety update within one business day of delivery. On written notice of a safety, security or misuse risk, it must disable a feature or roll back a version within 8 hours.

A licensee must use commercially reasonable efforts to deploy other updates within 30 days. A version Anthropic withdraws must be out of use within 30 days.

Royalty-free describes the software licence only. The licence page does not cover what model usage costs, and Anthropic's pages give no price for the beta. The server, database and workers also run on infrastructure you pay for.

A one-business-day safety update and an 8-hour rollback likely need an on-call owner and a tested release path. The change process may also need to approve a release the same day, outside office hours too.

If you plan to run agents for your own customers, read the managed service terms early. Anthropic can limit a licensee to one kind of use by written notice.

This is our reading of the licence, not legal advice. Have counsel read it before you join the beta.