Guides/Playbook

Claude Managed Agents tightens web access: Review both allowlists

6 min read
On this page
Two overlapping translucent filters pass one shared path while stopping paths outside their intersection

Claude Managed Agents web access

General Analysis

On October 7, 2026, Anthropic changed Claude Managed Agents so a cloud environment's limited networking also restricts its server-executed web_search and web_fetch tools. Previously working web research may now need a configuration change. Before fixing a blocked documentation fetch, check what else the new host grant would allow.

Review that change across both execution paths. A host added for web research also becomes reachable from the sandbox. If the agent has shell access and credentials, the consequences extend beyond reading documentation.

This guide gives a migration procedure for the Managed Agents API beta, using managed-agents-2026-04-01. The configuration and acceptance checks are illustrative; General Analysis has not run a Managed Agents deployment for this article.

Decide whether the task needs a shell#

Consider a hypothetical agent that answers questions from your public documentation. It needs to find and retrieve pages, but has no reason to install packages, upload files, or call a business API. Start its review with that task, rather than copying the configuration of a general coding agent.

Anthropic's environment documentation makes two details consequential: an API environment-create request that omits networking gets unrestricted access, and a permitted host allows sandbox requests beyond reads. The Console's initial Limited selection does not establish the API default.

Set the mode explicitly. For this research task, also disable the shell and other unnecessary tools. If a later request requires a build, review that as an expansion of the workflow's authority. Keep its credential and network requirements with the proposed change.

The coding-agent security baseline covers the surrounding controls. A host allowlist alone cannot decide whether a permitted destination should receive a particular document.

See how your AI systems hold up under real attacks

General Analysis maps AI applications and agents, red teams prompts, retrieval, tools, MCP servers, browser actions, permissions, and business workflows, then turns findings into evidence your team can reproduce and retest.

Give each allowlist a specific job#

Use the environment list as the outer boundary and the tool lists to narrow web access further. The web restrictions reference documents different matching rules:

SettingWhat a listed host permits
Environment allowed_hosts: [example.com]The exact host; it does not include docs.example.com.
Environment allowed_hosts: ["*.example.com"]Subdomains, excluding the bare example.com host.
Tool allowed_domains: [example.com]That host and its subdomains, within the environment restriction.

The environment rules come from cloud networking. Do not copy its wildcard syntax into a tool domain list. For the documentation agent, list the specific documentation host in both places.

Here is an illustrative environment definition. Replace the placeholder with a reviewed host you control. This example has no package installation or MCP dependency.

Code source: illustrative, using the environment configuration fields.

YAML
name: documentation-research config: type: cloud networking: type: limited allowed_hosts: - docs.example.com allow_package_managers: false allow_mcp_servers: false

Pair it with this excerpt from the agent's tools configuration. It leaves other built-in tools disabled. It is not a complete agent-create request.

Code source: illustrative, using the toolset configuration and web domain fields.

YAML
tools: - type: agent_toolset_20260401 default_config: enabled: false configs: - type: web_search name: web_search enabled: true allowed_domains: [docs.example.com] - type: web_fetch name: web_fetch enabled: true allowed_domains: [docs.example.com]

The built-in toolset otherwise enables its tools by default. Custom tools execute in your application, so review their outbound access separately. Keep unnecessary custom tools and MCP servers out of this example's agent definition.

Use the existing ant apply review procedure when deploying resource definitions. Record the returned environment ID and confirm the session uses that environment before interpreting any result.

Diagnose the failure before widening access#

The October 7 release introduced two distinct failure points: a session-create or update request can fail with HTTP 400 when an enabled web tool's allowed_domains falls outside allowed_hosts; a running fetch can return url_not_allowed. Search filters out disallowed hosts. Release notes.

For a 400, compare the submitted configuration against the referenced environment. Check spelling and host scope before adding a wildcard. A domain on the tool list may be unnecessary; removing it can be the appropriate fix.

For a failed fetch, retain the actual tool result and requested hostname. Do not treat the assistant's description of a network problem as the error record. For empty search results, check the configured scope first, then consider ordinary search coverage. An empty result does not establish that the requested material does not exist.

Enabling allow_package_managers or allow_mcp_servers does not grant extra hosts to the web tools. Those exceptions affect sandbox access. An empty environment host list therefore leaves the web tools without results even when an exception is enabled. Environment scope.

If the session uses a self-hosted environment, apply its sandbox egress policy and the server web-tool restrictions separately. The cloud limited coupling described here does not extend to self-hosted environments. Claude Console organization web settings for the Messages API also do not govern Managed Agents sessions. Product boundaries.

Keep a small acceptance record#

Before expanding access, ask the deployment owner to check the intended configuration with public or synthetic content:

  • Fetch a known page on the permitted documentation host and retain its tool result.
  • Request a harmless page on a second, unlisted host you control. Supply its URL explicitly and record whether the fetch is denied.
  • Confirm the effective tool inventory excludes bash and any application or MCP tool that could provide another outbound path.
  • Save the session ID, environment ID, submitted tool configuration, and results with the review decision. Keep expected behavior separate from observations.

If the blocked page is needed, document why that host belongs in the environment before changing either list. Repeat the affected checks after the change.

For a workflow that needs shell execution or sensitive service actions, follow the separate Managed Agents approval guide. Include the required operation and credentials in the access review, so the person approving a new destination can assess what the agent could do there.

Browse all