Select Page

Self-Hosted Claude Managed Agents: Data Control and Limits

by | Nov 15, 2026 | AI

Conceptual illustration of enterprise servers and an agent dashboard connected to an external AI model service

Anthropic has introduced self-hosted Claude Managed Agents, a private beta that lets organisations run the infrastructure around Claude agents in their own cloud or data centre. Announced on 12 November 2026, it gives enterprise teams more control over credentials, session records and internal integrations.

The crucial distinction is that hosting the agent service is not the same as hosting the Claude model. Model requests still go to Anthropic or another configured inference provider. That boundary matters more than the self-hosting label.

Background: what Claude Managed Agents actually manages

An AI agent needs more than a model answering prompts. It needs a loop that decides what happens next, tools that perform actions, somewhere for code to run, and a record of previous steps. Managed Agents packages those components behind APIs.

Anthropic previously offered the hosted service and an option for customers to operate their own sandboxes: the isolated workspaces where tools execute commands and handle files. That earlier option moved tool execution in-house, but left the surrounding service with Anthropic.

The new beta extends customer control to the service itself. It is aimed at teams whose requirements cover stored conversations and agent administration, not just where a command executes.

What changed with self-hosted Claude Managed Agents?

Customers can now operate the agent server, its database and the workers that execute shell and file tools. Agents, sessions and session history can live in the customer’s database. Developers use the same core Managed Agents APIs, although feature differences remain.

Model requests can be routed to Anthropic directly, supported cloud providers including Amazon Bedrock, Google Cloud and Microsoft Foundry, or a configured model gateway. Access is currently by private beta through an Anthropic account team, rather than an unrestricted public download.

What stays local, and what does not?

The official documentation says each model call sends the conversation so far, including tool inputs and results, to the chosen inference provider. A file can remain on a local worker while an extract from it appears in a tool response sent for inference.

Consequently, this is not an announcement of downloadable Claude weights or offline Claude inference. Choosing a gateway changes routing; it does not, by itself, make the underlying model local.

Why it matters for businesses and developers

For organisations building agents around private repositories or internal services, controlling the agent platform can simplify integration with existing identity, secrets and monitoring systems. It also allows teams to govern their own stored session history rather than relying on a provider-hosted transcript store.

For Australian businesses assessing AI data sovereignty, this distinction is useful but not a compliance guarantee. Keeping a database in Australia does not establish where inference occurs or what a cloud provider retains. Procurement teams should separately check processing regions, contractual terms and every external integration.

Three deployment choices, not one

  • Fully hosted: Anthropic operates the service and sandboxes.
  • Self-hosted sandboxes: your tools run on your infrastructure, while Anthropic operates the agent service.
  • Self-hosted Managed Agents: you operate both the service and sandboxes, with model calls routed to your chosen provider.

If only tool execution needs to stay in-house, the sandbox option may be sufficient. Hosting the whole service adds responsibilities that should solve a specific business requirement.

Security controls: useful architecture, not automatic safety

Anthropic separates the agent loop from the environment running agent-generated code. For MCP tools and supported API calls, a proxy can attach credentials outside the sandbox. Self-hosted deployments can also integrate a customer-controlled secrets manager.

However, protecting a credential’s value does not eliminate misuse of its permissions. An agent with access to a powerful authenticated tool can still request harmful actions. Least-privilege permissions, approval gates and narrow tool definitions remain important.

Network restrictions are also an operator responsibility. Self-hosted workers inherit the access allowed by their container or virtual machine, so teams must configure their own isolation and firewall rules. Session records support investigations, and OpenTelemetry can export observability data when configured.

Practical impact: how to evaluate the beta

A sensible pilot would start with a bounded workflow, such as investigating failed builds and proposing a fix without permission to deploy it. Measure whether the agent completes useful work, how often humans intervene, and what sensitive information reaches the model.

  • Map data flows between workers, the server, the database and inference providers.
  • Use disposable sandboxes, restricted service accounts and narrowly allowed network destinations.
  • Test approvals, emergency shutdown and recovery from interrupted sessions.
  • Budget for hosting, model usage, maintenance and operational support.

Do not assume a previous hosted deployment transfers automatically. Anthropic says agents, skills, vault credentials and memory stores must be created again; hosted session history is not copied.

Risks and limitations to understand

The self-hosted server is not feature-identical to the hosted service. Current documentation lists missing webhooks and scheduled deployments, while some tool and provider capabilities behave differently. Existing applications need a compatibility review before migration.

Self-hosting also transfers patching, database protection and monitoring to the customer. Anthropic warns that the worker’s shell has real permissions: the worker alone is not a security boundary. Different tenants or trust levels require separate deployments, not merely separate environments inside one deployment.

Retention needs explicit planning. Session history remains in your database until deleted, and deleting a session does not erase copies in backups or exported logs. An existing zero-data-retention agreement can cover Claude API model calls, but self-hosting does not automatically provide that agreement or delete local records.

What to watch next

Watch for broader beta access, changes to the hosted-versus-self-hosted feature list, and clearer operational evidence from production deployments. Teams should also verify model and regional support with their chosen inference provider rather than assuming every combination works.

Conclusion

Self-hosted Claude Managed Agents gives enterprises a meaningful new deployment option: control the agent infrastructure without building the whole platform themselves. The trade-off is equally clear. Your team gains control of more systems and becomes responsible for securing them, while the model-processing boundary still requires careful review.

Sources