claude/for
Search
Subscribe
Work & Tools

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:

DecisionRecommended
Where the agent runsCloud, unless files and processes must stay on your infrastructure
Networknetworking.type set to limited, with only the hosts the agent needs
CredentialsIn vaults, in request headers only, tied to the hosts the key is for
Web search and fetchAn allowed_domains list on each tool
Risky actionsA permission_policy on each tool, with always_ask where you cannot undo the change
Toolsdefault_config.enabled set to false, then enable only what the agent needs
Untrusted inputNo agent that reads it holds a write, run or change tool on always_allow
LimitsA budget on each session and deployment
MonitoringAlerts 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 networking is risky. Anthropic warns that a create request without it "might get unrestricted", 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.com does not match www.example.com, and *.example.com does not match example.com.
  • Package managers open a lot. allow_package_managers includes every repository and path on github.com, gitlab.com and bitbucket.org. Anthropic recommends false unless the environment's packages setting needs it.
  • Tightening is not retroactive. A session that is already running can keep the old limits until it ends.
Start new sessions. After you change an environment, stop the running sessions and start fresh ones. Existing sessions can keep the old rules.

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 read loads skills from the repository's .claude/skills directory 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 as read_only unless the agent must write.
  • Instruction files. Reading a file with read can also load CLAUDE.md and AGENTS.md files as instructions. No setting turns that off except disabling read.

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:

now

Send user.interrupt by itself

It stops the model response immediately. A running tool call can finish first.

now

Pause the deployment

For a scheduled agent, so no new run starts. Archive the deployment to end the schedule for good.

next

Rotate exposed keys

At the service that issued them.

next

Ask it to stop open workflow runs

An interrupt ends no workflow run.

next

Wait for the session to go idle

A running session cannot be archived or deleted.

next

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.

Sources (checked 2026-10-15)

The Claude moves worth stealing, by email

Workflows tested on real jobs, sent only when they are worth it. Free.