--- title: "Claude Console now lets you tie your API keys to an IP list: what it covers, what it doesn't, and how to turn it on without locking yourself out" url: https://hernandez.systems/en/articles/claude-console-now-lets-you-tie-your-api-keys-to-an-ip-list-what-it-covers-what-it-doesnt-and-how lang: en type: NewsArticle section: AI published: "2026-11-07T14:32:55+00:00" modified: "2026-11-08T17:12:27+00:00" publisher: Osky Networks image: https://oskydj.sfo3.cdn.digitaloceanspaces.com/calamardo/news_item/2026-11-07/e94-portada-c8951112.png alternate_es: https://hernandez.systems/es/articulos/claude-console-ya-deja-amarrar-tus-api-keys-una-lista-de-ip-que-cubre-que-no --- # Claude Console now lets you tie your API keys to an IP list: what it covers, what it doesn't, and how to turn it on without locking yourself out > On November 5, according to its release notes, Anthropic added an IP allowlist for Claude Console organizations, currently in beta. The idea is simple and as old as the firewall: if a request to the API comes from an address that isn't on your list, it gets rejected. What changes in practice is that an API key leaked in a public repo, in a log, or in the .env someone pushed by mistake stops being much use outside your networks. If you have bots, agents, or automations burning tokens on a single key, this is one of those features that doesn't shine in a demo but can save you from a really ugly bill. On November 5, according to its [release notes](https://platform.claude.com/docs/en/release-notes/overview#ip-allowlisting), Anthropic added an IP allowlist for Claude Console organizations, currently in beta. The idea is simple and as old as the firewall: if a request to the API comes from an address that isn't on your list, it gets rejected. What changes in practice is that an API key leaked in a public repo, in a log, or in the `.env` someone pushed by mistake stops being much use outside your networks. If you have bots, agents, or automations burning tokens on a single key, this is one of those features that doesn't shine in a demo but can save you from a really ugly bill. ## What Anthropic announced The release notes say three things: the list is configured for the whole organization from Claude Console, requests to covered services from addresses outside the list are rejected, and you can add IPv4 and IPv6 addresses or CIDR ranges, **up to 1,000 per organization**. The [IP allowlisting documentation](https://platform.claude.com/docs/en/manage-claude/ip-allowlist) fills in the picture: - An organization admin or owner sets it up on the **Identity and access** page of the console, with the **IP allowlist** toggle. Nothing changes until you save. - Anthropic compares the **public** IP of each covered request against your list. If it isn't there, the API responds with `403 permission_error` and the message "Your IP address isn't in this organization's allowed range." - People who log in to the console from a network that isn't allowed see a page saying their current network can't access the organization. This includes admins. - Each entry can be a single address or a range, but no broader than `/8` for IPv4 or `/32` for IPv6. - It only accepts public addresses: private ranges like `10.0.0.0/8` make no sense here. - Changes can take **up to 15 minutes** to apply. ## What it covers and what it doesn't In a Claude Platform organization, the list applies to web access to Claude Console and to these endpoints, whether you use an API key or a Workload Identity Federation token: - **Claude API:** Messages, Message Batches, Token Counting, Models, Files, and Skills. - **Claude Managed Agents:** Agents, Sessions, Environments, Vaults, and Memory stores. - **Organization APIs:** Admin API and Compliance API, with a key that covers only that organization. And here come the asterisks, which also come from the documentation. The list **does not apply** to Claude on Amazon Bedrock, Claude Platform on AWS, Claude Models on Google Cloud, or Claude in Microsoft Foundry: if you consume Claude through a cloud provider, you set up network control on that provider's side. It also doesn't apply to the internal network of the Managed Agents runtime: it covers the requests you make to those endpoints, not what the agent does on the inside. ![Diagrama del IP allowlist de Claude Console: una petición desde una IP en la lista es aceptada y una desde fuera recibe 403 permission_error; abajo, lo que cubre y lo que no cubre](https://oskydj.sfo3.cdn.digitaloceanspaces.com/calamardo/news_item/2026-11-07/e94-diagrama-112deb6d.png) For Claude Enterprise organizations there is an equivalent list with a different scope: it covers the Claude apps on web, desktop, and mobile, Claude Code when the user signs in with their Claude account, Claude in Chrome, Cowork, the Office add-ins, and Remote Tools. Claude Design, Claude in Slack, and Claude Academy are not included, and a task Claude was already working on in a chat can keep running for up to 24 hours even if the user gets blocked. ## How to turn it on without locking yourself out The biggest risk of this feature isn't the attacker, it's you blocking your own production. The documentation acknowledges this: when you save, the page checks that your current IP is on the list, but it **doesn't check your servers, your teammates, or the address you'll be connecting from tomorrow**. The order Anthropic suggests: 1. **Take inventory before turning anything on.** Data centers, CI, offices, VPNs, proxies, and self-hosted sandbox workers, with their public IPv4 and IPv6 addresses. The documentation warns that home and mobile data addresses often change without notice. 2. **Check the rescue box.** "Allow admins to access this settings page from any IP address" lets an admin fix the list from anywhere, but only that page. Anthropic recommends it, though it admits the cost: if someone steals an admin's session, they could also edit the list. If you have the Compliance API, its Activity Feed logs those changes. 3. **Watch for 403s after saving,** including jobs that run once a day or once a week, which are exactly the ones you forget in the inventory. 4. **If you get locked out:** connect from an allowed network, ask another admin to add your IP, use the rescue box if you left it on, or, as a last resort, ask Anthropic support to turn the list off. One detail in the documentation worth reading twice: if you add the IP of a shared proxy, anyone who goes through that proxy with your stolen key gets in too. The list protects only as much as your network's exits are locked down. ## The list isn't the only defense Anthropic says it on the same page: the allowlist limits **where** a key works, but not **for how long**. That's why it recommends combining it with two things that already exist in the console: - **Key expiration.** According to the [authentication guide](https://platform.claude.com/docs/en/manage-claude/authentication), when you create a key you choose its lifetime: 3 hours, 1 day, 7 days, 30 days, a custom duration, or "Never." The expiration can't be changed afterward, and an expired key responds with `401 authentication_error`. - **Workload Identity Federation (WIF).** According to its [documentation](https://platform.claude.com/docs/en/manage-claude/workload-identity-federation), instead of a static key your workload presents a token from your identity provider (GitHub Actions, AWS, Google Cloud, Entra ID, Kubernetes, and other OIDC issuers) and receives a short-lived Anthropic token, from 60 seconds to 24 hours depending on how you configure it. There's no `sk-ant-api...` to store or rotate. The allowlist applies to those tokens too. ## What this means My take: for a team that runs its Claude calls from one or two servers with a fixed IP, this is nearly free and worth turning on as soon as it leaves beta, or sooner if the key lives in a lot of places. A VPS on DigitalOcean, a server in your office, or a CI runner with a fixed egress IP can be listed in two minutes. Where it gets complicated is in architectures without a stable IP: serverless functions that go out through the provider's shared addresses, developers testing from home or from their phones, and clients that call the API directly from the app. For those cases the reasonable way out is to route traffic through your own gateway with a fixed IP, or to lean more on short expiration and WIF than on the allowlist. And a reminder that doesn't come from the documentation, but from common sense: the list reduces the damage from a leaked key, it doesn't prevent the leak. The key still doesn't belong in the frontend, or in the repo, or in the team chat. ## Sources - [Claude Platform release notes, November 5, 2026](https://platform.claude.com/docs/en/release-notes/overview#ip-allowlisting) - [Claude Platform Docs: IP allowlisting](https://platform.claude.com/docs/en/manage-claude/ip-allowlist) - [Claude Platform Docs: Authentication (key expiration)](https://platform.claude.com/docs/en/manage-claude/authentication) - [Claude Platform Docs: Workload Identity Federation](https://platform.claude.com/docs/en/manage-claude/workload-identity-federation)