Claude Managed Agents: Who Secures What Anthropic launched Claude Managed Agents in beta on April 8, 2026, a hosted agent harness in which Anthropic runs the agent loop and executes tools in a fresh Linux container per session, with no shared filesystem state between sessions. Anthropic's own risks documentation states that the platform's settings "do not secure your custom tools, your MCP servers, or your self-hosted infrastructure," while vaults keep credentials outside the sandbox as opaque placeholders substituted with the real secret only at egress. The API is exposed through the /v1/agents, /v1/environments and /v1/sessions resources behind the managed-agents-2026-04-01 beta header and is enabled by default for all API accounts on the Claude API, Claude Platform on AWS and Claude Models on Google Cloud. Anthropic launched Claude Managed Agents in beta on April 8, 2026. You’ll also see it called Anthropic Managed Agents: an API where Anthropic runs the agent for you, so you don’t build the loop, the tool runner or the container yourself. Claude Managed Agents is Anthropic’s hosted agent harness. You define an agent a model, a system prompt, tools and MCP servers and an environment, then start sessions through the API. Anthropic runs the agent loop and keeps each session’s history, and the tools run in a fresh container per session, or on a worker you operate if you use self-hosted sandboxes. Security teams keep asking us what they still own once Anthropic runs the sandbox. Anthropic answers on its own risks page https://platform.claude.com/docs/en/managed-agents/secure-deployment-risks : “The settings do not secure your custom tools, your MCP servers, or your self-hosted infrastructure.” This post goes through what the platform does secure, what it leaves to you, and what we saw when we ran a few probes of the defaults against the API ourselves. Every Anthropic fact comes from its docs as we read them on November 9, 2026. It’s a beta, so check them again. We build Formal, and the second-to-last section is where we’d put it: we haven’t tested that part with Managed Agents yet, and the section says so. What is Claude Managed Agents? Claude Managed Agents gives you four objects to work with. An agent is “the model, system prompt, tools, MCP servers, and skills”. An environment says where sessions run: “an Anthropic-managed cloud sandbox, or a self-hosted sandbox on your own infrastructure”. A session is one running instance of the agent doing one task, and events are the messages between your application and the agent, which Anthropic stores: “Event history is persisted server-side and can be fetched in full.” overview https://platform.claude.com/docs/en/managed-agents/overview The Claude Managed Agents API is three resource families, /v1/agents , /v1/environments and /v1/sessions , behind the managed-agents-2026-04-01 beta header. Access is “enabled by default for all API accounts” on the Claude API, Claude Platform on AWS and Claude Models on Google Cloud, and out of the box the agent gets bash, file tools, web search and fetch, plus whatever MCP servers you declare. Anthropic’s engineering post https://www.anthropic.com/research/managed-agents on the design calls the split “Decoupling the brain from the hands”: the model and its loop run on Anthropic’s side, and the hands, the code that touches files and the network, run in the sandbox. What runs where Three things in that picture matter for everything below. The MCP connector calls your MCP servers from Anthropic’s side; the sandbox never opens those connections. The web tools also run on Anthropic’s servers. And the only part that moves when you switch to a self-hosted sandbox is the sandbox itself. What Anthropic secures in Managed Agents Start with the parts that are real controls, because there are several. Each session gets “a fresh Linux container”, and “Sessions do not share filesystem state” environments https://platform.claude.com/docs/en/managed-agents/environments . Credentials don’t live in that container either. The risks page says Managed Agents “keeps the agent loop, session history, and vault secrets outside the sandbox by design”, and MCP credentials never enter it. For a credential your code needs as an environment variable, vaults https://platform.claude.com/docs/en/managed-agents/vaults store it “in the sandbox as an opaque placeholder”, substituted “with the real secret at egress. The agent never sees the secret value.” Anthropic’s engineering post describes the reasoning: “The structural fix was to make sure the tokens are never reachable from the sandbox where Claude’s generated code runs.” Egress has a real allowlist. An environment with limited networking can reach only the hosts in allowed hosts , and the docs say a blocked request gets “a 403 that names the blocked host”. In our test, curl reported a DNS failure instead what we saw what-we-saw-when-we-tried-it . The same list applies to web search and web fetch , even though they run on Anthropic’s servers. MCP servers get checked too: while allow mcp servers is false , “session creation fails with a 400 error if the agent declares an MCP server whose host is not in allowed hosts ”. Then there are permission policies https://platform.claude.com/docs/en/managed-agents/permission-policies , which decide whether a tool call runs on its own, waits for a person, or gets judged by the server: always allow , always ask and auto . MCP tools start on always ask . The MCP connector https://platform.claude.com/docs/en/managed-agents/mcp-connector also lets you turn off every tool on a server and enable only the ones you name, which Anthropic suggests for “when you want tools added by the server operator to stay off until you review them”. Each tool-use event records the decision in evaluated permission . Who is responsible for the sandbox depends on where it runs: “Anthropic, with a cloud environment, or you, with a self-hosted sandbox” secure deployment https://platform.claude.com/docs/en/managed-agents/secure-deployment . Where Anthropic says its controls stop Anthropic’s own wording is the clearest summary of what stays on you. From the risks page: “do not put data in the sandbox that must never leave it.” “Limit a key’s permissions at the service that issued it, because these settings do not limit them.” “These limits do not replace each other. For example, limiting the environment’s hosts does not stop the agent from using a credential on a host you allowed.” And on prompt injection: “Claude is inherently resilient to it, but model behavior is not a security control.” | Area | Anthropic provides | Stays on you | |---|---|---| | Sandbox | A fresh container per session | What you put in it; anything in it can leave | | Egress | limited networking with allowed hosts | Setting it explicitly; what an allowed host accepts | | Credentials | Vaults, placeholders swapped at egress | Each key’s scope, set at the service that issued it | | MCP servers | Connections from Anthropic’s side, the host check, always ask | The server, its auth, what its token can reach | | Tool approval | Permission policies, per-tool enable | A person who actually reviews; your custom tools | | Identity | API keys per workspace | Who started a session, and how a service would know | | Logs | Event history until you delete it | Exporting it; anything at the network level | Defaults to change Three defaults decide how much of the above you actually get. First, networking: “Set networking explicitly in API requests; a create request that omits it gets unrestricted .” The Console’s form starts on Limited , so an environment made by hand and one made by a script can end up with different egress. Our first probe got unrestricted from exactly that omission. unrestricted means “Full outbound network access, except for a general safety blocklist”, and Anthropic adds that “The safety blocklist is not an allowlist.” Second, tool approval. “The agent toolset enables all eight built-in tools by default”, and “the agent toolset defaults to always allow , and MCP toolsets default to always ask .” So bash runs without anyone looking, while an MCP call waits. Moving bash to auto doesn’t put a person back in the loop either: “ auto is not a human checkpoint.” Neither does a client that approves everything automatically, since “A client that allows every call without showing it to a person is the same as always allow .” Third, custom tools, which your application runs itself, sit outside all of this: they “are not governed by permission policies.” Granted by host The allowlist works on hostnames. Anthropic is direct about what that leaves open: “Network access is granted by host, not by operation. The sandbox can send any request to an allowed host, including uploads such as git push and package publishing, with any credential the command supplies.” Allow github.com so the agent can clone, and it can push too. The Claude Code sandbox’s domain list has the same limit. Checking what a request does, and not only where it goes, takes egress filtering https://www.formal.ai/academy/egress-filtering/ at layer 7. Vaults are workspace-scoped Vault credentials have a scope of their own: “Vaults and credentials are workspace-scoped, meaning any API key with workspace access can reference them when creating a session.” A key that can create sessions in a workspace can attach any vault in it. The placeholder trick also has two edges. “Substitution is outbound only”: if a client trades the stored secret for a session token, the token that comes back “arrives in the sandbox unredacted.” And the secret stays out of the model’s reach “unless a service sends it back, such as an endpoint that echoes request headers.” We reproduced that one below with a single request. A credential sent to a host outside the credential’s own allowed hosts goes out as the literal placeholder, which is safe but breaks the call. What we saw when we tried it On November 9, 2026 we ran five small probes against the API with Claude Haiku 4.5 claude-haiku-4-5-20251001 in cloud environments, each session capped by a 25-cent budget. Afterwards we deleted the sessions, environments and vault, and archived the agents, which have no delete endpoint. An environment created with only {"type": "cloud"} came back unrestricted, as the docs say: "networking": {"type": "unrestricted"} The blocked host behaved differently from the docs. In a limited environment that allowed example.com and httpbin.org , bash ran curl -sS -i https://www.wikipedia.org/ , then fetched https://example.com/ and printed its status code: curl: 6 Could not resolve host: www.wikipedia.org --- example.com allowed : 200 The allowed host answered. The blocked one failed at name resolution, so curl never sent a request, and we saw no 403 naming the host. We only tried curl, so we can’t say which clients get the 403 the docs describe. If you alert on blocked egress, test for both. The MCP host check worked as documented. An agent that declared https://mcp.linear.app/mcp , in an environment with allow mcp servers left false , couldn’t start a session. The API returned a 400 before any sandbox existed: {"type": "invalid request error", "message": "MCP server host s blocked by environment network policy: \"linear\" mcp.linear.app . Add these hosts to the environment's allowed hosts, or set allow mcp servers=true."} The placeholder held until a service sent the secret back. We stored a random dummy value as an environment-variable credential, DEMO TOKEN , limited to httpbin.org with header injection. echo printed the placeholder, and a request to httpbin’s /headers endpoint, which returns the request headers it received, came back with the real value: DEMO TOKEN in the sandbox: ANTHROPIC SECRET PLACEHOLDER eef240a6... --- { "headers": { "Accept": " / ", "Authorization": "Bearer REDACTED ", "Host": "httpbin.org", "User-Agent": "curl/8.5.0" } } That response is a tool result, so the model read the secret. It’s the case Anthropic’s docs warn about, and it took one curl to an allowed host. The value was a throwaway; we redacted it here anyway. The two sessions that ran were active for 3.6 and 3.2 seconds, and Anthropic reported a list cost of 1 cent and 0 cents. At $0.08 per session-hour, runtime was about a hundredth of a cent each, so nearly all of it was tokens. Two sessions that short say nothing about what a real workload costs. Can Claude Managed Agents call your own MCP servers? Yes. Claude Managed Agents connects to any remote MCP server you declare by name and URL on the agent, up to 20 per agent, each URL “up to 2,048 characters”. The connection doesn’t come from the sandbox: Anthropic’s MCP connector makes it, and supplies the credential from a vault whose mcp server url matches the server’s URL. If none matches, “the connection is attempted unauthenticated.” A vault credential for an MCP server is one of two types. mcp oauth holds OAuth tokens, and “If you supply a refresh block, Anthropic refreshes the access token on your behalf.” static bearer holds a fixed bearer token https://www.formal.ai/academy/bearer-token/ . We didn’t find a way to send any other header to an MCP server. One detail we haven’t seen anywhere else: “Session creation does not validate MCP connectivity or credentials.” A bad token doesn’t stop the session from starting. It shows up later as a session.error event with mcp authentication failed error , so a monitor that only checks whether sessions start will miss it. For servers inside your network, Anthropic offers MCP tunnels https://platform.claude.com/docs/en/agents-and-tools/mcp-tunnels/overview , in research preview, which Anthropic provides “as-is” without any uptime, support, or continuity commitment. You run Cloudflare’s cloudflared and Anthropic’s proxy inside your network over an outbound-only connection, so nothing listens on an inbound port. The tunnel “carries encrypted traffic to your MCP server but does not authenticate to it”, which leaves OAuth on each server and network limits on the proxy to you. What the agent can do through a server is decided by the token the server holds. That was the lesson of the GitHub MCP case in the permission pitfall of MCP https://www.formal.ai/blog/permission-pitfall-mcp/ , and Managed Agents doesn’t change it: the per-tool switches decide which tools Claude may call, and the token behind them still decides what each call can do. Putting an MCP gateway https://www.formal.ai/use-cases/mcp-gateway/ at that URL is the setup we cover in the Formal section below. Cloud sandbox vs self-hosted sandboxes In the cloud sandbox, egress control is the host allowlist and nothing else. We found no documented way to send the cloud sandbox’s traffic through a proxy of your own, add a CA, or peer it with your VPC. Self-hosted sandboxes https://platform.claude.com/docs/en/managed-agents/self-hosted-sandboxes “move the agent’s tool execution from Anthropic-managed cloud sandboxes into infrastructure you control, while Anthropic keeps running the agent.” “The worker needs only outbound HTTPS”, and “Tool inputs and outputs still flow to Managed Agents on Anthropic’s side.” The network is then yours: “Your sandbox’s network access is determined by your VPC and firewall rules”, and “Anthropic’s security boundary stops at the sandbox” self-hosted security model https://platform.claude.com/docs/en/managed-agents/self-hosted-sandboxes-security . Your firewall still doesn’t see everything. The secure deployment page notes that “Your firewall does not limit the MCP servers an agent declares” and “The web tools run on Anthropic’s servers, so your firewall does not limit them.” Vault placeholders don’t come along yet: environment-variable credentials “are not yet supported with self-hosted sandboxes.” Anthropic’s suggestion is the pattern we’d use anyway: “you can run your own proxy that replaces placeholder values with the real secrets at egress.” Anthropic’s comparison of the two https://platform.claude.com/docs/en/managed-agents/choosing-an-environment , with the credential and MCP rows added from the pages above: | | Cloud sandbox | Self-hosted sandbox | |---|---|---| | Tools run on | A container Anthropic runs | Your worker | | Reaches Anthropic | Conversation history, tool results, the sandbox’s files and state, skills, memory | The same, minus the sandbox’s files and processes | | You operate | Nothing | Worker hosts, their hardening and network limits, the environment key | | Network reach | Rules you set on the environment | Your own network policy | | Environment-variable credentials | Placeholder replaced at egress | Not supported yet; run your own proxy | | MCP servers and web tools | Called from Anthropic’s side | Still called from Anthropic’s side | “Neither option changes the compliance coverage of Managed Agents or how long it keeps conversation history.” Self-hosting keeps files and processes on your machines; it doesn’t keep the conversation off Anthropic’s. Who started this session? A service that a managed agent calls sees the credential from the vault or the key in the request, and nothing that names the session or the person who launched it. We didn’t find a per-session identity token in the Claude Managed Agents docs. So a database or an API can’t tell one session from another, or tie a request to an engineer, unless your application passes that along itself. That’s the part that changes the design for us. Cursor and Devin sign a short-lived OIDC token for every session, which is what let us tie cloud agent access to the session and the person who started it in Giving Cloud Agents Production Access with OIDC https://www.formal.ai/blog/cloud-agents-oidc-infrastructure/ . Without a token like that, AI agent identity https://www.formal.ai/academy/ai-agent-identity/ for a managed agent lives in your own application: it knows which user triggered which session, and the event history records what the session did. For data access, that argues for read-only credentials scoped at the issuing service, and against anything that depends on knowing which session is asking. What gets logged, and for how long? The event history is the main record, and Anthropic keeps it until you remove it. From the monitoring page https://platform.claude.com/docs/en/managed-agents/secure-deployment-monitoring : “Session history: Kept until you delete the session.” “To keep a session’s events, copy them to your own logs with the events API before you delete it.” “Sandbox state: Kept for 30 days after the sandbox is created.” Webhooks help, but “A webhook delivery can be missed, so also list your sessions on a schedule and check the idle ones.” OpenTelemetry https://platform.claude.com/docs/en/manage-claude/opentelemetry export, in beta, traces Managed Agents sessions, with a warning that applies to any audit use: “Exported spans aren’t guaranteed to be a complete record of your API usage.” What we didn’t find: a log of the network requests the sandbox makes, and Managed Agents sessions in the Compliance API’s coverage, whose session endpoints cover Claude Enterprise apps such as Cowork. If you need to know which hosts an agent contacted and what it sent, that record has to come from something on the network path. How we’d wire Formal in untested We haven’t run a Managed Agents session against a Formal Connector yet. What follows is the setup we’d test first, built from what Anthropic documents and what our own docs say the Connector does today. The table at the end marks which parts are documented and which are untested with Managed Agents. MCP servers behind the MCP gateway The agent’s MCP server URL would be the server’s Connector address, https://