Self-Hosted Claude Managed Agents: Run Claude’s Agent Harness in Your Own Cloud (Private Beta Guide)

The announcement came from @ClaudeDevs as a two-post thread, so here are both posts first. The second one carries the two facts that matter most for planning: who can use it, and how to ask.

Short answer

Self-hosted Claude Managed Agents lets you run Anthropic’s Managed Agents service on your own infrastructure instead of using Anthropic’s hosted version. It entered private beta on November 12, 2026, and it is available only to eligible organizations that ask their Anthropic account team for access. You operate the Managed Agents server, its PostgreSQL database and the workers that run each agent’s shell and file tools. Session history is stored in your database. Model calls go to Anthropic, Amazon Bedrock, Google’s Agent Platform, Microsoft Foundry or your own gateway, as you configure.

• What you get: the same core APIs as the hosted service, with the control plane, credentials and history inside your perimeter.
• What you take on: running, securing and patching the server, its database and your sandboxes, and installing each release yourself.
• What stays outside: Claude. Each model call sends the conversation so far, including tool inputs and results, to your inference provider.
• Not announced: pricing, a general availability date, eligibility criteria and system requirements beyond what the docs list. We say so wherever it matters below.

This post is a reading of Anthropic’s announcement and documentation, not a hands-on test. The server download is gated behind the account team, so we did not run it. Every claim below names its source. For the wider field of places to run agent code, see our guide to the best AI agent sandboxes and the roundup of AI agent hosting platforms.

Video: Run Claude Managed Agents on Cloudflare: Everything You Need to Know from the Cloudflare Developers channel. It is background on Managed Agents with a third-party sandbox provider, not a walkthrough of the self-hosted server, and we have verified only its title and channel. We found no official Anthropic video for the self-hosted beta as of November 12, 2026.

What Anthropic announced

The primary source is Anthropic’s article Operate Claude Managed Agents inside your security perimeter. It frames self-hosting as a new way to run Managed Agents, which it describes as a suite of composable APIs for building and deploying autonomous agents, providing the agent harness, sandboxes, credential handling and session history needed to put long-running agents into production.

The history, in Anthropic’s words, runs in two steps. Managed Agents first launched as a hosted service on the Claude Platform, where Anthropic runs the infrastructure. For teams that needed their code to stay in their own environment, Anthropic then added self-hosted sandboxes. The new step moves the rest: the harness, credentials and session history. Anthropic’s argument is that agents now take on work like fixing broken builds, testing releases, triaging alerts and working through a bug backlog, run unattended on your code, and need access to internal systems. For agents with that level of access, some teams want the whole service inside their environment, and until now that meant building the platform themselves.

Independent coverage the same day, from Help Net Security, restates the same facts and adds a useful caution we return to in the security section: the credential protection Anthropic describes is tied to MCP tools and supported API calls, so any other service an agent reaches deserves a check before the agent goes live. The Claude docs add the operational detail, including component names, the three credentials, the listener ports and the long list of differences from the hosted service.

What Managed Agents is, and how it got here

Claude Managed Agents runs Claude as an autonomous agent. Per the docs’ core concepts, you define an agent, pick an environment, start a session and exchange events with the agent while it works. The harness is the agent loop, which calls Claude. The sandbox is where the agent’s bash and file tools run. Vaults hold credentials, and memory stores let an agent keep notes across sessions. You reach all of it through the SDKs, the ant CLI or the REST API. If you use the CLI already, our Claude API and ant CLI guide covers the basics.

The May step matters for understanding this one. In that release, the agent loop stayed on Anthropic’s infrastructure while tool execution moved to your environment, which is the line a New in Claude Managed Agents post drew explicitly. The Decoder summed up the limit at the time: a fully on-premises deployment was not possible. November’s release removes that limit for organizations Anthropic admits to the beta. For pricing context on the hosted side, Anthropic’s launch post says Managed Agents is priced on consumption, with standard Claude Platform token rates plus $0.08 per session-hour of active runtime. We found no equivalent figure for the self-hosted server.

Three ways to run Managed Agents

