Self-Hosted Claude Managed Agents: Anthropic's Private Beta, Explained

Self-hosted Claude Managed Agents opened in private beta on November 12, and it is the biggest architectural change to Anthropic's agent platform since Managed Agents launched. Until now, Anthropic ran the service and customers could, at most, host the sandbox where an agent's code executes. The self-hosted option moves the whole control plane, the server, its database, the credential store, and the session history, into the customer's own cloud or on-premise environment. Access goes through the Anthropic account team. Source

What Claude Managed Agents is

Managed Agents is Anthropic's pre-built, configurable agent harness. Instead of writing your own agent loop, tool execution, and runtime against the Messages API, you get a managed environment where Claude can read files, run commands, browse the web, and run code, with built-in prompt caching and compaction. It is built around four concepts: the agent (model, system prompt, tools, MCP servers, and skills), the environment (where sessions run), the session (a running agent instance), and events (the messages exchanged with it, streamed over server-sent events). Source

The service is in beta under the managed-agents-2026-04-01 header, works with all Claude models, and is available on the Claude API, Claude Platform on AWS, and Claude Models on Google Cloud. Built-in tools cover Bash, file operations, web search and fetch with domain allowlists and blocklists, and MCP servers. The docs position it for long-running, asynchronous work: tasks that run for minutes or hours, stateful sessions with persistent filesystems, and scheduled execution. Source

What self-hosted changes

The short version: every part of the service now runs in your environment. You operate the Managed Agents server, its PostgreSQL database, and the workers where agents run their shell and file tools. Session history lives in your database. Your developers build agents against the same core APIs as the hosted service. Source

One caveat matters for anyone planning a migration: the self-hosted server has the same API, but nothing is copied from the hosted service, session history included. Agents, skills, vault credentials, and memory stores have to be created again on your server. Source

How the deployment works

The quickstart ships a Docker Compose stack: the server, its PostgreSQL database, and a set of workers that run each session in a sandbox container of its own. Anthropic is explicit that the Compose stack is for development, not production. It serves plain HTTP, publishes port 8400 on the Docker host's loopback address, and under some Docker Engine releases before 28.3.3 that port can be reachable from the host's local network. Since agent tools run in containers on that host, the docs advise using a machine that holds nothing you need to protect. For production, Anthropic recommends the release's two Helm charts and points to a Kubernetes deployment guide. Source

The stack's secrets come from a .env file: the database password, your Claude API key for model calls, the server API key your applications send, and a key that encrypts the server's stored secrets. Access to the release archive itself requires contacting the Anthropic account team. Source

What your server can do that the hosted service cannot

Four features exist only on the self-hosted server. It can send model calls to a cloud provider or your own model gateway instead of the Claude API, which means inference can route through Amazon Bedrock, Google's Agent Platform, Microsoft Foundry, or an internal gateway. It supports single sign-on, where callers authenticate with a token from your OpenID Connect identity provider and get a role from the token's groups. It can store each new vault credential's secret in your own secret manager instead of its database. And it can sign a short-lived token for an agent's calls to an MCP server, so the MCP server or gateway can verify the agent's identity against public keys you publish. Source

What the self-hosted server does not have

The differences page lists real gaps, and teams should read it before planning a move. Cloud environments do not exist on your server: a request for one returns a 400 error, so every environment needs self-hosted workers. The server does not serve the rest of the Claude API; calls to /v1/messages and /v1/models return 404. The Files API and file session resources are absent. mcp_oauth vault credentials are rejected because the server has no OAuth flow to refresh tokens, so you store tokens as static_bearer credentials and rotate them yourself. The prebuilt docx, pdf, pptx, and xlsx skills are rejected; you upload custom skills instead. Scheduled deployments and dreams have no routes, so recurring runs come from your own cron. Webhooks are not sent, so workers poll rather than wake on an event. Source

Behavior differs in a few places too. The Claude Console at platform.claude.com does not show what is on your server; you use the console on your server. Multiagent orchestration is restricted: an agent can delegate only to subagents you list, and the server accepts a multiagent block only if its type is coordinator. Dynamic workflows, the advisor, and self-defined subagents are out. Source

What leaves your network

Anthropic published a data-and-access page written to answer a security review, and it is refreshingly specific. The server connects only to destinations you would expect: your inference provider, its database, the credential-issuing services you configure, the MCP servers and Git hosts you allow, an OpenTelemetry collector if you configure one, your SSO identity providers, and a secret manager or key management service if you use one. The default inference provider is the Claude API; the server connects to Anthropic only when that is the provider, and Anthropic has no remote access to the server or its log. The docs suggest verifying this by comparing your egress proxy or firewall log against the published list. Source

Two details deserve attention. When the Claude API is the inference provider, each model call carries up to three headers holding server-generated session, agent, and environment IDs, so Anthropic can attribute usage; no setting turns them off, and the IDs encode creation time. The server also checks its model-call credential against the Claude API at startup and every 60 seconds, though those checks run no inference. Separately, workers are their own trust domain: a worker has whatever network access you give its container, VM, or sandbox, and every command an agent runs inherits that access. Source

On data retention, the model itself still runs outside your network, so prompts go out and completions come back. If your organization has a zero data retention agreement with Anthropic, it applies to those requests the same way it does to any Messages API call. Notably, self-hosted Managed Agents is the one Managed Agents configuration eligible for ZDR; the hosted service is not, because its sessions are stateful resources whose transcripts persist until you delete them. Source

The security model behind it

Anthropic's announcement frames the design around four principles, applied the same way whether Anthropic hosts everything or you do. First, the brain and the hands are split: the harness calls Claude while the agent's code runs in a separate sandbox, and sandboxes start only when a tool needs them. Second, credentials stay out of the sandbox; a proxy outside it attaches the credential to MCP tool requests and supported API calls, and self-hosted customers can keep credentials in their own secrets manager. Third, each environment's network access can be limited to a list of allowed hosts, with everything else blocked. Fourth, every session leaves a full record of each tool call and its result, exportable over OpenTelemetry into your existing monitoring. Source

Help Net Security's coverage adds a useful caution on the second principle: Anthropic's credential-injection protection is scoped to MCP tools and supported API calls, so any other service an agent reaches is worth checking before the agent goes live. When you host the sandbox yourself, the network allowlist enforcement also becomes your firewall configuration to get right. Source

Our read

This section is our assessment, not Anthropic's claims. The self-hosted release completes a pattern we have been tracking: agent platforms are being pulled inside the enterprise perimeter because unattended agents with real credentials are now operational infrastructure, not experiments. The honest limitation list on the differences page is a good sign; a private beta that documents what it cannot do is easier to evaluate than one that does not. Teams standing this up should treat the workers as the blast radius: the server may be locked down while a worker container still has whatever network access someone gave it. That maps directly to the scoping discipline in least-privilege for AI agents, and the egress list gives you a concrete starting point for the kind of audit our AI agent security checklist walks through.

The credential design is the part we would test first. Vaults keep secrets out of the sandbox, but only for MCP tools and supported API calls, which means the boundary of "supported" is now a security-relevant question for every integration you wire up. Our MCP server security best practices post covers the adjacent failure modes. Practical bottom line: this is a private beta with an account-team gate, plain-HTTP development defaults, and no webhooks or scheduler. It is a serious evaluation candidate for regulated teams, and the Kubernetes path is the one to evaluate, not the Compose stack.