Secure Claude Managed Agents: the settings that matter first
Anthropic's beta checklist for Claude Managed Agents, in order: limited networking, vault secrets, domain allowlists, approvals, a budget and monitoring.
To secure a Claude Managed Agents deployment, limit what the agent can reach before you worry about what it might do. Set networking to limited, keep secrets in vaults, put domain allowlists on the web tools, and require approval for actions you cannot undo. Anthropic's secure deployment guide lists its settings "most important first". Managed Agents is in beta.
This site is independent and not affiliated with Anthropic. We read Anthropic's three security pages on 2026-10-15 and did not deploy an agent, so the example below is Anthropic's, not our test. It is written as much for the person who asks a developer to build an agent as for the developer.
The order Anthropic recommends
The guide opens with a table. Here it is, shortened:
| Decision | Recommended |
|---|---|
| Where the agent runs | Cloud, unless files and processes must stay on your infrastructure |
| Network | networking.type set to limited, with only the hosts the agent needs |
| Credentials | In vaults, in request headers only, tied to the hosts the key is for |
| Web search and fetch | An allowed_domains list on each tool |
| Risky actions | A permission_policy on each tool, with always_ask where you cannot undo the change |
| Tools | default_config.enabled set to false, then enable only what the agent needs |
| Untrusted input | No agent that reads it holds a write, run or change tool on always_allow |
| Limits | A budget on each session and deployment |
| Monitoring | Alerts when a session goes idle, reaches its budget or terminates |
Why settings and not trust
Hidden instructions in a web page, ticket or email can steer an agent. Anthropic's risks page is blunt about it: "Claude is inherently resilient to it, but model behavior is not a security control." The settings limit the damage if an attempt works.
Its own example is a ticket that tells the agent to cancel every open order. The settings do not make that impossible. They decide whether the agent holds a tool that can do it.
The same page adds two limits: "These settings lower the risk but do not remove it, so do not put data in the sandbox that must never leave it." And the settings "do not secure your custom tools, your MCP servers, or your self-hosted infrastructure."
A worked example: the support agent
Anthropic's running example is a support agent. It reads a customer's ticket, looks up the order, reads your help center and drafts a reply. The environment allows one host. This is Anthropic's environment.yaml:
name: support-agent
config:
type: cloud
networking:
type: limited
allowed_hosts:
- help.example.com
The tools start from nothing. Three built-in tools come back on, each with its own policy, and one custom tool does the order lookup:
tools:
- type: agent_toolset_20260401
default_config:
enabled: false
permission_policy:
type: always_ask
configs:
- name: read
enabled: true
permission_policy:
type: always_allow
- name: write
enabled: true
permission_policy:
type: auto
- name: web_fetch
enabled: true
allowed_domains: [help.example.com]
permission_policy:
type: auto
The agent has no bash and no credential. Anthropic's reason: "Your application holds the API key for your order API, so the agent needs neither bash nor a credential." A ticket that tries to hijack the agent can only change files in the sandbox or open help center pages.
Network gotchas
- Omitting
networkingis risky. Anthropic warns that a create request without it "might getunrestricted", so set it every time. - Access is per host, not per operation. A host you allow can receive any request, including uploads such as
git push. - Host matching is literal. In
allowed_hosts,example.comdoes not matchwww.example.com, and*.example.comdoes not matchexample.com. - Package managers open a lot.
allow_package_managersincludes every repository and path ongithub.com,gitlab.comandbitbucket.org. Anthropic recommendsfalseunless the environment'spackagessetting needs it. - Tightening is not retroactive. A session that is already running can keep the old limits until it ends.
Credentials stay in vaults
Store every secret in a vault. Code in the sandbox sees a placeholder, and Managed Agents swaps in the real secret only in outgoing HTTPS requests to the hosts the credential allows. Set the injection location to request headers only, because request bodies are often built from content the agent reads.
Keep keys out of system prompts, agent definitions and messages. Do not give the agent a Claude API key either. Even in a vault, code in the sandbox can use it to call the Claude API directly, and the agent's tool settings, approvals and budget do not apply to those calls.
Limit each key's permissions at the service that issued it, because these settings do not limit them. For the local-file version of this habit, see our API keys and .env guide.
The Claude moves worth stealing, by email
Workflows tested on real jobs, sent only when they are worth it. Free.
Approvals: what auto is and is not
Anthropic's table sets read, glob and grep to always_allow. It sets bash, write, edit and web_fetch to auto, with always_ask instead where you cannot undo a change outside the sandbox. The default matters: the agent toolset default is always_allow, which runs every call without approval.
auto lets the server run a call, deny it, or pause for approval. But "auto is not a human checkpoint, so if a person must review a tool's calls before they run, configure always_ask on that tool."
Claude Code has the same idea on your own machine: our guide shows how dangerous tools can need approval there.
Plan for the pause. "A paused session waits indefinitely, so an unattended session needs a client that answers paused calls or interrupts the session."
Untrusted input meets powerful tools
Untrusted input is anything someone outside your team can write: web pages, tickets, emails, uploads, MCP results and relayed end-user messages. Powerful tools run commands, write files, send data or use a credential. The rule is not to give one agent both.
Anthropic lists specific traps:
- A mounted GitHub repository. An agent with
readloads skills from the repository's.claude/skillsdirectory as agent instructions, with no review step. - Memory stores. The default is
read_write, and later sessions read saved text as trusted memory. Attach the store asread_onlyunless the agent must write. - Instruction files. Reading a file with
readcan also loadCLAUDE.mdandAGENTS.mdfiles as instructions. No setting turns that off except disablingread.
When an agent must read untrusted input and also act, Anthropic recommends one of three designs: split reading from acting across agents, give the agent one narrow custom tool, or keep a person in the loop with always_ask.
The split has a limit. Agents in one multiagent session share the sandbox, its files and the vault credentials, so the split separates only their tools and conversations. Our dynamic workflows guide covers the multiagent setting that turns on subagents.
Budgets and the stop button
Set a budget when you create each session. A budget's max_list_cost.amount is a whole number of US cents written as a string, so "125" means $1.25. You cannot add a budget to a session created without one.
A cap is not a wall. Requests in progress can finish and their tool calls still run, so spend can pass the cap. To stop a running agent, Anthropic lists these steps:
Send user.interrupt by itself
It stops the model response immediately. A running tool call can finish first.
Pause the deployment
For a scheduled agent, so no new run starts. Archive the deployment to end the schedule for good.
Rotate exposed keys
At the service that issued them.
Ask it to stop open workflow runs
An interrupt ends no workflow run.
Wait for the session to go idle
A running session cannot be archived or deleted.
Archive or delete the session
Archive keeps the history. Delete it when you no longer need it.
"An interrupt does not undo what the agent already did or sent."
Monitoring and retention
Anthropic's monitoring page names the webhooks to watch: session.status_idled, session.budget_reached and session.status_terminated. A delivery can be missed, so also list your sessions on a schedule and check the idle ones.
It also describes an optional offline reviewer: a job that sends each session's events to Claude and flags overreach, repeated attempts and misreporting. The sample prompt "is a starting point, so test it on your own sessions." Claude can decline to review a transcript that shows real misuse, and a refused review counts as not reviewed.
Retention, per the same page:
- Session history is kept until you delete the session.
- Sandbox state is kept for 30 days after the sandbox is created.
- Files a session produces are deleted with the session.
- Files you uploaded, memory stores and vaults are not deleted with the session.
Where this falls short
This is a beta feature, and Anthropic's pages describe it as of today. We have not run any of these settings, so we cannot tell you how they behave under a real attack. Anthropic itself says they lower the risk and do not remove it.
With a self-hosted sandbox you carry more: you are responsible for isolating sessions from each other and hardening the sandbox image, and environment variable credentials are not yet supported there.
Is Claude Managed Agents eligible for zero data retention?
Not currently. Anthropic's monitoring page says Managed Agents is not currently eligible for Zero Data Retention or HIPAA Business Associate Agreement (BAA) coverage. Session history is kept until you delete the session, so decide what you store before you start.
Should I give a Managed Agents agent a Claude API key?
No. Even when the key sits in a vault, code in the sandbox can use it to call the Claude API directly and do anything the key allows, such as starting or deleting sessions. The agent's tool settings, approvals and budget do not apply to those calls.
How do I stop a runaway Managed Agents session?
Send user.interrupt by itself, pause the deployment if the agent is scheduled, and rotate any exposed key. Wait for the session to go idle, then archive it. An interrupt does not undo what the agent already did or sent.
