How to Set Up Claude IP Allowlisting and Fix 403 permission_error

Claude organizations can restrict covered traffic to approved public IP addresses and CIDR ranges with IP allowlisting. Help Center describes it as a public beta for Enterprise plans and Claude Platform organizations. Platform release notes dated November 5, 2026 introduced the Console IP allowlist in beta: IPv4 and IPv6 addresses or CIDR ranges, up to 1,000 entries per organization, so a leaked API key is harder to use from arbitrary networks.

This is a setup and troubleshooting guide, not a same-day launch brief. Anthropic documents two separate control planes. Mixing them—one toggle, one role name, one settings path—is the most common way to configure the wrong product.

Steps and quoted error text below follow Anthropic’s documentation.

Two control planes (do not mix)

Help Center is a short overview and points to the Platform docs for full setup. Use the docs page as the configuration reference; do not treat the Help article as the only handbook.

Control plane A: Claude Platform / Console

Threat model (docs): if an API key leaks, allowlisting makes it much harder for an attacker to use it from outside your approved ranges. An allowlist limits *where* a key works, not *how long* it remains valid. Anthropic still recommends short key expiration or Workload Identity Federation (WIF) instead of relying on allowlisting alone.

Where it applies (docs):

• Claude Console UI access
• Claude API endpoints: Messages, Message Batches, Token Counting, Models, Files, and Skills (API key or WIF token)
• Claude Managed Agents endpoints: Agents, Sessions, Environments, Vaults, and Memory stores (API key or WIF token)
• Organization Admin API and Compliance API, with a key that covers only this organization

Where it does not apply (docs Limitations):

• Managed Agents runtime networking (endpoint coverage ≠ agent runtime network)
• Claude in Amazon Bedrock, Claude Platform on AWS, Claude Models on Google Cloud, or Claude in Microsoft Foundry

How to turn it on

1. Open Claude Console → Identity and access.
2. Turn on the IP allowlist toggle. Nothing takes effect until you save.
3. Click Add entry. Add public IPv4/IPv6 addresses or CIDR ranges (format rules below).
4. Keep Allow admins to access this settings page from any IP address selected unless you have a deliberate reason not to—this is Anthropic’s recommended lockout escape for Console.
5. Save. Wait up to 15 minutes for changes to apply, then watch covered apps for 403 permission_error responses.

Off-list behavior: covered API requests from an address outside the list are rejected. Documentation’s Messages API example returns 403 permission_error with the message Your IP address isn't in this organization's allowed range. People who connect from a disallowed address can see a page titled Your current network can't access this organization. Admins are also blocked unless you enabled the optional “access this settings page from any IP” escape, in which case they can reach only the allowlist settings.

Control plane B: Claude Enterprise / claude.ai

Threat model (docs): a stolen user sign-in is harder to use against covered organization apps when traffic must come from approved ranges. The list covers the whole Enterprise organization, owners included. Only owners and primary owners can set it up; Enterprise admins cannot change the allowlist.

Apps the allowlist covers (docs):

• Claude in a browser, desktop apps, and mobile apps
• Claude Code, when users sign in with their Claude account
• Claude in Chrome, Office add-ins, Cowork, and Remote Tools
• Connectors and artifacts in those apps, except artifacts a user shared outside the organization
• Admin API and Compliance API with a key that covers only this organization

Not covered (docs Limitations): Claude Design, Claude in Slack, and Claude Academy. If Claude is working on a chat task when a user is blocked, that task can continue for up to 24 hours, but the user cannot open or control the chat from outside the list.

Proxies: some features connect through bridge.claudeusercontent.com (Claude in Chrome, Cowork, Remote Tools, and cross-app work in Office add-ins). If your proxy sends that host out through a different egress address than claude.ai / api.anthropic.com, list that egress address too.

How to turn it on

1. Open claude.ai → Organization settings → Organization and access.
2. Turn on the IP allowlist toggle. Nothing changes until you save.
3. Click Add IP range. Add public addresses or CIDR ranges.
4. Keep Allow owners to access this settings page from any IP address selected to reduce lockout risk.
5. Save. Expect up to 15 minutes for changes; already-open connections, Office add-ins, or Remote Tools sessions may take longer to reflect the new list.

