Claude Managed Agents Domain Allowlist: Lock Down web_search and web_fetch (2026 Guide)

If you've shipped a Claude Managed Agent that can browse the open web, you already know the uncomfortable question that comes up in every security review: what stops it from fetching a page it shouldn't, or leaking a summary to a domain you never approved? Until recently, the honest answer was "not much beyond prompt instructions." Anthropic just closed a chunk of that gap. Claude Managed Agents now support allowed_domains and blocked_domains directly on the web_search and web_fetch tool configs — a hard, API-enforced boundary instead of a hope that the model behaves.

This matters more than it sounds. Autonomous agents that browse are one of the fastest-growing categories on the Claude platform, and they're also the category security teams trust the least. A domain-level control that lives in the tool definition — not in the system prompt, where a clever injection could argue its way around it — is the kind of primitive that turns "we're evaluating agentic browsing" into "we've approved agentic browsing for production." If you're building agents, running a AiA cert-prep track toward the Claude Certified Architect exam, or just responsible for what your Claude deployment is allowed to touch, this is worth twenty minutes of your time.

What Changed: allowed_domains and blocked_domains

Claude Managed Agents run with a toolset — a defined set of tools the agent can call during a session, configured once in the Console or via the API rather than re-specified on every request. Two of the most commonly enabled tools in that toolset are web_search and web_fetch, which let an agent look things up and pull down page content mid-task.

The new controls sit on those tool entries:

• allowed_domains — the tool can reach only these hosts. Everything else is refused before the request goes out.
• blocked_domains — the tool can never reach these hosts. Everything else is permitted.

You can set one or the other, not both, on a given tool config — the API returns a 400 error if a request tries to combine them, which is a deliberate design choice to prevent the confusing "allow this but also block that subset of it" logic that tends to produce security holes. Entries are bare domains, optionally with a path, written without a scheme: docs.anthropic.com or github.com/your-org are valid; https://github.com/your-org is not.

In the Console, you'll find these fields on the "Built-in tools" card of the agent form, right under the web_search and web_fetch rows. If you're managing agents through the API, they're plain fields on the tool object in your toolset config.

Why Path Scoping Matters More Than Domain Scoping

The detail worth internalizing is that allowed_domains supports path prefixes, and that path scoping is meaningfully safer than domain scoping alone. github.com as an allowed domain means the agent can fetch literally any public repository, issue, gist, or user profile on GitHub — which is a much bigger surface than most teams intend when they say "let it read our repo." github.com/your-org restricts it to your organization's namespace. The difference sounds small until you consider that GitHub, Google Docs, Notion, and most large platforms host an enormous amount of content under one domain, some of it attacker-controlled (a public issue thread, a malicious gist, a spoofed docs page).

A concrete example: say you're building an internal agent that triages your own repository's issues. If you set:

allowed_domains: ["github.com/your-org/your-repo"]

the agent can pull issue and PR content from that one repository and nothing else on GitHub — not other orgs' repos, not unrelated gists, not a link an attacker slipped into an issue comment pointing at github.com/malicious-org/payload.

Compare that to setting github.com as the allowed domain. The agent is still "restricted to GitHub," which sounds reasonable in a security review, but in practice it can wander to any public content GitHub hosts. If a task involves the agent following links it finds mid-session (a common pattern for research or triage agents), domain-only scoping is a much weaker fence than it appears.

Allowlist vs. Blocklist: When Each Makes Sense

Anthropic's own guidance is blunt about the tradeoff, and it lines up with how most security teams already think about egress control: an explicit list of permitted domains is harder to bypass than a list of forbidden ones. Blocklists are reactive — you add a domain after something goes wrong, or after you think of it. Allowlists are proactive — nothing works until you've explicitly said it should.

That said, blocklists have a legitimate use case: broad-access agents where the task genuinely requires open-web research (a competitive intelligence agent, a general research assistant) but you need to carve out specific no-go zones — competitor domains you don't want the agent citing, known low-quality content farms, internal domains that should never be reachable from an externally-facing agent even by accident.

A practical split:

If you're not sure which category an agent falls into, that uncertainty is itself the answer: start with an allowlist. It's easier to widen a fence than to discover after an incident that yours had a gap.

What This Control Does Not Protect Against

This is the part worth being honest about, because a false sense of security is worse than no control at all. A domain allowlist restricts where the tool can send requests — it does not inspect or sanitize what comes back. Early write-ups of this feature (fairly summarized as "it blocks the blunt leaks, not the clever ones") point out the real gap: if allowed_domains includes a legitimate site that itself contains attacker-planted content — a comment, a wiki page, a public issue — the agent can still read and act on that content. The allowlist stops it from being redirected to an external exfiltration endpoint; it does nothing to stop prompt injection carried on a page the agent was already permitted to fetch.

In practice this means domain allowlisting is a necessary layer, not a sufficient one. It should sit alongside, not instead of:

• Output review or moderation for agents that take consequential actions based on fetched content
• Least-privilege tool grants — don't hand an agent web_fetch at all if the task doesn't need it
• Monitoring and logging of what URLs an agent actually requests in production, so anomalies surface quickly
• Treating fetched content as untrusted input in your system prompt design, the same way you'd treat user-uploaded files or third-party API responses

If you've read Anthropic's own tool-use documentation, this is consistent with how they frame the web_fetch tool generally: it's built for retrieval, and retrieval-based prompt injection is a known, actively-discussed risk class — the domain allowlist narrows the blast radius, it doesn't eliminate the risk category.

Setting This Up: A Minimal Walkthrough

For a Managed Agent configured via the API, the toolset entry for web_fetch with a path-scoped allowlist looks like this conceptually:

json{
  "type": "web_fetch",
  "allowed_domains": ["docs.anthropic.com", "github.com/your-org"]
}

And the equivalent for web_search, restricting search results to a documentation domain:

json{
  "type": "web_search",
  "allowed_domains": ["docs.anthropic.com"]
}

A few things to check before you ship this to production:

Key Takeaways

• Claude Managed Agents' web_search and web_fetch tools now support allowed_domains and blocked_domains, enforced at the API level rather than through prompt instructions.
• You can set one or the other per tool, not both — the API rejects requests that try to combine them.
• Path-scoped allowlists (github.com/your-org) are meaningfully safer than bare-domain allowlists (github.com) whenever the domain hosts third-party or user-generated content.
• Allowlists beat blocklists by default; reserve blocklists for genuinely open-research agents that need broad access with a few carved-out exceptions.
• This control restricts where requests go, not what comes back — it doesn't stop prompt injection from content hosted on an allowed domain. Pair it with least-privilege tool grants and output review.

Next Steps

If domain-level tool security is the kind of detail you need fluent command of — not just "I read a blog post about it" — this is exactly the depth the Claude Certified Architect (CCA) exam tests: tool configuration, agent security boundaries, and production-readiness tradeoffs. AI for Anything's CCA practice test bank is built from real exam-style scenarios covering Managed Agents, tool use, and security configuration, so you can validate you actually understand this before you're asked about it under exam conditions — or before you ship it to production and find out the hard way.

• Web fetch tool — Claude Platform Docs
• Web search tool — Claude Platform Docs
• Managed Agents Tools — Claude Platform Docs
• Claude Managed Agents Domain Allowlist: What It Blocks (and What It Doesn't) — byteiota
• Claude Agents Get a Web Allowlist — Automation Labs on Medium