Skip to Content
DeploymentQuarantine

Quarantine

When an incident requires removing a user’s access immediately — credentials compromised, employee terminated, suspicious activity flagged by the SOC — Arrakis composes a sequence of admin API calls against each tool’s vendor console, and pushes a corresponding block to the endpoint via MDM. This page documents what the verified API actions actually do (and do not do), and how they combine with the MDM-side block to constitute a complete quarantine.

What Quarantine actually is

Quarantine is a composite action: API key revocation, plus workspace and project removal, plus organization-level user deletion, plus an MDM-side block on the endpoint. It is not a single “kill switch”, because no upstream vendor publishes a session-termination API. The composite is the most that can be done with the surfaces the vendors expose.

Arrakis runs the composite from the platform when an admin clicks Quarantine on a user. The MDM-side block is the part that provides instant local enforcement; the vendor-API actions revoke long-lived credentials and remove the user from the org so that subsequent re-auth attempts fail. The two halves are issued together — Arrakis enforces that both a vendor admin credential and an MDM credential are configured before any Quarantine action can run.

What the vendors do NOT publicly document

This section is deliberately prominent. The Quarantine composite has gaps that are inherent to the vendor APIs, not to Arrakis, and customer security teams must understand them before relying on Quarantine as their incident response control.

  • No vendor publishes a “kill all active sessions” API. Anthropic, Cursor, and OpenAI all expose user-removal and key-revocation endpoints. None of the three documents an endpoint that immediately invalidates an in-progress OAuth session running on the developer’s machine.
  • Anthropic API keys persist after user removal. Per the Anthropic Admin API documentation , API keys are scoped to the organization, not the individual user. Quarantine must explicitly enumerate keys by created_by_user_id and deactivate each — DELETE user alone does not revoke them.
  • None of the three vendors publishes granular OAuth-style scopes for admin actions. Quarantine requires a single full org-admin credential per vendor. This is inherent to the vendor APIs, not a choice Arrakis makes.

Where vendor docs are silent on a behavior — for example, whether a DELETE user call cascades to active OAuth sessions — this page says so explicitly. For each item below labeled “verify with vendor support”, the customer should confirm cascade behavior with their TAM at the vendor before relying on it for incident response.

Per-vendor composite actions

Anthropic (Claude Code, Claude Cowork, Claude Desktop)

Required Arrakis credential. An Admin API key (sk-ant-admin...) issued by an Anthropic org admin. There are no granular scopes; this single key carries full org-admin authority.

Composite, in order:

  1. Enumerate the user’s keys: GET /v1/organizations/api_keys?created_by_user_id={user_id}&status=active.
  2. For each key returned: POST /v1/organizations/api_keys/{api_key_id} with body {"status":"inactive"}.
  3. For each workspace the user belongs to: DELETE /v1/organizations/workspaces/{workspace_id}/members/{user_id}.
  4. Remove the user from the org: DELETE /v1/organizations/users/{user_id}.
  5. (Optional, if the customer’s tenant is entitled to the Compliance API) pull the Activity Feed for forensics.

Cited references:

What is NOT verified. Whether DELETE /v1/organizations/users/{user_id} cascades to active Claude.ai web sessions, Claude Desktop OAuth, Claude Code OAuth, or CLAUDE_CODE_OAUTH_TOKEN long-lived tokens is not in public Anthropic documentation. There is no documented OAuth token revocation endpoint for Pro / Max / Team subscription tokens used by Claude Code and Claude Desktop, and no documented revocation path for CLAUDE_CODE_OAUTH_TOKEN. Org admins additionally cannot be removed via API per the Admin API FAQ. Verify cascade behavior with Anthropic support or your TAM before relying on it.

Cursor

Required Arrakis credential. A Cursor admin API key issued by a team admin. Authentication is HTTP Basic with the key as username. There are no granular scopes.

Composite, in order:

  1. Pull recent activity for forensics: GET /teams/audit-logs.
  2. (Optional soft-stop while staging removal) POST /teams/user-spend-limit with the target user_id and a limit of 0.
  3. Remove the user from the team: POST /teams/remove-member.

