Claude adds IP allowlists with API coverage limits

Anthropic introduced IP allowlisting in beta on 5 November, letting organisation administrators restrict covered Claude requests to approved public network addresses. A request from outside the list is refused with a 403 permission error, even when its API key is valid. For platform and security teams that is a trade: a leaked credential becomes less useful, and every legitimate network left off the list becomes a production incident. Primary documents: the dated Claude Platform release notes and Anthropic's IP allowlisting documentation. The documentation says the feature is in beta under your agreement with Anthropic, that settings and behaviour can change, and it gives no end date.

Which Claude routes the allowlist covers

For Claude Platform organisations the allowlist applies to the Console and to the Messages, Message Batches, Token Counting, Models, Files and Skills endpoints, used with an API key or a Workload Identity Federation token. It also covers the Managed Agents endpoints (Agents, Sessions, Environments, Vaults and Memory stores) and the Admin and Compliance APIs when called with a key limited to one organisation. The rule checks the public source address of a covered request. It does not judge whether the request is safe.

Anthropic explicitly excludes Claude in Amazon Bedrock, Claude Platform on AWS, Claude Models on Google Cloud and Claude in Microsoft Foundry. For Managed Agents, the allowlist covers calls to the endpoints, not networking started inside an agent runtime. A company that reaches Claude both directly and through a cloud marketplace has to secure each route separately.

Claude Enterprise has its own organisation allowlist, covering the browser, desktop and mobile apps, Claude Code when users sign in with a Claude account, Claude in Chrome, Office add ins, Cowork, and connectors and artifacts in those apps. Claude Design, Claude in Slack and Claude Academy are excluded. A task already running when a user is blocked can continue for up to 24 hours, although that user cannot open or control the chat from outside the list. Anthropic also warns that traffic to bridge.claudeusercontent.com, used by several of these features, may leave from a different address than claude.ai and api.anthropic.com, in which case that address needs listing too.

The real cost is a network inventory

Each organisation can list up to 1,000 public IPv4 or IPv6 addresses or CIDR ranges, with IPv4 ranges no broader than /8. Private ranges are no use, because Claude sees the public address your traffic leaves from. Anthropic lists the places to check: data centres, CI systems, offices, VPNs, proxies and self hosted sandbox workers. Home and mobile addresses can change without notice, and remote staff off the VPN are blocked until they connect through a listed network. A shared proxy is a weak point, because someone with a leaked key who can route through that proxy would pass the check.

Changes take up to 15 minutes to apply, and in Claude Enterprise they can take longer to reach open connections. That makes a successful test straight after saving weak evidence. Test the real requests from each network once the change has propagated, including jobs that only run daily or weekly.

Anthropic recommends letting administrators reach the settings page from any IP address, so a wrong list cannot lock everyone out. It also states the trade off: an attacker who takes over an administrator session could change the list remotely. The Compliance API Activity Feed records allowlist changes, so wiring that feed into monitoring would be a sensible pairing. That last point is our suggestion, not Anthropic guidance.

Where an allowlist stops helping

The allowlist limits where a key works, not how long it works. Anthropic says a short key expiration or Workload Identity Federation is safer than allowlisting alone, because it removes reliance on long lived static keys. An attacker operating from a listed network, or through a listed shared proxy, is not stopped. The same day, Anthropic also released a beta Admin API call to sign an Enterprise member out of Claude everywhere. The member stays in the organisation and can sign in again, so it ends sessions without removing access.

The pattern this control targets is stolen AI credentials used from somewhere else. Google's LLMjacking findings describe bills above $100,000 in a day after cloud credentials were stolen, and the Northflank breach left customers revoking AI keys at the issuing provider. Both involve other providers, and neither tells us how often a Claude allowlist would have helped. Industry Contents has not tested the control in a live organisation, so this reading rests on Anthropic's documentation. Our report on shadow AI monitoring covers the related problem of finding AI use that nobody listed.

Before you enforce it

1. List every public exit address for servers, CI, offices, VPNs and proxies, plus the address behind bridge.claudeusercontent.com if you use those features.
2. Decide on the administrator recovery option, knowing its trade off.
3. After 15 minutes, test each network and expect a 403 from anything unlisted.
4. Pair the list with short key expiry or Workload Identity Federation.
5. Watch the Compliance API Activity Feed for list changes.

FAQ