Feature Request
Problem
The Anthropic Console supports org-level domain restrictions for web search and web fetch tools (Settings → Privacy). These act as a ceiling — request-level blocked_domains can only further restrict, not expand beyond org settings. This is the right architecture.
The problem: there's no API to manage the org-level list, and the list doesn't scale to real-world security blocklists.
We assembled a deduplicated blocklist from 8 curated upstream sources (Steven Black, URLhaus, Phishing Army, Spam404, and others). The result: 196,000+ unique malware/phishing/scam domains. This can't be pasted into a Console text field or passed as request-level blocked_domains.
Current workaround
We split into two layers:
| Layer |
Mechanism |
Scale |
Automated? |
| Console UI |
Hand-curated policy domains (competitors, internal) |
Dozens |
No — manual |
| Claude Code hook |
PreToolUse hook reads local blocklist file, blocks WebFetch to malicious domains |
196k+ |
Yes — script refreshes from upstream |
The hook works but only covers Claude Code. API consumers (our Next.js app) have no equivalent — blocked_domains at request level isn't practical at this scale.
Proposed solution (any of these would work)
-
Admin API endpoint — POST /v1/organizations/domain_restrictions accepting a domain list. Matches the existing Admin API pattern for managing org resources programmatically.
-
Blocklist URL subscription — Console setting that accepts a URL to a published blocklist (like Pi-hole does with OISD/Steven Black). Anthropic fetches and applies it on a schedule.
-
Built-in category toggles — Console toggles for common categories (malware, phishing, adult, gambling) backed by Anthropic-curated lists. Lowest maintenance for customers.
Option 3 would eliminate the need for customers to manage blocklists entirely. Option 1 gives maximum flexibility. Option 2 is the middle ground that leverages existing community-maintained lists.
Context
- The web search/fetch domain filtering docs acknowledge org-level restrictions exist but provide no API surface
- The Admin API currently covers members, invites, workspaces, and API keys — domain restrictions would be a natural addition
- Request-level
blocked_domains has no documented limit but is impractical at 196k+ domains per request
Feature Request
Problem
The Anthropic Console supports org-level domain restrictions for web search and web fetch tools (Settings → Privacy). These act as a ceiling — request-level
blocked_domainscan only further restrict, not expand beyond org settings. This is the right architecture.The problem: there's no API to manage the org-level list, and the list doesn't scale to real-world security blocklists.
We assembled a deduplicated blocklist from 8 curated upstream sources (Steven Black, URLhaus, Phishing Army, Spam404, and others). The result: 196,000+ unique malware/phishing/scam domains. This can't be pasted into a Console text field or passed as request-level
blocked_domains.Current workaround
We split into two layers:
The hook works but only covers Claude Code. API consumers (our Next.js app) have no equivalent —
blocked_domainsat request level isn't practical at this scale.Proposed solution (any of these would work)
Admin API endpoint —
POST /v1/organizations/domain_restrictionsaccepting a domain list. Matches the existing Admin API pattern for managing org resources programmatically.Blocklist URL subscription — Console setting that accepts a URL to a published blocklist (like Pi-hole does with OISD/Steven Black). Anthropic fetches and applies it on a schedule.
Built-in category toggles — Console toggles for common categories (malware, phishing, adult, gambling) backed by Anthropic-curated lists. Lowest maintenance for customers.
Option 3 would eliminate the need for customers to manage blocklists entirely. Option 1 gives maximum flexibility. Option 2 is the middle ground that leverages existing community-maintained lists.
Context
blocked_domainshas no documented limit but is impractical at 196k+ domains per request