Claude Managed Agents goes self-hosted: Separate trust levels

On November 12, 2026, Anthropic opened self-hosted Claude Managed Agents in private beta. Teams can now operate the agent service and retain its session history in their own infrastructure, with model requests sent to their chosen provider. Previously, self-hosted sandboxes moved tool execution while Anthropic continued to operate the service.

A deployment can contain several environments, but those environments do not separate tenants or trust levels. Before connecting internal systems, decide which callers may use every worker environment in that deployment.

This guide turns the public documentation into a rollout review. General Analysis has not run the private beta; the examples and acceptance checks below are proposed procedures.

Choose how much of the service you need to own#

Anthropic's hosting overview distinguishes three arrangements. Choose based on where the workload must execute and where its history must reside.

The self-hosted service uses PostgreSQL 16 or later for durable state. Its server runs the agent loop; workers execute shell and file tools. The shell has the worker's permissions, so isolation must come from the container or VM around it.

Self-hosting also lets you choose an inference provider. It does not move Claude's model into your deployment. Review the provider configuration alongside the data you intend to send. For the wider execution baseline, see securing coding agents.

Split deployments where authority changes#

Consider a hypothetical platform with two jobs: triaging untrusted build failures and investigating production incidents. The incident agent needs access to internal operational data that the build agent must never reach.

Putting those jobs in two environments on one server leaves a shared access boundary. Anthropic's multitenancy rules require a deployment per tenant and trust level, each with its own database, server key, and workers.

For this example, use separate deployments. Admit build-triage callers only to the build deployment. Give the incident deployment its own identity-provider audience and role mappings. Keep their secrets separate in any shared secret manager, and identify each deployment separately to a shared model gateway. Do not set a fallback default_role that admits callers outside the reviewed groups.

An environment remains useful for choosing execution resources within a trust level. It should not be the only thing stopping a build-triage user from choosing a worker that can reach production.

Distinguish resource privacy from execution access#

The SSO role documentation gives user and developer the same access. Each sees and changes only their own agents, sessions, vaults, and memory stores. Both can list environments and run sessions in them. Administrators can access everything, including starting a session with another user's vault.

Alice may be unable to retrieve Bob's transcript yet still be able to start her own session in an environment with Bob's network reach. Check both properties during the access review.

The following illustrative excerpt maps only an incident-response group. Replace the issuer, audience, and group with values from your identity provider. Use a different audience in the build deployment, and make sure neither deployment accepts the other's audience.

Code source: illustrative, using Anthropic's SSO fields and configuration reference.

This is an authentication excerpt, not a complete server configuration. It grants no SSO administrator role and contains no credentials. The server API key remains an administrator credential by default; keep it out of ordinary clients.

Apply the excerpt in the server settings file, restart the server, and check its effective configuration. For settings that support environment variables, those values override the file; auth.issuers is file-only. If you choose auth.refuse_server_api_key: true, first establish a working OIDC administrator and recovery procedure: the setting refuses the key on every route, including admin CLI commands that depend on it. See the configuration reference.

For a non-production identity check, use synthetic accounts. A token issued for the other deployment should fail validation; a valid token with no mapped role should be refused. Record which test account and audience you used, the response, and the server's reason. Anthropic documents 401 for failed token checks and 403 for an unmapped role in its SSO troubleshooting section.

Keep worker credentials outside agent code#

Caller roles govern requests made with the caller's token. They cannot reduce the authority of another credential that agent-generated code finds in its sandbox. An environment key can read events and submit tool results across that environment's sessions. Keep it outside the sandbox, and isolate each session separately. Credential and sandbox boundary.

Review the actual deployment manifests before adding sensitive workloads. Record which process holds the server key, inference credential, environment key, and downstream service credentials. Inspect mounted secrets and inherited environment variables without copying their values into a report.

Anthropic's Kubernetes deployment separates the server and sandbox charts and requires a network plugin that enforces NetworkPolicy. Verify that requirement on the chosen cluster. The development Compose quickstart uses plain HTTP; its optional mock sign-in provider gives administrator access to anyone who can reach it. Keep that setup on a disposable development machine with throwaway data.

For downstream MCP access, the service can issue an agent identity token. The receiver must validate it and apply its own access policy. A valid agent identity is an input to authorization; your MCP service still needs to decide which records and actions that agent may use. The existing Managed Agents approval guide covers sensitive tool decisions separately.

Review the migration before switching clients#

Anthropic's hosted-service differences identify dependencies to resolve before moving an application:

• Hosted agents, credentials, and session history are not copied to your server. Recreate the resources the application needs and decide what happens to existing hosted sessions.
• The server sends no webhooks. A webhook-triggered worker will never start through that path; keep workers polling and use the session event stream for progress.
• The server rejects mcp_oauth vault credentials. If using the documented static_bearer alternative, assign an owner to refresh the token before expiry.
• MCP and Git hosts need server allowlist entries. Review worker egress separately; adding a server integration is not proof of sandbox isolation.

Check retained data as part of that migration. Prompts and tool results go to the inference provider. Sessions remain in your database until deletion, and deletion does not purge backups, exported telemetry, or memory-store copies. Data and retention scope.

Kubernetes workspace cleanup has another step: archive the session and verify that its workspace volume is gone before deleting the session. Anthropic's volume cleanup procedure explains why deleting the session first can leave its volume behind.

Require evidence for the boundary you intend to enforce#

Use an isolated pilot with synthetic data. These are recommended acceptance checks, not results from a General Analysis deployment.

Keep the release archive version and effective settings with those records. If the incident deployment still accepts build identities, or a sandbox holds an environment-wide key, resolve that boundary before connecting production systems.