On November 5, 2026, Anthropic added a beta Enterprise Admin API action to sign a member out of Claude. Responders can end sessions during an account investigation without removing the member. Some work can still continue under that person's authority after the reset.
Anthropic's launch announcement explicitly excludes API keys, running cloud sessions, and scheduled routines. Build the incident procedure around those remaining paths. A successful sign-out belongs in the response record; it cannot close the whole incident.
The checks below are recommendations based on current documentation. General Analysis has not tested this beta against an Enterprise tenant.
Prepare the responder's access#
The endpoint is POST /v1/organizations/users/{user_id}/sign_out. It takes no request body. Use the member's ID from the user-management API, and follow its current beta request requirements. An organization that is not enrolled receives organization_not_enrolled_in_beta; a production incident is a poor time to discover that limitation.
Have the parent organization's primary owner create an organization-bound responder key in advance. Anthropic's key-creation guide requires write:members for sign-out and read:members for member lookup. Scopes are fixed when a key is created. Keep the secret in your approved secrets manager and put only its reference in the runbook.
List each Enterprise organization with its responder key, authorized operator, and evidence collector. The sign-out key is bound to one organization. Linked organizations need separate member-write keys even if one parent-level key collects their reports.
If the API is unavailable to your organization, prepare the documented Members-page sign-out action as a fallback. It has the same exclusions. The primary owner cannot be signed out by another member, so that account needs a separate recovery procedure.
See how your AI systems hold up under real attacks
General Analysis maps AI applications and agents, red teams prompts, retrieval, tools, MCP servers, browser actions, permissions, and business workflows, then turns findings into evidence your team can reproduce and retest.
Resolve the account and organization scopes#
Consider a hypothetical lost laptop whose owner belongs to a Research organization and a Production organization. The responder calls sign-out with Research's key and receives 200. The call for Production returns 503.
The first result ends the person's account sessions across organizations and any individual plan. OAuth revocation has a narrower boundary: it covers tokens issued for Research. Production's result remains incomplete. Anthropic documents these scopes separately, including account-level OAuth tokens that this action cannot revoke.
Record one result per organization. Seeing the user logged out of Research does not settle Production's failed request. Retain the partial response and retry; access already removed stays removed.
Before the reset, address the route back into the account. Follow the lost-device procedure: sign the person out of the identity provider or disable the identity as appropriate. A still-active identity-provider session or mailbox can let the device holder return. Where SCIM manages membership, coordinate removal there. Removing a Claude membership while leaving automatic provisioning active can allow it to be recreated.
Verify the member lookup before acting. The email filter tolerates address variants, so compare the returned identity with the incident's subject record. Keep the resolved user_id and organization together in the evidence trail.
Interpret the response before closing the action#
Use this table as a response checklist. The behavior comes from Anthropic's sign-out contract; the closure conditions are our recommendations.
| Observation | Required follow-through |
|---|---|
| HTTP 200 | Save the result for this organization. Continue the token, re-entry, and autonomous-work checks. |
| HTTP 503 | Some revocations may already have happened. Retry and reconcile the eventual result; preserve both attempts. |
| HTTP 429 | Honor retry-after. Keep the organization pending while the shared Admin API budget recovers. |
| A sign-in was already underway | It can finish up to five minutes after the request. Follow the documented repeat-sign-out procedure. |
| An organization OAuth token still works immediately afterward | Revocation can take up to one hour. Verify denial within that bound and investigate continued access. |
| A cloud session reports an authentication error | Inspect the session again. It can obtain new credentials and continue without another user sign-in. |
Keep the five-minute sign-in race separate from the one-hour token-revocation bound. Neither is a waiting period after which all work becomes safe. While a token may still work, contain access to sensitive destinations through the controls your organization already operates.
A missing sign-in event is also limited evidence. Anthropic says app sign-ins such as Claude Code are absent from the cited audit surfaces. If one was underway, its procedure calls for repeating sign-out after five minutes. Push-notification cleanup is asynchronous, and a 200 does not confirm that cleanup or the reset of remembered two-step-verification skips.
Find the work that sign-out leaves behind#
Review API keys, active Code cloud sessions, scheduled or GitHub-triggered routines, and Cowork-linked computers as separate incident items. The member-management documentation confirms that sign-out preserves membership and does not unlink Cowork computers. The API contract also leaves Admin API keys valid and data on the device untouched. Delete affected Admin keys in Organization settings > API > Keys, and keep device recovery in the response.
For scheduled work, open each task's detail page and inspect its repositories, connectors, triggers, and API tokens. The scheduled-task guide documents those fields and the schedule's on/off switch. Review every trigger and its authority; do not treat a schedule change as evidence about an already-running session.
Read the run transcript and inspect affected destination records. Anthropic distinguishes a session's ending status from completion of its assigned work: even a Succeeded row can contain blocked requests or missing tools. Conversely, an error during the account reset cannot establish that no earlier write reached a repository or connected service.
Give each remaining resource an owner and a specific disposition: restrict its credential, stop or retire the work through its supported controls, recover the linked computer, or record an approved exception. Keep identifiers and evidence before destructive cleanup. The coding-agent security baseline covers the surrounding credential and tool boundaries; Claude account restrictions addresses durable account-access policy.
Keep an incident record that can remain incomplete#
Use an application-owned record like the example below. Its fields and values are illustrative; this is neither an Anthropic response schema nor the result of a live exercise. Store evidence links in the incident system and omit secret values.
Code source: illustrative.
incident: lost-device-example
member_id: user_example
organization: production-example
responder_key_ref: secret-store/claude-production-responder
identity_reentry: blocked-and-verified
sign_out:
attempts: 2
latest_http_status: 200
evidence_ref: incident/response-2
oauth_denial: pending-verification
concurrent_signin_followup: pending
remaining_authority:
- resource: scheduled-review-example
owner: repository-admin
state: unresolved
next_action: inspect-triggers-and-active-runs
containment: open
This record stays open because token denial and a routine remain unresolved. Blocking re-entry and receiving 200 are useful progress, but the incident summary must retain the unfinished items.
Correlate the request with org_user_trusted_devices_revoked. Anthropic records completed sign-outs in the audit export and, when available, the Compliance Activity Feed. Partial requests appear in the feed with completed: false but not in the audit export. Consult the event description and retain request evidence when feed coverage is unavailable. Our Compliance API guide explains the surrounding collection limits.
Before rollout, walk an authorized test account through the two-organization case, a failed request, a concurrent sign-in, and a routine that already exists. Record observed outcomes separately from the expected ones above. Close the containment item only when each applicable authority has evidence of removal or an explicitly accepted exception; leave unknown resources open with a named responder.
Frequently asked questions
- Does Claude's sign-out API remove a member from the organization?
No. It preserves the member's seat and role, and the person can sign in again. Keeping someone out requires a separate identity or membership action. If SCIM manages membership, perform removal through the identity provider.
- Does signing out stop Claude Code cloud sessions and routines?
No. Anthropic documents that cloud sessions can obtain new credentials and continue, while routines keep starting sessions. Review those resources and their downstream permissions separately, even after the sign-out request succeeds.
