Claude Managed Agents: Auto Permissions, Dynamic Workflows and Web Limits to Set First

If you are setting up a Claude Managed Agents agent this month, three recent changes decide how much damage a bad prompt can do: the new auto permission policy, dynamic workflows, and the October rules for what web_fetch may touch. The short version: keep always_ask on shell access, give every web tool an allow list, and switch workflows off until you want them.

This is a read-the-docs post. I fetched the Anthropic pages named below on 2026-10-30 and I did not call the Managed Agents API (no key in this environment). The one thing I ran is an offline script that checks an agent definition against these rules; its output is below. Managed Agents is a beta (managed-agents-2026-04-01 header) and the docs list it as not eligible for zero data retention, so expect pages to move.

What did Anthropic change for Managed Agents recently?

Dates are from the Claude API release notes.

Claude Code also added /claude-api managed-agents-secure, which compares an agent's settings with Anthropic's published security guide without changing anything (Claude Code changelog, version 2.1.304). I did not run it, so I can't tell you how thorough it is.

What does the auto permission policy actually do?

There are now three policies. The defaults matter more than the new one: the agent toolset defaults to always_allow, and MCP toolsets default to always_ask. If you omit default_config, your agent can run its built-in tools, including bash, without asking anyone.

auto sits in between. From the permission-policies page, each call ends in one of three outcomes:

• Runs. The server judged it safe and it runs as under always_allow.
• Denied. The agent gets an error result saying permission was denied, the session keeps going, and your client cannot override it. Sending a user.tool_confirmation for a denied call returns a 400.
• Pauses. No determination, so the session waits for your allow or deny, exactly like always_ask.

The events tell you what happened. Each agent.tool_use carries evaluated_permission (allow, ask or deny) and usually an evaluation object; under auto the reason code is indeterminate for a pause and high_risk for a denial. The docs say to treat reason_code as something to branch on and log, not text to show end users, and to tolerate values you don't recognise.

Two caveats from the page are worth repeating because they are the ones people will learn the hard way:

1. auto is not a human checkpoint. Safe-looking calls run before anyone sees them and may not be reversible.
2. Your user.message text counts as your intent. The server does not take instructions from tool results, fetched pages, MCP responses or messages between session threads, but it does read your user messages as intent. If you pass untrusted end-user text into user.message events, that text can help a call get allowed. Put always_ask on tools you would not let that end user run unreviewed.

My rule: use auto for tools whose worst case you can undo, and always_ask for shell, anything that sends messages, spends money or deletes. This pairs with the approval-gate pattern in human-in-the-loop approval gates for agent tool calls.

Are dynamic workflows on by default?

Per the multiagent orchestration page, yes if you use the newer block type. Setting "multiagent": {"type": "multiagent_20261001"} enables subagents and workflows, and inline agents (agents the main agent or a workflow defines itself) are allowed by default. Enabling workflows explicitly looks like this, quoted from the release notes:

{"multiagent": {"type": "multiagent_20261001", "workflows": {"type": "enabled"}}}

A workflow is a program the agent writes that runs many agents in phases; the server runs it in the background as a workflow run, and you follow it through workflow_run.* events. It suits jobs with many pieces, such as reviewing hundreds of documents. The cost surface is the point: every agent in a run uses tokens. The docs say to set a session budget when you create the session, because you cannot add one to an existing session, and that runs pause when the budget is reached. Also note that a tool call from a run's thread that needs approval reaches your client on the primary stream, so your approval handler must handle it.

Defaults I would set unless I had a reason:

• workflows: {"type": "disabled"} and subagents: {"type": "disabled"} until the job needs them.
• If you do enable them, set inline_agents to {"type": "disabled"} and list the agents you trust in predefined_agents (up to 20 per list). The page says this is how to allow only agents you listed.
• Create the session with a budget.

For the non-managed equivalent of delegation in Claude Code, see the subagents practical guide.

How do I limit what web_fetch and web_search can reach?

Three layers apply at once, and a URL must pass all of them:

