Claude Managed Agents Domain Allowlist: What It Blocks (and What It Doesn’t)

Anthropic shipped a security control for Claude Managed Agents three weeks ago that most developers building production agents have not noticed yet. On August 19, 2026, domain filtering landed for the web_search and web_fetch built-in tools. You can now lock down exactly which domains your agent is allowed to reach — and you should. But before you add a list and call it done, you need to know exactly what “locked down” means here, because it is narrower than it sounds.

What Shipped in August

The August 19–20 update dropped three changes at once: memory stores gained compatibility with self-hosted sandboxes, the Console session viewer was redesigned with a per-thread cost inspector and timeline minimap, and web tools got domain filtering. The first two got the blog posts. The third is the one that matters most for security in production.

Domain filtering works by adding an allowed_domains or blocked_domains list to the web_search or web_fetch entry inside your agent_toolset_20260401 configs array. An allowlist restricts the agent’s web tools to only the domains you name. A blocklist excludes specific domains and permits everything else. You pick one or the other — not both. Sending both in the same request returns an HTTP 400.

How to Configure It

The configuration sits inside your agent toolset definition. Set it at agent creation time or via the Built-in tools card in the Claude Console:

{
  "type": "agent_toolset_20260401",
  "configs": [
    {
      "tool_name": "web_search",
      "allowed_domains": ["docs.anthropic.com", "stackoverflow.com"]
    },
    {
      "tool_name": "web_fetch",
      "allowed_domains": ["docs.anthropic.com"],
      "max_content_tokens": 4096
    }
  ]
}

A few format rules will burn you if you skip them. Domain entries are bare hostnames with an optional path — no scheme, no protocol prefix. Write docs.anthropic.com, not https://docs.anthropic.com. A listed domain covers all of its subdomains: adding anthropic.com automatically covers docs.anthropic.com and api.anthropic.com. The reverse is not true — listing docs.anthropic.com does not cover anthropic.com. And www.anthropic.com is treated as its own subdomain, so list the bare domain to cover both. You can also restrict to a path prefix: github.com/your-org permits access to a specific organization but blocks the rest of GitHub.

What the Allowlist Actually Stops

Domain filtering on web_search and web_fetch closes one specific attack path: a prompt-injected instruction telling the agent to fetch or search an arbitrary external domain to exfiltrate data or receive further instructions. If your agent is processing user-supplied content and that content contains an embedded instruction to send session data to evil.example.com, an allowlist stops that call. That is a real threat vector, and closing it is worth the five minutes it takes to configure.

What the allowlist does not cover is everything outside those two tools. If your agent has access to the bash tool — and most production agents do, because bash is how they execute code — a compromised agent can run curl or wget to reach any domain the sandbox’s underlying network policy permits. The allowed_domains setting on web_search and web_fetch is a tool-level control, not a network-level firewall. It is precise and it works, but it does not cover the bash door. Pluto Security’s audit of Claude Managed Agents confirms this distinction and goes deeper on the sandbox network architecture.

The GitHub Problem

There is a subtler issue with how developers typically construct allowlists. If your agent does anything development-related, github.com is almost certainly on your list — it has to be. But once github.com is permitted, a prompt-injected agent can exfiltrate data through GitHub itself: creating public gists, writing repository files, posting PR comments, or pushing to public branches. All of that traffic flows over GitHub’s own HTTPS endpoints, and your domain filter sees it as legitimate GitHub traffic, because it is. The same logic applies to any allowed domain with write capability: npm, PyPI, or Hugging Face.

Cloud Security Alliance research published in August 2026 documented exactly this pattern against three AI coding agents. The conclusion: treat content arriving from any external source — including GitHub issues, PR descriptions, and repository files — as untrusted input, regardless of whether the domain is on your allowlist.

Three Rules for Production Agents

Domain allowlists are not optional for production agents — use them, and use them correctly. Prefer allowlists over blocklists: an explicit list of permitted domains is harder to bypass than a list of forbidden ones. Use path restrictions where you can: github.com/your-org is meaningfully safer than github.com. And combine domain filtering with the max_content_tokens parameter on web_fetch — this limits how much fetched content reaches the context window, cutting token cost and reducing the surface area for injected instructions to arrive on. Treat the allowlist as one layer in a defense-in-depth stack, not as a perimeter. The control is real; the perimeter is not.