What happened
Anthropic’s documentation describes the data and access model for self-hosted Claude Managed Agents, a deployment in which the customer runs the server, its database and the sandboxes where workers execute shell and file tools. The server’s inference provider handles model calls. Anthropic says it has no remote access to the self-hosted server or its log. The default inference provider is the Claude API; an operator can configure another provider, in which case model calls go there instead.
The server’s outbound connections are limited to configured destinations: the inference provider, database, credential-issuing services, allowed MCP servers and Git hosts, and optional identity, telemetry, secret-management and other services. Web search and fetch are off until enabled in server settings; when the inference provider offers those tools, that provider runs them rather than the server making its own connection. Workers are a separate boundary: each worker can reach whatever the operator permits in its container, VM or other sandbox, and commands run through that worker have the same network access.
Each model call carries the conversation so far, including prompts, tool inputs and tool results. When Claude API is used, calls also carry up to three server-generated session, agent and environment IDs in headers; Anthropic says the IDs contain no name or content, but encode creation time and allow usage attribution. Those headers cannot be disabled. The API key identifies the organization, while request metadata and a User-Agent can identify usage of the self-hosted server. Certain inference routes also carry the cma-server label in metadata.user_id; a proxy that rejects that field causes model calls to fail.
The server writes logs to standard error. It creates no traces or metrics until configured through OpenTelemetry environment variables, and sends them only to the configured destination. Agents, sessions and session history are stored in the configured database; with no database, the default is in-memory storage and restart erases the data. Sessions remain until deleted. Deletion removes the session and history from the database, but does not remove backups, exported logs and traces, memory-store copies or, on Kubernetes, the session workspace volume. Provider agreements govern model-call data retention; Anthropic says an organization’s existing data-retention agreement and settings apply to Claude API calls.
The deployment serves one tenant at one trust level. Environments in a deployment do not isolate trust levels, and the server API key reaches every environment. Anthropic recommends separate deployments, databases, API keys and workers for different tenants or trust levels. The default API listener is at 127.0.0.1:8400; the console is served on the same address and port, while the optional Prometheus endpoint and egress-gateway listener have their own exposure considerations.
What the archive adds
New Runtime’s earlier coverage on 2026-11-12 described the private beta and the ability to run agents, credentials and session history inside a company’s cloud or on-premises environment (Operate Claude Managed Agents inside your security perimeter). This is a new fact on a known story: Anthropic’s documentation now spells out the network, retention, identity and tenant-isolation boundaries.
Trend signal
This supports the view that agent security depends on the runtime boundary, not only on instructions given to a model. The documentation makes sandbox network access, credential handling, session storage and deployment isolation operator decisions (Agent security moves to runtime boundaries).
Why now
The private-beta deployment option makes the operational boundary consequential for teams evaluating whether self-hosting meets their security requirements. Anthropic’s documentation gives security reviewers specific destinations, retention behavior and listener defaults to check before deployment.
Why it matters
Self-hosting is not the same as keeping all data away from external systems. Model requests still carry the conversation to the chosen inference provider, and workers can access whatever their sandbox permits. Teams therefore need to evaluate the full path: what enters prompts and tool results, which provider receives it, what credentials are available to worker code, and where logs, traces, backups and workspaces persist.
The single-tenant and single-trust-level model also affects architecture. A shared deployment is not a substitute for isolating tenants or workloads with different trust levels; separate deployments are the documented approach. That creates operational cost, but makes the security boundary explicit. For builders, the useful question is not merely whether the server runs in their cloud, but whether every downstream connection and stored copy fits their threat model.
Limits and uncertainty
The documentation describes intended product behavior, not an independent security assessment or a guarantee about a particular customer deployment. It does not establish that every operator will configure network policies, proxies, identity providers, backups and sandboxes correctly. Provider data-retention terms remain specific to the organization’s agreement, and configured gateways or proxies may receive request metadata. Teams should validate actual traffic and deployment configuration, especially optional listeners and worker egress, rather than treating self-hosting alone as proof of isolation.
Skill to build now
Before enabling agent workloads, draw a data-flow map from session input through tool results, model provider, database, logs, telemetry and backups. Then compare the server’s observed egress against Anthropic’s documented destination list, and test that each worker sandbox can reach only the hosts it needs. Separate deployments by tenant or trust level, and verify deletion behavior across database backups and Kubernetes volumes.
Reader takeaway
Self-hosted Managed Agents moves the server and session store into the customer’s environment, but it does not erase provider, worker-network or backup boundaries. Treat isolation as a deployment design problem: separate trust domains, constrain worker egress and account for every copy of session data.