{"slug": "claude-managed-agents-who-secures-what", "title": "Claude Managed Agents: Who Secures What", "summary": "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.", "body_md": "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.\n\nClaude 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.\n\nSecurity 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.”\n\nThis 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.\n\n## What is Claude Managed Agents?\n\nClaude 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))\n\nThe 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.\n\n### What runs where\n\nThree 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.\n\n## What Anthropic secures in Managed Agents\n\nStart with the parts that are real controls, because there are several.\n\nEach 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.”\n\nEgress 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`”.\n\nThen 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`.\n\nWho 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)).\n\n## Where Anthropic says its controls stop\n\nAnthropic’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.”\n\n| Area | Anthropic provides | Stays on you | \n|---|---|---|\n| Sandbox | A fresh container per session | What you put in it; anything in it can leave | \n| Egress | `limited` networking with`allowed_hosts` | Setting it explicitly; what an allowed host accepts | \n| Credentials | Vaults, placeholders swapped at egress | Each key’s scope, set at the service that issued it | \n| MCP servers | Connections from Anthropic’s side, the host check, `always_ask` | The server, its auth, what its token can reach | \n| Tool approval | Permission policies, per-tool enable | A person who actually reviews; your custom tools | \n| Identity | API keys per workspace | Who started a session, and how a service would know | \n| Logs | Event history until you delete it | Exporting it; anything at the network level | \n\n### Defaults to change\n\nThree 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.”\n\nSecond, 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`.”\n\nThird, custom tools, which your application runs itself, sit outside all of this: they “are not governed by permission policies.”\n\n### Granted by host\n\nThe 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.\n\n### Vaults are workspace-scoped\n\nVault 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.\n\nThe 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.\n\n### What we saw when we tried it\n\nOn 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.\n\nAn environment created with only `{\"type\": \"cloud\"}` came back unrestricted, as the docs say:\n\n```\n\"networking\": {\"type\": \"unrestricted\"}\n```\n\nThe 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:\n\n```\ncurl: (6) Could not resolve host: www.wikipedia.org\n---\nexample.com (allowed): 200\n```\n\nThe 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.\n\nThe 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:\n\n```\n{\"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.\"}\n```\n\nThe 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:\n\n```\nDEMO_TOKEN in the sandbox: ANTHROPIC_SECRET_PLACEHOLDER_eef240a6...\n---\n{\n  \"headers\": {\n    \"Accept\": \"*/*\",\n    \"Authorization\": \"Bearer [REDACTED]\",\n    \"Host\": \"httpbin.org\",\n    \"User-Agent\": \"curl/8.5.0\"\n  }\n}\n```\n\nThat 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.\n\nThe 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.\n\n## Can Claude Managed Agents call your own MCP servers?\n\nYes. 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.”\n\nA 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.\n\nOne 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.\n\nFor 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.\n\nWhat 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.\n\n## Cloud sandbox vs self-hosted sandboxes\n\nIn 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.\n\n[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.”\n\nVault 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.”\n\nAnthropic’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:\n\n|  | Cloud sandbox | Self-hosted sandbox | \n|---|---|---|\n| Tools run on | A container Anthropic runs | Your worker | \n| Reaches Anthropic | Conversation history, tool results, the sandbox’s files and state, skills, memory | The same, minus the sandbox’s files and processes | \n| You operate | Nothing | Worker hosts, their hardening and network limits, the environment key | \n| Network reach | Rules you set on the environment | Your own network policy | \n| Environment-variable credentials | Placeholder replaced at egress | Not supported yet; run your own proxy | \n| MCP servers and web tools | Called from Anthropic’s side | Still called from Anthropic’s side | \n\n“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.\n\n## Who started this session?\n\nA 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.\n\nThat’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.\n\n## What gets logged, and for how long?\n\nThe 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.”\n\n[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.”\n\nWhat 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.\n\n## How we’d wire Formal in (untested)\n\nWe 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.\n\n### MCP servers behind the MCP gateway\n\nThe agent’s MCP server URL would be the server’s Connector address, `https://<server-name>.<connector-hostname>/<mcp-path>`, from the [MCP gateway docs](https://docs.formal.ai/docs/guides/core-concepts/connectors/mcp-gateway). For MCP clients that call from their vendor’s cloud, those docs already cover the network side: “Claude and ChatGPT call MCP servers from Anthropic’s and OpenAI’s clouds. To use them, expose the Connector’s listener to the internet”, and if you restrict inbound traffic, allow the IP ranges Anthropic publishes. Anthropic lists its outbound ranges, used “when making MCP tool calls to external servers”, on its [IP addresses page](https://platform.claude.com/docs/en/api/ip-addresses).\n\nBehind that address, the [Connector](https://www.formal.ai/products/pam/) holds the upstream credential as a linked account or a Native User (“Users never see the token”), so the Linear or Notion token stays out of Anthropic’s workspace-scoped vault. An allowlist of tools per server becomes a policy, and the Connector “blocks `tools/call` requests for tools outside the list”. Custom Rego “can read each call’s tool name and parameters”, and “Tool calls appear in Logs with the user, server, and tool name.” Anthropic’s per-tool switches already cover the first part. What a gateway adds is the token held outside the vault, rules on parameters, and one log across every MCP client you use.\n\nThe open question is sign-in. Our gateway accepts Formal OAuth or identity headers, and “Only active human users can approve an MCP client. Machine users authenticate with identity headers instead.” As far as we found, Managed Agents can’t send custom headers to an MCP server, which leaves one candidate: a person approves a pre-registered client through Formal OAuth, and the access and refresh tokens go into an `mcp_oauth` vault credential. If that works, every call is attributed to the person who approved it. The session itself stays invisible to the gateway.\n\n### API calls from the cloud sandbox\n\nFor APIs, the sandbox would call the Connector instead of the service: put the Connector’s hostname in `allowed_hosts` and call an [HTTP resource](https://docs.formal.ai/docs/guides/core-concepts/resources/http) at `https://<resource-name>.<connector-hostname>`. A Native User injects the API key, which the HTTP client “does not have access to”, and request policies act on the method and path. That is the operation-level check the host allowlist doesn’t make.\n\nUntested: how the sandbox proves who it is to the Connector. The obvious candidate is a Formal machine user’s identity headers stored as an environment-variable credential and swapped in at egress. The trade-off is that one Formal credential then sits in Anthropic’s vault instead of each upstream key, but it’s limited by policy and every request it makes is logged.\n\n### Self-hosted sandboxes with Formal Endpoint\n\nA self-hosted worker is closest to what we already run. Our guide to [keeping API keys out of cloud agent sandboxes](https://docs.formal.ai/docs/guides/example-use-cases/cloud-agent-credential-forwarding) covers Cursor and Devin, part of how we approach [AI coding agent security](https://www.formal.ai/use-cases/ai-coding-agent-security/): the Endpoint in the sandbox forwards selected traffic to a Connector that injects the key, “The agent keeps calling the real API hostname”, and “Every request is logged with the agent and the human who started it.” On a worker, [Formal Endpoint](https://www.formal.ai/products/endpoint/) would run as the [headless Linux package](https://docs.formal.ai/docs/guides/client-apps/linux) or as a Kubernetes or ECS sidecar, and sign in with [OIDC](https://docs.formal.ai/docs/guides/integrations/oidc) from the infrastructure it runs on. That’s the kind of egress proxy Anthropic suggests for secrets on self-hosted workers.\n\nThe limit is the one in the diagram: the Endpoint on the worker doesn’t see MCP calls or web tools, because they leave from Anthropic’s side. We haven’t run this with Anthropic’s worker.\n\n| Gap Anthropic names | How we’d wire it | Status | \n|---|---|---|\n| MCP servers are yours to secure | Connector address as the MCP URL; token on the Connector; tool list and Rego; logs | Gateway for cloud MCP clients: documented. With Managed Agents: **untested** | \n| How the agent signs in to the gateway | Formal OAuth tokens in an `mcp_oauth` credential | **Untested** , and documented by neither side | \n| Network access granted by host | Connector hostname in `allowed_hosts` ; HTTP resource policies; Native User | Connector policies: documented. Sandbox sign-in: **untested** | \n| A proxy for secrets on self-hosted workers | Endpoint on the worker, key injected by the Connector | Documented for Cursor and Devin. With Anthropic’s worker: **untested** | \n| Data the agent can reach | Connector in front of databases and APIs: masking, blocking | Documented. Approval per session needs a session token we didn’t find | \n| Logs you keep | Connector logs, forwarded with a [log integration](https://docs.formal.ai/docs/guides/integrations/log) to your SIEM | Documented, for traffic through the Connector only | \n\n## What we’d set up today\n\nNone of this needs Formal. With Claude Managed Agents as documented, we’d start with:\n\n- `networking` set to`limited` in every create request, a short`allowed_hosts` , and`allow_mcp_servers` left at`false` .\n- MCP toolsets with every tool off by default and the needed ones enabled by name, on `always_ask` for anything that writes.\n- `bash` on`always_ask` for sessions that read untrusted input, such as tickets, emails or web pages.\n- Each environment-variable credential’s `allowed_hosts` kept to the API it belongs to. Any allowed endpoint that reflects request headers hands the real value to the model, as our probe showed.\n- Keys limited at the service that issued them, and separate workspaces for credentials with different blast radius. That last one is our reading of vault scope; Anthropic doesn’t recommend it.\n- Events copied to your own storage before a session is deleted, and sessions listed on a schedule rather than trusting webhooks alone.\n- Self-hosted sandboxes when files must stay on your machines, knowing that tool inputs and outputs still go to Anthropic.\n\nAnthropic’s docs are explicit about where its controls stop. The host allowlist, the placeholders and `always_ask` on MCP are good defaults to build on, and the API’s `unrestricted` default and `always_allow` on bash are the two to change first. What an agent can do with an allowed host and a valid credential is still decided by the service that issued the key and by whatever sits on the network path, and that part is yours. Next, we’re running the Formal setup above against a real session. We’ll update this post after we run it.\n\n## Frequently asked questions\n\n### How much does Claude Managed Agents cost?\n\nClaude Managed Agents pricing has two parts: tokens at the model’s usual rates, and session runtime. As of November 2026, Anthropic’s [pricing page](https://platform.claude.com/docs/en/about-claude/pricing) lists runtime at “$0.08 USD per session-hour”, which accrues “only while the session’s status is `running`”, so time spent idle waiting for your next message isn’t billed, and a session that runs for ten minutes costs about 1.3 cents in runtime before tokens. A session-hour is wall-clock time in the `running` state. “You are not separately billed for container hours on top of session runtime.” Web search costs $10 per 1,000 searches. Our two test sessions, a few seconds each, reported list costs of 1 cent and 0 cents, which tells you probing the defaults yourself is cheap and nothing about a production workload.\n\n### What’s the difference between Claude Managed Agents and Claude Code?\n\nClaude Code is a coding agent you run yourself, in a terminal or an IDE, on your machine or your CI. Claude Managed Agents is an API where Anthropic hosts the agent loop and the sandbox and you send it tasks. Anthropic’s engineering post mentions it directly: “Claude Code is an excellent harness that we use widely across tasks.” For locking it down, see [Claude Code security](https://www.formal.ai/integrations/claude-code/) and our post on the [Claude Code sandbox](https://www.formal.ai/blog/claude-code-sandbox/).\n\n### What agents does Claude have?\n\nAnthropic documents three ways to run Claude as an agent: your own agent loop on the Messages API (“Custom agent loops and fine-grained control”), Claude Code for coding work, and Claude Managed Agents for “Long-running tasks and asynchronous work” that Anthropic hosts. The first two run wherever you run them; the third runs on Anthropic’s infrastructure or a worker you connect.\n\n### Which IP addresses does Claude Managed Agents connect from?\n\nAnthropic publishes `160.79.104.0/21` and `153.61.208.0/20` as the addresses it uses “for outbound requests (for example, when making MCP tool calls to external servers)”. That’s what to allow on an MCP server that restricts inbound traffic. The page doesn’t say whether bash commands in the cloud sandbox leave from the same ranges, so don’t build an allowlist on that.\n\n### Is Anthropic Managed Agents eligible for zero data retention or HIPAA?\n\nNo. Anthropic’s overview says “Managed Agents is not currently eligible for Zero Data Retention or HIPAA Business Associate Agreement (BAA) coverage”, and that applies to self-hosted sandboxes too, because session transcripts persist until you delete them.\n\n### Is Anthropic Managed Agents available on AWS and Google Cloud?\n\nYes, in beta on Claude Platform on AWS and on Claude Models on Google Cloud (Anthropic managed), with some differences in features. MCP tunnels are one of them: Anthropic’s tunnels page lists only the Claude API.", "url": "https://wpnews.pro/news/claude-managed-agents-who-secures-what", "canonical_source": "https://www.formal.ai/blog/claude-managed-agents-security/", "published_at": "2026-11-09 00:00:00+00:00", "updated_at": "2026-11-10 02:20:23.737995+00:00", "lang": "en", "topics": ["ai-agents", "ai-safety", "ai-products", "ai-tools"], "entities": ["Anthropic", "Claude Managed Agents", "Claude API", "Claude Platform on AWS", "Claude Models on Google Cloud", "Formal"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/claude-managed-agents-who-secures-what", "markdown": "https://wpnews.pro/news/claude-managed-agents-who-secures-what.md", "text": "https://wpnews.pro/news/claude-managed-agents-who-secures-what.txt", "jsonld": "https://wpnews.pro/news/claude-managed-agents-who-secures-what.jsonld"}}