The docs reduce the choice to one table. The name of each option says what you host.

Two details sit behind that table. First, in the middle option, tool inputs and outputs still flow to Managed Agents on Anthropic’s side so the model can see results, according to the self-hosted sandboxes docs. Second, the docs say to pick self-hosted Managed Agents only when you need one of two things: agents, sessions and history stored on your own infrastructure, or model calls routed to Amazon Bedrock, Claude Models on Google Cloud (Google managed), Microsoft Foundry or your own gateway. If you only need tools to run on your infrastructure, the docs point you back to self-hosted sandboxes.

Architecture: server, database and workers

The docs describe one deployment as one or more servers, their database and your sandboxes, all inside your network, with a single outbound arrow to the inference provider. Here are the parts, using the names in the docs.

This is the brain and hands split in concrete form. The server is the brain: it holds the conversation and calls the model. Workers are the hands: they poll the server for work, run each tool call locally and post the result back. A session’s model turns can run even when no worker is polling, and the first tool call then waits without an error until a worker picks it up, which is worth remembering when a session looks stuck.

Isolation is your job here, and the docs are blunt about it. 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. The Docker Compose stack and the cma-sandboxes Helm chart start each session’s worker in its own container or pod, and the docs say that if you start a worker yourself, it should run in a disposable container or VM that holds nothing you need to protect. A separate Helm chart deploys the server on Kubernetes. For the sandbox layer itself, our sandbox comparison lists the providers that publish worker guides, and the Claude docs list AWS Lambda MicroVMs, Blaxel, Cloudflare, Daytona, E2B, Fly.io, GKE Agent Sandbox, Modal, Namespace, Superserve and Vercel as platform guides for self-hosted sandboxes.

The three credentials

A self-hosted deployment juggles three separate credentials, and the docs keep them apart on purpose. The server API key is held by your applications, the ant CLI and the admin CLI, and plays the role a Claude API key plays with the hosted service. The inference credential is held only by the server and authenticates its model calls, whether that is a Claude API key, your cloud provider’s credential or the token your gateway accepts. The environment key is held by the workers that poll one environment’s queue and sessions. Applications and workers never need the inference credential.

Model routing and what leaves your network

Anthropic’s announcement lists the destinations for model requests: Anthropic directly, your cloud provider (Amazon Bedrock, Google’s Agent Platform or Microsoft Foundry) or your own gateway. In the docs the server’s inference.provider setting selects the route, and the differences page shows the values anthropic, vertex, foundry and gateway. Which provider you choose changes which features work, so this is a design decision, not a footnote.

If you route through a cloud provider, expect to check that provider’s own docs for which models and regions support a feature. The Claude docs say custom tools, MCP tools and the tools your worker runs behave the same under every provider. For teams that already put a proxy in front of model traffic, the gateway option is the hook, and our roundups of LLM API gateways and AI inference providers cover the options on the other end of that connection.

What the server connects to

For each model call the server sends the conversation so far, tool inputs and tool results included, to your inference provider. By default that is the Claude API, and a call there also carries the IDs of its session, agent and environment. The data and access page lists every destination the server contacts: your inference provider, its database, any service that issues its model credential, a cloud provider’s model-listing service if you use one, MCP servers and Git hosts you allow, an OpenTelemetry collector, single sign-on identity providers, and a secret manager or key management service if you configure one. The server connects to Anthropic only when the provider is the Claude API, and the docs state that Anthropic has no remote access to the server or its log.

There is one disclosure to know about before a security review. Every request to the Claude API carries a User-Agent header naming the server software and version, and model calls can carry the label cma-server in metadata.user_id. The docs say the label is identical on every server and does not identify your deployment, users or sessions, and that Anthropic can use these fields to count usage of self-hosted Managed Agents. The label is sent on calls to the Claude API, to Microsoft Foundry and to a gateway that accepts the same requests as the Claude API. It is never sent on calls to Amazon Bedrock, to Claude Models on Google Cloud (Google managed) or to a gateway with another request format.

