In one of the enterprise cases in Wiz's write-up of October's AI-platform breaches, a single address "made approximately 1.7 million Bedrock calls" (Wiz). Wiz also lists IP addresses it saw testing stolen keys as indicators of compromise, though it says it has no evidence tying them directly to the October attacks.

On November 5, Anthropic added an IP check to the Claude Console. The release notes say you can now set up an IP allowlist for your organization, in beta, so requests from addresses not on your list are refused, "which limits where a leaked API key can be used."

There is a catch, and it's in the same docs. The list doesn't reach Claude on Bedrock, which is where both enterprise cases in Wiz's write-up ran. And every job you forget to list gets the same 403 an attacker would.

What shipped on November 5

An organization admin or owner sets one list of IP ranges for the whole organization, and Anthropic compares each covered request's public IP address against it. The list holds up to 1,000 entries. Each entry is a single IPv4 or IPv6 address or a CIDR range, no broader than /8 for IPv4 or /32 for IPv6.

On a Claude Platform organization, the allowlist covers the Console UI and these APIs, whether you call them with an API key or a Workload Identity Federation token (docs):

  • Messages, Message Batches, Token Counting, Models, Files and Skills
  • the Claude Managed Agents endpoints: Agents, Sessions, Environments, Vaults and Memory stores
  • the Admin API and the Compliance API, with a key that covers only that organization

A refused call to the Messages API comes back as a 403 permission_error with the message Your IP address isn't in this organization's allowed range. Changes can take up to 15 minutes to apply.

Claude Enterprise organizations get a separate list. It covers Claude on the web, desktop and mobile, Claude Code when users sign in with their Claude account, Claude in Chrome, the Office add-ins, Cowork and Remote Tools (docs). A developer who opens Claude Code from home without the VPN sees that same 403 message. Developers Digest has an independent walkthrough of both lists.

A large black key whose teeth are shaped like three small server buildings, standing inside a burnt-orange fence, while an identical copy of the key held from outside the fence is stopped at a closed gate
The gate checks the address a request leaves from.

Where the list stops

The Limitations section is short and worth reading before anything else:

  • It doesn't apply to Claude in Amazon Bedrock, Claude Platform on AWS, Claude Models on Google Cloud, or Claude in Microsoft Foundry.
  • It covers requests to the Managed Agents endpoints, "not the agents themselves," and doesn't apply to any networking inside the Managed Agents runtime.
  • On Claude Enterprise, Claude Design, Claude in Slack and Claude Academy aren't covered. A task Claude is already working on in a chat can keep running for up to 24 hours after its user is blocked, though the user can't open or control it from outside the list.

The first bullet matters most for the incidents that set this up. Both enterprise cases in Wiz's write-up were Bedrock traffic, and in one of them Opus models made up three quarters of successful calls (Wiz). Anthropic's list can't touch that path. If you reach Claude through AWS, the equivalent control lives in IAM: a policy can compare aws:SourceIp with the ranges you allow. AWS's docs warn that the key isn't present when the request comes through a VPC endpoint, and that Deny statements built on it can block AWS services calling on your behalf (AWS IAM docs).

The 403 you'll cause yourself

The save button protects exactly one address. Anthropic's lockout guidance says the settings page checks your current address against the list, "but it does not check your servers, your teammates, or the address you might connect from tomorrow."

You're asked to list data centers, CI systems, offices, VPNs, proxies and the workers of any self-hosted sandboxes, with both their public IPv4 and IPv6 addresses (docs). Private ranges don't count, because Anthropic sees the address your traffic leaves from. To find those addresses, run this on each server that calls Claude:

# Public IPv4 address this host egresses from curl -s https://checkip.amazonaws.com # Public IPv6 address, if the host has one curl -6 -s https://ifconfig.co

Hosted CI runners need more than one check, because their address can change from run to run. Send those jobs out through a fixed egress address, such as a self-hosted runner or a NAT gateway, and list that.

After you save, Anthropic says to watch for 403 permission_error responses, "including jobs that run only daily or weekly." That's the failure most likely to hurt. A weekly report or a monthly batch job can hit the gate days after you flip it, from a runner nobody remembered to list.

So make the refusal loud. In the Python SDK, a 403 raises PermissionDeniedError (SDK docs). Don't retry it. Alert on it:

import anthropic client = anthropic.Anthropic() try: client.messages.create( model="claude-opus-5-5", max_tokens=64, messages=[{"role": "user", "content": "ping"}], ) except anthropic.PermissionDeniedError as err: # A retry from the same host gets the same 403.  # Alert here: this host's egress IP may be unlisted.  print("Claude refused this host:", err.message) raise

Two settings need a decision. If a shared proxy address is on the list, an attacker with a leaked key who can reach that proxy could use the key through it. And the recommended "Allow admins to access this settings page from any IP address" checkbox prevents lockout, but an attacker who takes over an admin's session could then edit the list from anywhere. If you've set up the Compliance API, its Activity Feed records changes to the allowlist (docs).

A burnt-orange calendar page with a small clock-shaped robot walking up to a closed black gate, while a second identical robot already sits on the right side of the gate
The job that runs once a week is the last one to find out about the new list.

Location is not lifetime

Anthropic is plain that the list isn't enough on its own: "An allowlist limits where a key works, but not for how long" (docs). It recommends a short key expiration or a move to Workload Identity Federation, and calls that "safer than allowlisting alone."

Both are already there. When you create a key in the Console you pick an expiration: 3 hours, 1 day, 7 days, 30 days, a custom duration, or Never. You can't change it afterwards (authentication docs). Workload Identity Federation swaps the static key for a short-lived token exchanged from an identity your cloud, GitHub Actions or Kubernetes already issues. WIF has its own caveat: it "does not, on its own, guarantee end-to-end security" (authentication docs).

Anthropic also shipped a second admin control on November 5, for Claude Enterprise: POST /v1/organizations/users/{user_id}/sign_out, in beta, ends a member's sessions, trusted devices and OAuth tokens for the organization on every device. The member stays in the organization and can sign in again right away (release notes).

I haven't turned the allowlist on for an organization myself. Everything above comes from Anthropic's docs as published on November 5, and the feature is a beta whose "settings and behavior can change" (docs).

Would you turn it on?

If your Claude traffic leaves from a few fixed NAT addresses, this is a small change that makes a leaked key worth much less. If it leaves from shared CI runners, laptops on home Wi-Fi and a proxy half the company uses, the list gets long, and every entry is a place a stolen key still works.

Where does your Claude traffic come from today: fixed addresses you could list in an afternoon, or somewhere you'd have to go and find out? Tell me in the comments.

If this was useful

The hard part of this rollout is knowing every caller before you flip the toggle, and spotting the one you missed the first time it gets a 403. That's an observability problem, and the LLM Observability Pocket Guide covers picking the tracing and logging tools that show you every call your LLM features make, so the weekly job isn't a surprise. If you run Claude Code next to other agents, I build Hermes IDE, a free, source-available console that runs each agent in its own terminal and worktree on macOS, Windows and Linux (GitHub).

LLM Observability Pocket Guide: Picking the Right Tracing & Evals Tools for Your Team