Claude Adds IP Allowlists: Check Your Egress First

On November 5, 2026, Anthropic announced a beta IP allowlist in Claude Console. An organization can restrict covered requests to approved public source addresses, with up to 1,000 IPv4 or IPv6 addresses or CIDR ranges. This gives teams a way to limit where a valid API credential works. Before enabling it, find the public addresses used by your servers, jobs, proxies, and people: the restriction applies across the organization, and a missed address can interrupt access.

What changed on November 5

The dated announcement concerns the Claude Console control. Anthropic’s IP allowlisting guide explains how it behaves: an admin or owner saves a list of allowed public IP ranges, and Anthropic compares the source address of each covered request with that list. Requests from outside it are denied. This is an additional condition on access, not a replacement for credentials or an assurance that a leaked key cannot be used. A key could still be used from an allowed address, including a shared proxy.

The guide also describes a separate allowlist for Claude Enterprise organizations. Its app coverage differs from the Claude Platform organization that uses Console and API keys. The November 5 release note specifically announces the Console beta; the current Enterprise documentation should not be read as a claim that every Enterprise feature launched that day.

Which requests does it cover?

The scope matters more than the switch itself. The following is a compact reading of Anthropic’s published coverage and limitations, not the result of a live access test.

Surface	Covered for a Claude Platform organization?	Boundary to remember
Claude Console	Yes	People outside the list cannot normally enter the organization’s Console.
Claude API	Yes, for Messages, Message Batches, Token Counting, Models, Files, and Skills	The documented list is specific; do not assume every endpoint is covered.
Claude Managed Agents API	Yes, for Agents, Sessions, Environments, Vaults, and Memory stores	The restriction covers those API endpoints, not networking inside an agent runtime.
Admin API and Compliance API	Yes, with a key covering only this organization	A broader key is outside the stated condition.
Claude via other named platforms	No, for Amazon Bedrock, Claude Platform on AWS, Claude Models on Google Cloud, and Microsoft Foundry	Apply the access controls of the platform you actually use.

For covered API endpoints, the guide says the rule applies when requests use an API key or a Workload Identity Federation token. It is organization-wide, not a way to allowlist one selected key while leaving other keys unrestricted. It does not control the outbound networking of a Claude Managed Agents runtime. If an agent can reach an external address, this setting is not an outbound firewall for that agent.

If your team also uses Claude Enterprise apps, inspect that organization’s separate coverage before changing it. Anthropic lists browser, desktop and mobile Claude, Claude Code signed in with a Claude account, and several connected apps under the Enterprise list, with explicit exclusions. The Platform table above should not be applied to Enterprise sign-ins.

Numbers and errors to plan around

Anthropic’s official guide documents these limits:

Parameter	Documented limit
Entries	1,000 public IPv4 or IPv6 addresses or CIDR ranges
Broadest IPv4 CIDR	/8
Broadest IPv6 CIDR	/32
Change propagation	Up to 15 minutes

Use the public address from which a request leaves your network, not a private internal address such as 10.0.0.0/8. The CIDR limits are entry-format rules, not a recommendation to add a very broad public range just to fit the list.

Changes can take up to 15 minutes to apply. The setup guide advises watching applications for 403 permission_error responses after saving, including jobs that run only daily or weekly. Its example Messages API error says the source address is outside the organization’s allowed range. A 403 with that cause calls for checking the public egress address and the list. A 429 can indicate a rate limit or a monthly spend cap; inspect the error details before retrying. Our API rate-limits guide explains the distinction. Increasing rate limits will not repair a source-IP denial, and adding an IP will not increase request capacity.

The allowlist is an access boundary, not a cost-control setting. It does not alter Claude token prices or establish a spending cap. Use the API cost calculator to model an ordinary workload, then check your account’s actual usage and spending controls separately.

Inventory your outbound addresses before enabling it

Start with every place a covered request can originate: production and staging servers, CI runners, scheduled jobs, office networks, VPN exits, proxies, and remote workers. Check both IPv4 and IPv6 where they are used. Anthropic’s guide warns that home and mobile addresses can change and that the Console checks only the current address at save time, not your servers or a teammate’s address tomorrow.

An illustrative deployment shows the failure mode. Suppose an application server exits through a fixed public address, but a nightly batch job uses a different CI runner. Listing only the server may leave the interactive application working while the batch job fails later with a 403. This is a planning example, not an observed Claude incident. Record the job’s actual public egress address before you save, and verify it after the rule propagates.

For a practical rollout, make a short inventory with the workload, its covered endpoint, its public egress address or range, and the person who can confirm it. Include the network from which the administrator will save the setting. After saving, test a covered request from each listed network and watch for 403s through the next scheduled job cycle. Where egress changes dynamically, decide whether you can route traffic through a controlled fixed address before applying an organization-wide rule. A shared proxy can simplify the address list, but Anthropic warns that someone with a stolen credential may also be able to use that proxy.

Decide whether your network is ready

If most covered traffic has stable public egress and your team can inventory it, the allowlist may reduce the places where a stolen credential works. If important workloads use untracked or changing exits, first make those paths visible. Keep the Claude message threads guide separate in your planning: that beta changes how long conversations are sent, while this control restricts network origin. The AI model tracker likewise helps with model selection; an IP allowlist is not a model release.

Anthropic recommends leaving the “Allow admins to access this settings page from any IP address” recovery option selected in Console to avoid a lockout. That option lets an admin reach the allowlist settings from outside the range, but the guide warns that a compromised admin session could then change the list remotely. Decide who holds admin access and how you would recover before switching on the rule. If nobody can reach the settings page, Anthropic says to contact support; restoring access can also take up to 15 minutes.

Finally, Anthropic recommends a short key expiration or Workload Identity Federation alongside allowlisting. The list limits where a credential can work; expiry limits how long a static key works, while federation can avoid static keys. Choose the combination for your credential and network setup rather than treating one control as complete protection.

Sources

• Claude Platform release notes: November 5, 2026 Console beta announcement and 1,000-entry maximum.
• Anthropic IP allowlisting guide: covered services, limitations, entry format, rollout delay, recovery, and credential guidance.

All pages read on November 6, 2026.

Free toolWhat will 10,000 chats a month cost?Estimate my bill