On data retention, Anthropic says that if your organization has zero data retention with Anthropic, it applies to the requests sent to Claude in the same way as any other Messages API call. Your database is a different matter: sessions and history stay there until you delete them, and the server does not delete a session because of its age. Deleting through the API removes the session and its history but not copies in backups, exported logs and traces, or what an agent wrote to a memory store.

The four security principles in practice

Anthropic’s reasoning is simple. When an agent runs unattended inside your code and systems, you cannot rely on a person checking every step, so the limits have to be built into the system. It lists four principles and says they apply whether Anthropic hosts everything, you host just the sandbox, or you host the whole service. Here is what each one means when you are the operator.

1. The brain and the hands are split

The harness calls Claude, and the sandbox is where the agent’s code runs. The agent loop, session history and vault secrets stay outside the sandbox, sandboxes start only when a tool needs one, and history lives as an event log outside the sandbox. In practice this means a sandbox that dies mid-task does not kill the session, and a compromised tool execution cannot read the session store or the vault because they are not in the sandbox. It also means your isolation effort goes into the worker environment, as covered above, not into the server.

2. Credentials stay out of the sandbox

Vaults are designed to keep credentials out of the sandbox. For MCP tools and supported API calls, a proxy outside the sandbox adds the credential to the request, and in a self-hosted deployment you can also store credentials in your own secrets manager. The docs give concrete cases. The server stores the secret of each new vault credential in your secret manager instead of its own database if you configure one. For Git, the token your client sends never reaches the sandbox because Git traffic goes through your server, which adds the token. The server can also sign a short-lived agent identity token and send it with an agent’s calls to an MCP server, which checks it against public keys you publish. The limit to keep in mind is the one Help Net Security flagged: this protection covers MCP tools and supported API calls, so a CLI that needs a secret inside the sandbox is a separate problem. The docs offer the optional egress gateway for environment_variable vault credentials, and the server rejects those credentials until you turn the gateway on.

3. Network access can be limited

You can limit each environment to a list of allowed hosts, and requests to any other host are blocked. Anthropic’s own example is an agent that fixes broken builds, where the list might be just your git host and your package registry. When you host the sandbox yourself, you set the same limits in your own firewall, which makes the allowlist your configuration to get right. A practical version for that build-fixing agent: allow the Git host over HTTPS, allow the package registry, deny everything else, and name the branch the agent may push to. The server has its own allowlists for MCP hosts and Git hosts, covered next.

4. Every session leaves a full record

Managed Agents keeps a record of each step an agent took, including tool calls and what came back, and the record exports over OpenTelemetry so you can review agent activity next to the rest of your systems. On your own server, the details are specific. The server writes its log to standard error, records no traces or metrics until you turn them on with the standard OpenTelemetry environment variables, and sends them only where those variables point. A Prometheus endpoint can expose metrics, and it asks for no credential, so who can reach it depends on where it listens. Anthropic’s OpenTelemetry docs add that the environment worker in the Python, TypeScript and Go SDKs emits a span per tool it runs, grouped under one anthropic.environment.work span per work item. If you already run tracing, our guide to LLM observability and eval tools compares the backends you could send this to.

What you own as the operator

The docs say the self-hosted sandboxes security model applies, with one change: what that page assigns to Anthropic is yours here. That includes securing the server, hosting memory stores and detecting unusual usage. Anthropic cannot know that a key leaked, cannot verify your worker image, and cannot enforce data retention once session content reaches your worker. Each trust level also needs its own deployment, where the sandbox-only setup suggested a separate workspace and environment per trust boundary. The practical checklist is short: patch each release, store the environment key in a secrets manager, rotate it on suspicion, run workers with least privilege, and restrict outbound traffic.

Allowlists you must set

Several features are off or refuse every host until you edit the server’s settings file. That is a sensible default, and it is also where first-day surprises come from.

# Server settings file: names are from the differences page of the docs
mcp:
  allowed_hostnames:
    - mcp.example.com        # exact match, no wildcards, empty by default
git:
  allowed_hostnames:
    - github.com             # HTTPS only
  allowed_push_refs:
    - refs/heads/agent/      # agents can push only to branches you list