Cited references:

What is NOT verified. Cursor publishes no session-termination endpoint and no OAuth token revocation endpoint. The local IDE may continue to function on cached credentials until its next auth check; the MDM-side block is the only verified instant kill on the endpoint. The Cursor audit-log event-schema documentation page was not retrievable during research; verify event names with Cursor support before alerting rules hardcode them.

OpenAI Codex (via the OpenAI Admin API)

Required Arrakis credential. An Admin API key (sk-admin-...) issued by an OpenAI org Owner. Org-wide; no granular scopes.

Composite, in order:

  1. Pull recent activity for forensics: GET /organization/audit_logs?effective_at[gte]=...&actor_emails[]=user@co.
  2. For each project the user belongs to:
    1. Enumerate project API keys: GET /organization/projects/{project_id}/api_keys.
    2. Delete any key owned by the target user_id: DELETE /organization/projects/{project_id}/api_keys/{api_key_id}.
  3. For each project: DELETE /organization/projects/{project_id}/users/{user_id}.
  4. Remove the user from the org: DELETE /organization/users/{user_id}.
  5. If SCIM is the source of truth for identity, deprovision the user in the IdP — the change flows down via is_scim_managed on the OpenAI user record.

Cited references:

What is NOT verified. The OpenAI User object exposes role and is_scim_managed but no suspend or disable state — Quarantine is DELETE. The audit log records logout.succeeded events but OpenAI does not document an admin-initiated logout call. Time-to-effect of DELETE /organization/users/{user_id} on active Codex CLI / IDE sessions is undocumented. There is no documented OAuth token revocation API for the Codex CLI or IDE distinct from project API key deletion. Verify cascade behavior with OpenAI support.

The MDM block (instant kill)

The vendor APIs above revoke long-lived credentials and remove the user from the org. They do not provably terminate an in-progress session running on the developer’s machine. For instant local enforcement, Arrakis pushes a Quarantine policy via the customer’s MDM that does one or both of:

  • Block Claude Code, Cursor, and Codex from launching on the endpoint.
  • Remove the OAuth credential file from the endpoint so any subsequent launch fails to authenticate.

The exact payload depends on the customer’s quarantine policy. This MDM-side push is the only verified instant kill across all three tools. See MDM Sync → Live policy push for how Arrakis publishes the Quarantine profile to the fleet, and the per-MDM force-sync caveats that determine how quickly endpoints actually receive it.

Cross-vendor capability matrix

CapabilityAnthropicCursorOpenAI
Remove user from org via APIYesYesYes
Disable / suspend (non-destructive)NoNoNo
Revoke API key via APIYes (status: inactive)N/A — no end-user API keysYes (DELETE)
Remove from workspace / projectYesVia groupsYes
Documented session-kill / OAuth revokeNoNoNo
Audit log APICompliance API / Activity FeedGET /teams/audit-logsGET /organization/audit_logs
Granular admin scopesNoNoNo

Required Arrakis-side configuration

For Quarantine to work end-to-end the customer must provide Arrakis with the following.

  • Anthropic. An Admin API key (sk-ant-admin...), pasted into the Arrakis platform under Settings → Integrations → Anthropic.
  • Cursor. A Cursor admin API key, pasted into Settings → Integrations → Cursor.
  • OpenAI. An Admin API key (sk-admin-...), pasted into Settings → Integrations → OpenAI.
  • MDM live-push credential. The same credential used for ongoing policy management, plus the optional force-sync permission so the Quarantine MDM payload reaches the endpoint within seconds rather than waiting for the next regular check-in. See MDM Sync → Live policy push.

Arrakis enforces a strict ordering rule: any Quarantine action requires both a vendor admin credential AND an MDM credential to be present, so the API revocation and the endpoint block are always issued together. If either credential is missing, the Quarantine button is disabled in the platform.

Cross-references

Last updated on