1. Per-tool lists on the agent. On the toolset's configs entry for web_fetch or web_search, set allowed_domains or blocked_domains, never both. Each list holds 1 to 64 ASCII domains, no scheme, port, wildcard or IP. A listed domain covers its subdomains, and www.example.com does not cover example.com. web_fetch domains cannot carry a path.
2. Environment networking. With limited networking, allowed_hosts also applies to these tools. Session creation fails with a 400 if a tool's allowed_domains entry is not within allowed_hosts. The two match differently: an allowed_hosts entry matches one exact host unless it starts with *., so docs.example.com is not within ["example.com"]. A blocked fetch returns url_not_allowed.
3. Organization settings. Admins can turn web fetch off or set domain rules on the Console Capabilities page. With it off, a Messages API request that includes the web fetch tool fails with a 400, and in a Managed Agents session the call returns an error result.

Since October 7, web_fetch also only fetches a URL that already appeared in the session: in a user message, a web_search result, or a page web_fetch returned earlier. A URL that only appears in the model's own output, the system prompt, an attached document, or the output of bash, read or an MCP tool gets url_not_in_prior_context. Anthropic says this reduces the risk of data exfiltration. The practical consequence is that if you want the agent to fetch a specific page, paste the URL into a user.message. Background on why this matters is in the prompt injection for tool-using agents post.

Can I check an agent definition automatically?

I wrote a small offline linter that encodes the rules above. It is my reading of the docs, not an official validator, and it reads only the agent JSON. Here is the core of it:

def lint(agent):
    out = []
    for tool in agent.get("tools", []):
        if tool.get("type") == "agent_toolset_20260401":
            default = (tool.get("default_config") or {}).get("permission_policy")
            if default is None:
                out.append("WARN no default_config: default policy is always_allow")
            overrides = {c.get("name"): c for c in tool.get("configs", [])}
            bash = overrides.get("bash", {}).get("permission_policy", default or {"type": "always_allow"})
            if bash.get("type") != "always_ask":
                out.append("WARN bash is not always_ask")
            for name in ("web_fetch", "web_search"):
                cfg = overrides.get(name, {})
                if not cfg.get("allowed_domains") and not cfg.get("blocked_domains"):
                    out.append("WARN %s has no domain list" % name)
        # ... mcp_toolset always_allow check, workflows-enabled check
    return out or ["no findings"]

I ran the full version on two sample definitions I wrote (not real production configs). The loose one uses the multiagent type with no other settings, the agent toolset with no default_config, and an always_allow MCP toolset. The tight one is always_ask by default, has allow lists on both web tools, and disables subagents and workflows.

== agent_loose.json
  WARN agent toolset has no default_config: the default policy is always_allow
  WARN bash is not always_ask (policy: always_allow)
  WARN web_fetch has no allowed_domains or blocked_domains
  WARN web_search has no allowed_domains or blocked_domains
  WARN mcp_toolset github is always_allow
  WARN workflows are enabled (the default for multiagent_20261001)
  NOTE inline subagents are allowed (default)
== agent_tight.json
  no findings

The linter does not check the environment (allowed_hosts, networking type), the session budget, or the Console settings, because none of them are in the agent definition. Check those by hand.

What should I add before going to production?

• Tracing. The OpenTelemetry export (beta, Oct 14) emits spans from the SDKs and can be configured as a destination in the Console. If you already follow the OpenTelemetry tracing for LLM calls approach, add the Managed Agents sessions to it so denied and paused calls are visible.
• Custom tools. They bypass permission policies by design. Your handler decides.
• Data retention. The docs list Managed Agents as not eligible for zero data retention and say session transcripts persist until you delete them. Don't put data in a session you could not store.
• Scheduled runs. Scheduled deployments run sessions on a cron schedule (on the Claude API since June 9, and on Claude Platform on AWS since Oct 14). An unattended agent has nobody to answer an always_ask, so decide in advance what a paused call does.

For the broader safety picture, including sandboxes, read AI coding agent safety: sandbox and permissions.

Sources

• Claude API release notes (Sep 10, Oct 7, Oct 9, Oct 14, Oct 20 entries): platform.claude.com/docs/en/release-notes/api, read 2026-10-30.
• Permission policies: platform.claude.com/docs/en/managed-agents/permission-policies, read 2026-10-30.
• Restrict web search and web fetch domains: platform.claude.com/docs/en/managed-agents/tools-web-restrictions, read 2026-10-30.
• Multiagent orchestration: platform.claude.com/docs/en/managed-agents/multiagent-orchestration, read 2026-10-30.
• Claude Code changelog 2.1.304: code.claude.com/docs/en/changelog, read 2026-10-30.