web_tools:
  enabled: true              # web_search and web_fetch are off by default

• MCP servers: the server connects only to hosts under mcp.allowed_hostnames. Matches are exact, there are no wildcards, and the list is empty by default. An MCP server inside your private network needs no MCP tunnel: put its HTTPS URL in the agent definition and add its host to the list.
• Git hosts: github_repository resources are rejected until their hosts are listed. Agents push only to branches matching allowed_push_refs. The docs warn that the server does not refuse force pushes, so protect branches on your Git host if you need that, and that agents are not told the branch list, so name the branch in your prompt.
• Web tools: web_search and web_fetch are off by default, and with the tools off an agent that lists them runs without them and no error says so.
• MCP results: results larger than mcp.max_result_bytes (100 KiB by default) are cut, the model is told, and the rest is lost.

If your agents depend on private tools, our roundup of MCP integration platforms and the list of best MCP servers for Claude Code are good places to find servers to put behind that allowlist.

What a first run looks like

The docs include a Docker Compose quickstart. It starts the server, its PostgreSQL database and a set of workers that run each session in a sandbox container of its own, then has you chat with an agent from your terminal and confirm the tool calls ran in a sandbox. Anthropic labels the stack as development only: it serves plain HTTP and publishes port 8400 on the host’s loopback address. Under some Docker Engine releases before 28.3.3, machines on the local network can reach that port too, so the docs say to use a machine that holds nothing you need to protect. You need the release archive from your account team and a Claude API key in the stack’s .env file, and the docs ask that you set ANTHROPIC_BASE_URL and ANTHROPIC_API_KEY for the ant CLI so it talks to your server instead of the hosted service.

# Docs quickstart (development only): start the stack from the release archive
docker compose up --build -d
docker compose logs -f cma-server

# Wait for: msg="cma-server listening", then check readiness
curl -s http://127.0.0.1:8400/cma-server/readyz
# A ready server answers with "status":"ready"

# Start a session against the stack's environment, then chat from the terminal
AGENT_ID=$(ant beta:agents list --format raw \
  --transform 'data.#(name=="Quickstart agent").id' --raw-output)
ENVIRONMENT_ID=$(ant beta:environments list --format raw \
  --transform 'data.#(name=="compose-sandbox").id' --raw-output)
SESSION_ID=$(ant beta:sessions create --agent "$AGENT_ID" \
  --environment-id "$ENVIRONMENT_ID" --transform id --raw-output)
ant beta:sessions connect "$SESSION_ID"

Environments on a self-hosted server are always self_hosted. A request for a cloud environment returns a 400 error, so every environment needs workers you deploy. The environment definition is the same one the sandbox docs use:

# yaml-language-server: $schema=https://platform.claude.com/schemas/ant/beta/environment.json
name: self-hosted
config:
  type: self_hosted          # the only environment type a self-hosted server accepts

Each release archive also ships an operator guide, operator-guide.md, for that version. The docs suggest having Claude read it so Claude can help you configure and run the server. For production the docs point to the server Helm chart and the cma-sandboxes chart on Kubernetes, but we did not find their values documented in the pages we read, so plan to read the guide in your release.

Differences from the hosted service

The API matches the hosted service apart from the differences page, and Anthropic says to check it before moving an application. Treat the list below as a migration checklist. Nothing is copied from the hosted service, so agents, skills, vault credentials and memory stores are created again on your server.

Two of these deserve attention. First, losing scheduled deployments and webhooks means that unattended triggers, such as a nightly bug-backlog sweep or an alert handler, become your scheduler’s job. Second, the Messages API is not served, so an application that mixes direct model calls and Managed Agents calls needs two clients. If you already run self-hosted sandboxes, the docs say the worker software is the same and your workers can connect to your server, but a worker that starts on a webhook does not work against it.

Use cases

Anthropic’s own examples are fixing broken builds, testing releases, triaging alerts and working through a bug backlog. The second @ClaudeDevs post frames the target as work that needs access to your code and internal systems. Below are the shapes those take under the documented controls. They are our illustrations of how the documented pieces combine, not Anthropic-published reference designs.

