Self-Hosting an AI Agent Moves the Boundary, Not the Model Call

A company can keep an agent’s shell inside its own network and still send a prompt containing source code, a customer record or a retrieved document to a hosted model. “Self-hosted” is only useful if the diagram shows exactly which part is local. Anthropic’s new private beta for self-hosted Managed Agents moves more of the agent control plane into the customer’s environment, while leaving the model call as a separate data-flow decision.

Managed Agents is a suite of APIs for long-running agents. In the hosted arrangement, the provider operates the service, sandboxes and session history. An earlier self-hosted-sandbox option moved tool execution to customer infrastructure while the service remained hosted. The November 12 private beta extends the deployment boundary: customers run the API, agent loop and storage for agents and sessions as well as the sandboxes. ^{[1] [2]}

Map the system by component

Anthropic’s documentation divides a self-hosted deployment into a server, database and workers. The server exposes the API, manages the agent loop and stores agent definitions, sessions and history. It does not run shell or file tools directly. Worker programs accept work from the server and execute those tools in sandboxes. The database requirement is PostgreSQL 16 or later; without a database, the service keeps state in memory and a restart erases it. ^[2]

The model is a separate component. The documentation lists Anthropic or selected providers such as Amazon Bedrock, Google’s Agent Platform, Microsoft Foundry or an organization’s own gateway. That flexibility can help satisfy provider and routing needs, but it does not erase the data sent in an inference request. If an agent reads an internal source file and asks a hosted model to reason about it, the relevant file contents may leave the environment even when its shell and session database stay local. ^{[1] [2]}

This is why “inside our perimeter” needs a data-flow diagram, not just a deployment label. List where tool calls execute, where credentials are stored, where session transcripts persist, which network path reaches the model provider, what telemetry is retained and what gets placed in each prompt. Classify data by policy and verify that the chosen inference route is allowed to receive it.

Control brings operational ownership

Running the control plane locally creates obligations. The organization must patch and secure the server, PostgreSQL, workers and sandbox images; protect signing keys and provider credentials; constrain network egress; back up state; monitor queues; and install each release. The vendor warns that some features differ from the hosted service, so teams must review the current comparison before committing to a migration. ^[2]

Isolation is especially important because an agent can execute commands and read files. A worker should receive only the tools and data needed for its task. Sandbox boundaries should prevent an agent from reaching unrelated hosts or credentials. Session history deserves access controls and retention policies because it may contain sensitive snippets even when the original system of record remains untouched.

The managed API can reduce the amount of orchestration code a team writes, but self-hosting does not remove the need to inspect the agent’s authority. Define which tools can mutate state, where approvals are required and how an operator stops a long-running session. Treat upgrades as behavior changes: test that permissions, state migration and worker compatibility still match the deployment’s assumptions.

Choosing the right boundary

If the primary requirement is to run commands near internal systems, while hosted session storage is acceptable, self-hosted sandboxes may provide a smaller operational step. If policy requires the service API, agent loop and session history to reside in the organization’s environment, the full self-hosted option addresses more of that requirement. If prompts themselves cannot be sent to any hosted model, moving the control plane is insufficient; the team needs an approved inference path that satisfies the restriction. ^[2]

Before a pilot, inventory every data class the agent may read, every tool it may call and every provider that may receive inference payloads. Start with a low-risk task, use synthetic or approved data, and test the denied paths as carefully as the successful ones. Track the exact beta version, API behavior, database backup and restoration procedure, worker permissions and feature gaps.

Self-hosting changes who operates the agent’s runtime and where its durable state lives. That can be an important control for regulated or highly sensitive workflows. It is not a synonym for local inference, automatic compliance or safe autonomy. The architecture becomes easier to reason about when each boundary is named—and when teams verify what crosses it during a real session. Our guide to setting access boundaries for personal agents looks at the authorization side of that same deployment problem.