Claude Console IP allowlist: list every network first

Anthropic added an IP allowlist to the Claude Console on November 5, 2026, in beta. Once an admin turns it on, covered requests from public IP addresses that aren't on the organization's list are refused, which makes a leaked key much harder for an attacker to use. The decision for teams calling Anthropic directly is whether to switch the allowlist on now, and which networks to list before they do.

The catch is coverage. The allowlist applies to the Console and to a set of Anthropic's first-party endpoints, not to models reached through Amazon Bedrock, AWS, Google Cloud or Microsoft Foundry. It also blocks your own servers, CI jobs and admins once a list that misses them takes effect.

What is the Claude Console IP allowlist?

It is an organization-wide list of IPv4 and IPv6 addresses or CIDR ranges that covered requests must come from. The November 5 release note says requests to covered services "from addresses not on your list are refused, which limits where a leaked API key can be used," and that an organization can add up to 1,000 entries.

The IP allowlisting guide describes the mechanism. An organization admin or owner sets the list in the Console. For each covered request, the request's public IP address is compared with the list and denied if the address isn't allowed. A blocked call to the Messages endpoint returns a 403 permission_error with the message "Your IP address isn't in this organization's allowed range." A person who opens the Console from a blocked network sees a page titled "Your current network can't access this organization."

The guide is direct about what the feature doesn't do: "an allowlist limits where a key works, but not for how long." It recommends a short key expiration or a move to Workload Identity Federation, calling either option "safer than allowlisting alone."

Which endpoints does the IP allowlist cover?

On a Claude Platform organization, the allowlist covers the Console UI, the main model endpoints, the Managed Agents endpoints and the organization endpoints. The guide lists these:

• Console: UI access is restricted.
• Model endpoints: Messages, Message Batches, Token Counting, Models, Files and Skills, whether the caller uses an API key or a Workload Identity Federation token.
• Managed Agents: the Agents, Sessions, Environments, Vaults and Memory stores endpoints.
• Organization endpoints: Admin and Compliance, with a key that covers only this organization.

What the allowlist doesn't cover

The guide's limitations section names the gaps. The allowlist "doesn't apply to Claude in Amazon Bedrock, Claude Platform on AWS, Claude Models on Google Cloud, or Claude in Microsoft Foundry." It also covers requests to the Managed Agents endpoints "not the agents themselves," and doesn't apply to any networking inside the Managed Agents runtime.

BaristaLabs interpretation: if your production traffic reaches the models through a cloud provider, this setting does nothing for that traffic. Choosing between the Google Cloud routes already decides which control plane you live in, and the guide doesn't list any Google Cloud route as covered.

The guide also describes a separate allowlist for Enterprise organizations, covering claude.ai, the desktop and mobile apps, and Claude Code when users sign in with their account. This post covers the Console version named in the November 5 release note.

Rules for entries, and how to avoid locking yourself out

Each entry is a single address (203.0.113.5) or a CIDR range (203.0.113.0/24, 2001:db8::/32). Ranges can be no broader than /8 for IPv4 or /32 for IPv6. Only public egress addresses belong on the list, "not private ranges such as 10.0.0.0/8," and the guide warns that a shared proxy address could let an attacker with a leaked key use that proxy.

When you save, the settings page checks the address you are connecting from. It "does not check your servers, your teammates, or the address you might connect from tomorrow," the guide warns. Changes can take up to 15 minutes to apply.

The guide recommends selecting Allow admins to access this settings page from any IP address, so an admin can repair the list from anywhere. It names the tradeoff: an attacker who takes over an admin's session could then change the allowlist from a remote location. If you set up the Compliance endpoints, their Activity Feed records allowlist changes so you can audit them. If no admin can reach the page, the last resort is asking support to turn the allowlist off.

Who should turn it on now

BaristaLabs recommendation: turn the allowlist on if your calls leave from a known, stable set of addresses: a cloud NAT gateway, fixed office egress, a VPN, or self-hosted CI runners with static IPs. That setup gets the benefit with little upkeep, and the list blocks use of a key that leaks through a public repository or a copied laptop config, as long as the attacker calls from an unlisted address.

Wait, or plan more carefully, if any of these apply:

• Hosted CI or serverless functions with changing egress IPs. You'd have to list broad cloud ranges, and IPv4 entries are capped at /8. The guide warns that a shared proxy address weakens the protection, since anyone else using that proxy passes the check.
• Developers calling from home or mobile networks. The guide notes these addresses "can often change without notice." Route that traffic through a VPN or a gateway first.
• Most traffic through Bedrock, Google Cloud or Foundry. The allowlist doesn't see it.

BaristaLabs interpretation: the allowlist limits where a stolen key works, not how long. Pair it with the key-lifetime work the guide itself recommends. Leaked keys are an old problem: the credential leak pattern AI coding keeps shipping walks through what an exposed key can cost.

Recommended first step: inventory egress before you save

BaristaLabs recommendation: treat the first save as a production change.

1. Inventory every caller. Find every source of model traffic: application servers, batch jobs, CI, agent workers, self-hosted sandboxes and the admins who use the Console. The guide specifically calls out jobs that run only daily or weekly.
2. Collect public IPv4 and IPv6 egress addresses for each, through NAT gateways and proxies. Skip private ranges.
3. Turn on the toggle in the Console's Identity and access page, add the entries, keep the admin-access checkbox selected, and save during a window when someone is watching.
4. Watch for 403 permission_error responses for at least a full weekly cycle, and add any address you missed. Allow 15 minutes after each change.
5. Replace existing keys with short-lived ones or plan a move to Workload Identity Federation, so the allowlist isn't your only control.

If one team already tracks usage through the Admin endpoints, it can own this list too. Moving spend alerts to the new analytics endpoint covers that admin surface, and putting the Claude Code gateway in writing covers access rules for developer tools.

Sources and scope

• Claude Platform release notes, entry dated November 5, 2026
• IP allowlisting (beta), Claude Platform docs, accessed November 5, 2026
• Workload Identity Federation and key expiration, Claude Platform docs, accessed November 5, 2026

The feature is in beta, and settings and behavior can change during the beta. BaristaLabs did not enable an allowlist on a test organization for this post. Coverage and limits come from the vendor's documentation as of November 5, 2026. Lines marked BaristaLabs interpretation or recommendation are BaristaLabs' views, not the vendor's. For help planning access controls for AI tools, see AI consulting.