Self-hosting is a heavy option for lighter needs. If you only want a sandbox you control, self-hosted sandboxes cost less to operate, and if you want a persistent personal agent on a server, the lighter path in our VPS for AI agents guide may fit better than running a full Managed Agents server.

Eligibility and how to request access

The path is the same in every source: contact your Anthropic account team. The tweet says the private beta is only available to eligible orgs, and the docs add that you request access to the download through the account team. We could not find a public form, a waitlist, published eligibility criteria, supported regions or an SLA. If you have no account team yet, the announcement gives no alternative route. Before the conversation, it helps to know your answers on four points:

• Where the server, PostgreSQL 16 or later and workers will run (Kubernetes or Docker Compose are the documented paths).
• Which inference provider you want: Anthropic directly, Bedrock, Google, Foundry or a gateway, and which features you need that depend on that choice.
• Which hosted-only features you use today, from the differences list above.
• Your identity provider, since single sign-on uses OpenID Connect, and your secret manager if you want one.

Versus building your own harness or using the Agent SDK

Anthropic’s stated reason for the product is that, until now, a team wanting the whole service in its own environment had to build the platform itself. The documented contrasts are narrower than a full buy-versus-build analysis, and we found no published cost, benchmark or reliability comparison, so treat the table as a map of what each option is, not a ranking.

The Agent SDK row is from Anthropic’s Agent SDK overview, which separates the SDK, the CLI, the client SDK and Managed Agents by who runs the agent and how you reach it. The practical difference for an operator is the API shape. Managed Agents gives you agents, environments, sessions and events behind a service, and the self-hosted server is that service running in your account. If you are weighing open frameworks for the loop instead, our roundup of AI agent frameworks covers the code-first alternatives. The honest unknown is comparative: Anthropic has not published how much operating a server costs you in practice, or how it performs against a harness you build.

Open questions: what is not announced

Two other items belong on a risk list rather than a to-do list. The beta label means behavior and the differences list can change, and the data-handling table on the self-hosted sandboxes page lists Managed Agents as not eligible for HIPAA, and as not eligible for ZDR except for self-hosted Managed Agents. Confirm any compliance claim with Anthropic in writing for your exact configuration.

Verdict

This is a real answer for a specific buyer: an organization that wants autonomous agents working on its code and internal systems, and that needs the control plane, credentials and history inside its own perimeter. Anthropic is giving that buyer the same API as the hosted service, a choice of model route, and a documented security model. In return you run a server, a database and a sandbox fleet, and you give up several hosted features.

The practical plan is short. If you only need tool execution on your infrastructure, stay with self-hosted sandboxes. If your requirement is storage and model routing under your control, ask your account team about the beta, list the hosted-only features you rely on, and test them against the differences page before committing. Until Anthropic publishes pricing and a GA date, it is a pilot decision, not a platform migration.

FAQ

Sources

Sources checked November 12, 2026.

• Operate Claude Managed Agents inside your security perimeter: Claude / Anthropic, Nov 12, 2026 (announcement, four principles, model routing, ZDR)
• Self-hosted Claude Managed Agents, Differences from the hosted service, quickstart and Data and access: Claude docs (components, credentials, settings, differences, listeners, retention)
• Self-hosted sandboxes and its security model: Claude docs (how workers run, shared responsibility, availability and data handling)
• OpenTelemetry tracing for the Claude API: Claude docs (traces, environment worker spans)
• Agent SDK overview: Claude docs
• Claude Managed Agents launch post and New in Claude Managed Agents: Claude / Anthropic (hosted pricing, self-hosted sandboxes and MCP tunnels)
• The New Stack, May 19, 2026: dates for the April and May launches
• Help Net Security, Nov 12, 2026: independent coverage of the announcement
• X posts: @ClaudeDevs and @ClaudeDevs reply, Nov 12, 2026
• YouTube: Run Claude Managed Agents on Cloudflare: Everything You Need to Know, Cloudflare Developers