Off-list behavior: on web and desktop, blocked users see Your current network can't access this organization. In Claude Code, blocked users see a 403 API error with the same message: Your IP address isn't in this organization's allowed range.

Entry format, limits, and public-only rules

Documentation examples:

• Single IPv4: 203.0.113.5
• IPv4 CIDR: 203.0.113.0/24
• IPv6 CIDR: 2001:db8::/32

Rules from the docs:

• Each entry is a single address or a CIDR range no broader than /8 for IPv4 or /32 for IPv6
• Up to 1,000 entries per organization
• Public addresses only—list the addresses traffic leaves your network from; do not list private ranges such as 10.0.0.0/8
• You can enter comma-separated values and press Enter; unsaved edits do not apply until you save
• Changes can take up to 15 minutes to apply

There is no separate anthropic-beta request header that “turns on” allowlisting for API calls. Allowlisting is an organization setting, not a per-request beta flag like some other Claude API betas.

Avoid locking yourself out

On save, Anthropic checks the current address of the person saving. It does not validate every server, teammate laptop, CI runner, or tomorrow’s VPN egress.

Practical safeguards from the docs:

1. Before save, include every egress you need: office, VPN, CI, cloud NAT, and—on Enterprise—any distinct egress for bridge.claudeusercontent.com.
2. Leave the Allow admins / Allow owners escape checkbox enabled.
3. Prefer a second admin (Console) or owner (Enterprise) who can still reach settings if you mis-list an address.
4. Do not clear the list while you are already locked out and have no escape path.

If you are locked out

1. Reconnect from a network that is already on the list.
2. Ask another admin (Console) or owner / primary owner (Enterprise) to fix the list.
3. If the escape checkbox was enabled, that role can reach allowlist settings from any IP, add the missing range, or turn allowlisting off.
4. Otherwise contact Anthropic support to turn the allowlist off.
5. Access can take up to 15 minutes to return after a fix.

403 and “can’t access this organization” checklist

Use this order when something looks blocked after you enable or edit the list:

1. Confirm organization type. Console Identity and access ≠ claude.ai Organization and access.
2. Confirm Save. Toggle alone is not enough; unsaved entries do not apply.
3. Wait up to about 15 minutes. On Enterprise, already-open Office / Remote Tools / similar sessions may lag further.
4. Check the public egress IP of the failing client (laptop, CI, VPN, reverse proxy, NAT). Private RFC1918 addresses do not belong on the list. On Enterprise, include bridge.claudeusercontent.com egress if it differs.
5. Match the error text. Treat 403 permission_error with message Your IP address isn't in this organization's allowed range. (and the UI title Your current network can't access this organization) as allowlist denials. Other 401 / 429 / billing failures are different problems.
6. If you locked yourself out, follow the lockout steps above. Do not wipe the list from an unlisted network without an escape path.

Anthropic’s docs give the permission_error type and the message string for the Messages example; they do not publish a full sample error JSON body on that page.

What allowlisting is not

• It is not general availability; treat it as beta / public beta. Settings and behavior can change during beta.
• It does not prove a key cannot leak, stop all abusive billing, or replace short-lived credentials / WIF.
• Listing a shared proxy IP can also let an attacker reach covered services through that same proxy if they have a leaked key or stolen session.
• Official docs do not publish a separate allowlist price.
• Same-day Admin API “sign a member out everywhere” (also noted on November 5, 2026) is a different Enterprise capability—useful context at most, not part of allowlist setup.

Practical checklist

1. Pick control plane A (Console) or B (Enterprise)—not both as one switch.
2. Open the matching settings page with the matching role (Admin vs owner / primary owner).
3. Add only public IPs / CIDRs; stay within breadth and 1,000-entry limits.
4. Keep the admin/owner settings escape enabled.
5. Save, wait up to 15 minutes, then verify from each critical egress.
6. On 403 permission_error with the documented message, fix egress membership before chasing unrelated auth errors.
7. Pair allowlisting with short key expiry or WIF on Platform; do not treat the list as the only control.

Follow the live Claude Platform IP allowlisting docs and Help Center article for any UI label that drifts after beta. The split between Console and Enterprise, the 403 permission_error message, the 1,000-entry cap, and the up-to-15-minute apply window are the stable starting points for setup and triage.