Claude Enterprise security update: a security center, parent organizations, and sign-out everywhere

On November 5, 2026 Anthropic released a batch of security and admin features for Claude Enterprise. Most are in beta. Taken together they answer the questions a security team asks in the first review of a Claude rollout: are our settings right, can we restrict where people sign in from, can we cut off a compromised account right now, and can our existing security tools see what Claude does on a laptop.

This is what each feature does and how to sequence them.

1. Security center (beta)

A new page in Organization settings compares your settings for chat, Cowork, and Claude Code with Anthropic's recommended configuration. For each control it shows the current value, the recommended value, and a link to the setting. It flags settings that changed recently or are new, and it re-checks every time the page loads.

Two extras make it useful for audits:

• Attestations: a shared place for admins to record that a control was reviewed, with who confirmed it. Organizations using the Compliance API can read the results programmatically.
• A downloadable report that marks which controls were checked automatically and which an Owner confirmed by hand.

The security center is guidance based on Anthropic's recommendations. It is not a certification, and passing it does not mean you meet SOC 2, ISO 27001, or any legal standard. Treat it as your starting checklist and record where you deliberately differ.

2. Centralized management for parent organizations (beta)

Large companies often end up with several Claude organizations: one per subsidiary, per region, or from an acquisition. Until now, each had its own SSO, SCIM, and domain setup, configured separately.

A parent organization now gets its own admin console at admin.claude.com. From there you set SSO, SCIM directory sync, domain verification, groups, and Compliance API keys once for every organization underneath it.

• Two new roles. Parent organization owners manage everything at the parent level, including who holds owner and admin roles. Parent organization admins can do everything except change those assignments.
• Several identity providers. Each provider gets its own SSO and SCIM setup, so an acquired company can keep its Okta tenant while you move it over domain by domain.
• Child organizations keep their own members, roles, settings, IP allowlist, tenant restrictions, and session duration. Parent roles do not grant access inside a child organization by default.
• One exception: a Compliance API key created at the parent level can read across every child organization. Decide who holds that key before you create it.

Setup is a vote. An admin of any child organization proposes the parent admins, and admins of the other organizations approve. The last approval completes the setup, and it cannot be undone. Get sign-off from each organization's owner and from legal before the first proposal.

3. Sign a member out everywhere (Admin API, beta)

One API call ends a member's sign-in sessions and trusted devices on every browser and device, and revokes their OAuth tokens for your organization. Apps such as Claude Code require a fresh sign-in. The member stays in the organization and can sign in again straight away, so pair it with an SSO password reset or a block if the account is compromised.

curl -X POST "https://api.anthropic.com/v1/organizations/users/$USER_ID/sign_out" \
  -H "x-api-key: $ANTHROPIC_ADMIN_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "anthropic-beta: admin-user-sign-out-2026-10-08"

What it does not end: API keys, cloud sessions already running, and scheduled routines. If you are responding to a stolen laptop or a compromised account, revoke the person's API keys and check their scheduled tasks as separate steps. Write those three steps into your incident runbook now, while it is calm.

4. Self-serve IP allowlist (beta)

Owners and primary owners can now set an IP allowlist themselves at claude.ai > Organization settings > Organization and access, without a ticket to Anthropic. People connecting from outside the listed ranges lose access to your organization in Claude on web, desktop, and mobile; Claude Code when signed in with a Claude account; Claude in Chrome; the Office add-ins; Cowork; and Remote Tools. The Admin and Compliance APIs are covered too.

Practical details:

• Up to 1,000 entries, IPv4 or IPv6, single addresses or CIDR ranges (no broader than /8 for IPv4 or /32 for IPv6). Public egress addresses only.
• Not covered: Claude Design, Claude in Slack, and Claude Academy. A task Claude is already working on can keep running for up to 24 hours after a user is blocked.
• Remote staff on home Wi-Fi or mobile data are blocked until they connect through the VPN. Tell them before you save.
• If your proxy routes bridge.claudeusercontent.com out through a different address from claude.ai, list that address too, or Cowork and Claude in Chrome will fail.
• Keep "Allow owners to access this settings page from any IP address" selected. Changes take up to 15 minutes to apply.

The same feature shipped for Claude Console (API) organizations on the same day, covering the Messages, Batches, Files, Skills, and Managed Agents endpoints.

5. Claude Desktop settings and outside-account blocking (beta)

Owners can now set the most-used Claude Desktop settings from Organization settings, without pushing a configuration profile through device management. On managed computers, admins can also block personal and other outside Claude accounts in Claude Desktop, so a work laptop cannot be used with someone's personal Pro account. Owners can also restrict which folders people can open with Claude.

This is the shadow-IT control most security teams have been asking for. If your AI usage policy says "work data only in the company Claude account", this is how you enforce it on the desktop.

6. Inference hooks, generally available

Inference hooks are out of beta. Prompt hooks send prompts from supported Claude products to your security tool for an allow-or-deny check before the model sees them. Pre-tool-call hooks check tool calls before they run. They are how you put your existing DLP vendor in front of Claude.

7. EDR inside Cowork (beta)

Cowork runs tasks inside a virtual machine on the user's computer. Endpoint detection and response tools on the laptop could not see inside it. Now your organization's EDR sensor can run inside the Cowork VM and report to your existing security console. Claude checks the sensor package's signature from your EDR vendor every time the VM starts. It runs in detection mode only and does not block anything, and it covers the local VM, not cloud Cowork sessions.

It is available for Cowork on macOS and Windows on Team and Enterprise, and for the Claude desktop app on Amazon Bedrock, Google Cloud Vertex AI, and Microsoft Foundry, deployed through MDM. Supported vendors are listed in the Help Center.

The order to do this in

1. Open the security center and download the report. It is read-only and takes ten minutes. Use it to find the gaps the rest of this list should close.
2. Write the incident runbook: sign-out API call, API key revocation, scheduled-task check. Test the sign-out call on a test account.
3. Turn on outside-account blocking in Claude Desktop for managed machines.
4. Roll out the IP allowlist after you have collected every egress address: offices, VPN, CI, proxies. Announce it to remote staff first.
5. Talk to your EDR vendor about the Cowork sensor if your users run Cowork locally.
6. Centralized management last, and only if you run more than one Claude organization. It is the only step here that cannot be undone.

For the rest of the admin surface, see Claude admin controls and security and privacy for Claude admins. If you are still choosing a plan, most of this list is Enterprise-only; Team vs. Enterprise for IT covers the trade.

Announcement: More visibility and control over Claude Enterprise for security teams. Docs: IP allowlisting.