Self-hosted Claude Managed Agents: read the licence first
Self-hosted Claude Managed Agents puts you on an 8-hour rollback clock with 1-day safety updates. See what the licence requires and when to skip it.
Self-hosted Claude Managed Agents puts the whole Managed Agents service on your infrastructure, and its licence sets clocks most architecture reviews never see: 8 hours to roll back a feature Anthropic flags, 1 business day to deploy a safety update, 48 hours to report an incident.
This post rests on Anthropic's public documentation and licence text as read on 15 November 2026. We have not deployed it ourselves, so treat what follows as a close reading of the paperwork, not a field report. Access is also gated: the docs say to request the release archive through your Anthropic account team.
Three hosting options, and what each one moves to you
Anthropic's docs describe three ways to host Managed Agents. The difference between self-hosted sandboxes and the full self-hosted service comes down to who runs the agent loop and who stores the session history.
| Option | Sandboxes | Service (API, agent loop, history) | Model calls |
|---|---|---|---|
| Cloud sandboxes (default) | Anthropic | Anthropic | Anthropic |
| Self-hosted sandboxes | You | Anthropic | Anthropic |
| Self-hosted Managed Agents | You | You | Anthropic, or a provider you choose |
Anthropic's own guidance is to start with a cloud environment and choose a self-hosted sandbox only if tools must run on infrastructure you control. The docs reserve the full service for two needs: storing agents, sessions and session history yourself, or sending model calls to Amazon Bedrock, Claude Models on Google Cloud (Google managed), Microsoft Foundry or a model gateway you run. If you only need tools to run inside your network, they say to use self-hosted sandboxes and let Anthropic run the service.
Running the service also changes your calendar. The same page says you run and secure a server, its database and your sandboxes, and you install each release yourself. The server needs PostgreSQL 16 or later, and without a database it keeps its data in memory, so a restart erases it. Someone on your side has to own all of that, whether that is your platform team or an AI engineering partner.
Self-hosted Claude Managed Agents: the licence clocks
The server software sits under the Software License Agreement for the Claude Managed Agents Server. It is royalty-free (section 2.1), and use of Anthropic models through your deployment stays under the separate agreement that governs your model access (section 2.4). What it adds is a set of obligations with deadlines attached:
| Clause | What you must do | Deadline |
|---|---|---|
| 5.2 Safety updates | Deploy each update Anthropic identifies in writing as necessary to address a safety, security or misuse risk, in each deployment | 1 business day after delivery |
| 5.3 Safety rollback | Disable a feature or roll back a version after written notice that it presents a safety, security or misuse risk | 8 hours after the notice |
| 5.4 Other updates | Use commercially reasonable efforts to deploy any other update | 30 days after delivery |
| 5.5 Withdrawn versions | Stop using a version Anthropic withdraws and delete all copies | 30 days after notice, or the shorter 5.2 or 5.3 period |
| 5.7 Agent incidents | Notify Anthropic, investigate, and report the results and the fix | 48 hours after confirming the incident |
| 7.5 Unauthorised access | Notify Anthropic in writing of unauthorised access to, or use or disclosure of, the licensed code | 72 hours after becoming aware |
| 9.2 Termination | Either party may end the agreement for convenience | 90 days' written notice |
Three details in that table deserve a second read. First, the 8-hour rollback in section 5.3 is counted in hours, while the safety-update window in section 5.2 is counted in business days. Our reading is that a rollback notice that lands on a Friday evening still runs on the clock through the weekend, so you need a named on-call owner and a tested way back to a previous version before you go live.
Second, the duty applies "in each deployment". The licence defines a deployment as the managed service or an internal deployment, to the extent you operate it. Whether a staging cluster counts is a question to settle with Anthropic in writing before you sign, not after the first notice.
Third, an agent incident is not defined by the licence alone. Section 5.7 ties it to a safety feature being triggered, or other anomalous agent behaviour being detected, based on thresholds you and Anthropic agree in writing, and an email is enough. Until you have agreed those thresholds, you cannot say when the 48-hour clock starts. Section 5.8 adds that you may not disable, bypass or materially alter a custom safeguard without Anthropic's prior written consent.
Section 5.6 is the one that affects architecture most. Anthropic may decide, for safety reasons, that some or all of your customers should reach certain models only through its hosted service, and the licence says not every model may be available through your deployment. A design that promises a specific model fully inside your perimeter carries that caveat.
The licence also gives you a way out, but a slow one. Either side can terminate for convenience on 90 days' notice, and section 9.3 allows up to 90 days of wind-down use to move your own workloads off an internal deployment. If agents become part of a customer-facing process, plan that migration before you need it.
Does self-hosted Claude Managed Agents keep your data in your network?
Stored data stays with you, but prompts do not stay put by default. According to Anthropic's data and access page, the server stores agents, sessions and session history in your database, and Anthropic has no remote access to the server or its log. Each model call, however, carries the conversation so far, including prompts, tool inputs and tool results, to your inference provider.
That provider is the Claude API unless you change it. The inference provider setting takes five values:
| Provider value | Model calls go to | Server authenticates with |
|---|---|---|
| anthropic (default) | The Claude API | ANTHROPIC_API_KEY |
| bedrock | Amazon Bedrock | Your AWS credential |
| vertex | Claude Models on Google Cloud (Google managed) | Google Application Default Credentials |
| foundry | Microsoft Foundry | A Foundry API key, or Microsoft Entra ID |
| gateway | A model gateway you run | A key or token your gateway accepts |
The docs say the server connects to Anthropic only when the Claude API is the provider. When it is, each call carries up to three headers holding IDs that your server generated, for the session, the agent and the environment, and the docs say no setting turns them off. Requests also carry a User-Agent header naming the server software, and some calls carry the label cma-server in the request body. Anthropic can use these to count usage of self-hosted Managed Agents.
On retention, the same page explains that Managed Agents is listed as not covered by zero data retention because Anthropic stores transcripts when it runs the service. When you run it, you store them, and sessions stay in your database until you delete them. For a compliance review, "the history is in our Postgres" is true. "Nothing leaves our network" is only true if your chosen provider sits inside the boundary you mean.
What you give up compared with the hosted service
A self-hosted server has the same API as the hosted one apart from the exceptions on Anthropic's differences page. Nothing is copied across, session history included, so you recreate agents, skills, vault credentials and memory stores on the new server. Several features do not exist there at all:
| Feature | On a self-hosted server |
|---|---|
| Cloud environments | Not available. Only self_hosted environments exist, and a request for a cloud one returns a 400 error |
| Messages API and Models API | Not served. Calls to /v1/messages and /v1/models return 404 |
| File session resources and Files API | Rejected. Memory store resources still work |
| mcp_oauth vault credentials | Rejected. Store the token as a static bearer credential and refresh it yourself |
| Prebuilt docx, pdf, pptx and xlsx skills | Rejected. Upload your own copies as custom skills |
| Scheduled deployments, dreams, webhooks | No routes, and no webhooks are sent |
| Web search and web fetch | Off until enabled. web_search works under anthropic, vertex and foundry; web_fetch under anthropic and foundry |
Two defaults will catch teams on day one. The MCP host allowlist is empty, so the server refuses to save an agent that names an MCP server until you list its host. The same goes for Git hosts before a session can use a GitHub repository resource. Each of these is a small task, but together they are a migration plan, and you should price them before you assume the self-hosted server is a drop-in copy of the hosted one.
Who is responsible for security in self-hosted Claude Managed Agents?
You are. The self-hosting overview says that what the sandbox security page assigns to Anthropic becomes your responsibility, including securing the server, hosting memory stores and detecting unusual usage. Anthropic's security model page already lists a long set of duties even when it runs the service: sandbox image quality, network egress controls, storing and rotating the environment key, and isolating untrusted workloads.
Three warnings in the docs matter most for design:
- The agent's bash tool is a real shell with the worker process's permissions and network access, and the worker does not isolate it. Isolation comes from what the worker runs in, so run it in a disposable container or VM that holds nothing you need to protect.
- Each deployment serves one tenant at one trust level. The server API key reaches every environment, so separate tenants or trust levels need separate deployments, each with its own database and workers.
- Roles limit only requests made with a caller's own token. Code the agent runs can call the server with any credential its sandbox holds, so keep the environment key out of the sandbox.
The quickstart adds that its Docker Compose stack is for development, not production, and that Anthropic recommends the release's Helm charts for production. If you want the wider argument for why agents route around controls that sit outside their reach, we have covered how AI agent security controls get routed around, and the sandbox question in where long-running agents live.
When self-hosting the whole service is the wrong choice
The strongest case for self-hosting is a regulated team that must keep session history in its own PostgreSQL database and send inference through its own Bedrock or Foundry account. That is exactly what the docs say the option is for, and for those teams the licence deadlines are the price of admission. For almost everyone else, a self-hosted sandbox covers the genuine need, tools running on your hosts, without making you the operator of the service.
Before you request access, answer these five questions:
- Is there a written requirement that session history lives in your database, or that inference goes through a provider other than the Claude API? If not, stay with self-hosted sandboxes or cloud sandboxes.
- Who can deploy a safety update within 1 business day and roll back a flagged feature within 8 hours, in every deployment you run?
- Have you agreed in writing what counts as an agent incident, so the 48-hour clock has a start?
- Do your agents depend on anything missing from a self-hosted server, such as file resources, webhooks, scheduled deployments or prebuilt document skills?
- Can the business live with a 90-day notice period if either side ends the agreement for convenience?
If you answer "no" to the first question or "nobody" to the second, the architecture is not your problem yet. Budget matters here too: our AI agent development cost breakdown shows how much of an agent project sits outside the model bill, and an operated server adds to that side of the ledger.
Decide the hosting option before you request access
The cheapest mistake to fix is the one you make on paper. Map each agent workload to a hosting option, the data it touches, and the person who answers a safety notice, then compare that against the licence table above. If you are weighing self-hosted Managed Agents against sandboxes or a cloud setup, our AI engineering team can scope the agent architecture, the operating model and the rollback plan with you before you ask your Anthropic account team for the release archive.
Frequently asked questions
Yes. Anthropic offers self-hosted Claude Managed Agents, where you run the API, the agent loop and the storage, plus the sandboxes. Access is not self-serve: the docs say to request the release archive through your Anthropic account team. Anthropic recommends Helm charts for production and Docker Compose only for development.
With self-hosted sandboxes you run only the workers that execute the agent's tools, while Anthropic runs the service and stores session history. With self-hosted Managed Agents you also run the server, its PostgreSQL database and the agent loop, and you can send model calls to another inference provider such as Amazon Bedrock.
The server licence is royalty-free, so the cost comes from your own infrastructure and from model usage, which stays under your separate agreement with Anthropic. We found no published price for the software in the documents we read, so confirm commercial terms with your Anthropic account team before you plan a budget.
Stored data does: agents, sessions and history sit in your own PostgreSQL database. Prompts and tool results do not stay put by default, because each model call sends the conversation to your inference provider, which is the Claude API unless you configure Bedrock, Google Cloud, Foundry or a gateway.
You are. Anthropic's docs say what the sandbox security model assigns to Anthropic becomes your responsibility when you self-host, including securing the server, hosting memory stores and detecting unusual usage. Each deployment should serve one tenant at one trust level, and workers should run in disposable containers or VMs.
