Updates

Claude Console adds IP allowlisting to restrict API access

Illustration of a network gate admitting selected data points and excluding others
AI-generated conceptual illustration, for illustration only.

Anthropic added an organisation IP allowlist to Claude Console in beta on November 5. Requests to covered services from outside the list are rejected, the company says. The aim is to limit where an API key can be used, so a leaked key does not necessarily work from any network.

The list applies across the organisation. An administrator or owner can add IPv4 and IPv6 addresses or CIDR ranges, up to 1,000 entries. These are public outbound addresses, not computers' private internal addresses. That distinction matters when several systems share a proxy or gateway.

What is covered, and what is not

The documentation includes Claude Console access and specified APIs, among them Messages, Message Batches, Token Counting, Models, Files and Skills. Certain Managed Agents and organisation-management endpoints are included too. A Messages request from outside the list returns 403 permission_error, so configuration changes can affect a live application.

The allowlist is not a firewall for everything an agent does. Anthropic says it covers requests to Managed Agents endpoints, not networking inside their runtime. It also does not apply to Claude in Amazon Bedrock, Claude Platform on AWS, Claude Models on Google Cloud or Claude in Microsoft Foundry.

Teams therefore need to map their access paths before relying on this control. One organisation may use several providers; enabling a Console list does not impose the same restriction on all of them. Nor does an allowed address prove that every action originated with the correct person or an authorised purpose.

Check networks before enabling it

Before saving, the documentation recommends including servers, CI systems, offices, VPNs and proxies, and retaining an administrator recovery route. Administrators can optionally reach allowlist settings from any address. This helps recovery but makes protecting accounts that can change the list especially important.

Changes can take up to 15 minutes. Monitor errors and test jobs that run only daily or weekly. One successful request from an administrator's computer does not establish that production servers or scheduled tasks will work. Switching networks can change the public address even when the key stays the same.

Anthropic recommends combining the list with short key expirations or Workload Identity Federation. Allowlisting limits where a key works, not when it expires. Combining controls reduces both the location and duration of potential misuse while leaving a separate need to review the permissions the key grants.