Anthropic adds IP allowlisting and a sign-out API to Claude admin controls

Anthropic added two access controls to Claude on 5 November 2026, according to its Claude Platform release notes: an IP allowlist for organizations, in beta in the Claude Console, and an Admin API endpoint that signs a member out of Claude everywhere. Both aim at the same problem for teams running Claude at work: a stolen API key or sign-in being used from somewhere it should not be.

IP allowlisting

An organization admin or owner enters a list of IP ranges, and Anthropic compares the public IP address of each covered request with it. Per the docs, the release notes allow up to 1,000 entries per organization. Each entry can be a single address or a CIDR range no broader than /8 for IPv4 or /32 for IPv6, and must be a public address, not a private range such as 10.0.0.0/8.

A request from an address outside the list gets a 403 permission_error from the Messages API, with the message "Your IP address isn't in this organization's allowed range." Anthropic says the allowlist limits where a leaked key works, not for how long, and recommends also setting a short key expiration or moving to Workload Identity Federation.

What it covers, and what it does not

• Covered on the Claude Platform: the Console, the Messages, Message Batches, Token Counting, Models, Files and Skills endpoints, the Managed Agents endpoints (Agents, Sessions, Environments, Vaults, Memory stores), and the Admin and Compliance APIs when used with a key scoped to one organization.
• Not covered: Claude in Amazon Bedrock, Claude Platform on AWS, Claude Models on Google Cloud and Claude in Microsoft Foundry. Networking inside the Managed Agents runtime is also outside it.
• Claude Enterprise has its own allowlist covering the browser, desktop and mobile apps and Claude Code when users sign in with a Claude account. Claude Design, Claude in Slack and Claude Academy are not covered, and a task already running in a chat can continue for up to 24 hours after a user is blocked.

Signing a member out everywhere

The release notes describe POST /v1/organizations/users/{user_id}/sign_out as ending a member's sign-in sessions and trusted devices on every browser and device, plus their OAuth tokens for your organization. It is in beta, every request needs the header anthropic-beta: admin-user-sign-out-2026-10-08, and it needs the write:members scope. The docs list lost or stolen devices, security incidents and account investigations as uses.

Two limits matter for a runbook. The member keeps their seat and role and can sign in again immediately; to keep someone out you must remove them, or disable their account in your identity provider if you use single sign-on. And the docs say the sign-out reaches the person's whole Claude account, including sessions in other organizations and on an individual plan.

What Anthropic leaves for you to check

• The save-time check confirms only your current address is on the list. It does not check your servers, teammates or tomorrow's address, so Anthropic tells admins to list data centres, CI, offices, VPNs, proxies and self-hosted sandbox workers first.
• Changes can take up to 15 minutes. Anthropic advises watching for 403 errors, including from jobs that run only daily or weekly.
• Anthropic recommends letting admins reach the settings page from any address to avoid lockout, and notes the downside: an attacker who compromises an admin session could change the list remotely. The Compliance API Activity Feed records allowlist changes.
• A shared proxy address on the list means a leaked key used through that proxy would still pass.

This is Anthropic describing its own feature. There is no independent test of either control yet, and the pages do not say how the allowlist behaves for traffic through cloud-marketplace routes beyond listing them as excluded. If your Claude use runs through Bedrock, Google Cloud or Foundry, this allowlist does not protect it; your cloud provider's network controls still apply.