Access reviews are standard identity hygiene: on a cadence, enumerate who and what can touch a system, confirm each grant is still needed, remove the rest, and keep evidence that you did. AI systems earn a dedicated pass for two reasons. First, credentials for model access are unusually consequential — a leaked key can exfiltrate data through prompts and run up real spend. Second, AI access has a machine-heavy shape: most "users" of your Claude integration are service credentials, and those never resign, never get offboarded by HR, and quietly outlive the projects that created them.
What to enumerate, per platform
On the Claude API, the surfaces are organization members, workspace members, and API keys. Anthropic's Admin API exists for exactly this: with an Admin API key (prefixed sk-ant-admin, provisionable only by members with the admin role) you can list organization members (GET /v1/organizations/users), list API keys with filters for status and workspace (GET /v1/organizations/api_keys), and list workspaces and their members. The documented role model gives you the review rubric: five organization roles (user, claude_code_user, developer, billing, admin) and workspace-level roles from Workspace User up to Workspace Admin — flag anyone holding admin anywhere and confirm they still need it.
On Bedrock, Vertex AI, and Foundry, model access is governed by your cloud's identity system — IAM roles and policies on AWS, service accounts on Google Cloud, Microsoft Entra identities and RBAC on Azure — so your existing cloud access-review machinery covers Claude the way it covers any other service. The AI-specific step is scoping the query: enumerate which principals hold permissions to invoke the model service, not just who can log in (see least-privilege IAM and Bedrock IAM setup). Note that on Claude Platform on AWS, only the workspace endpoints of the Admin API are documented as available — member and API-key endpoints are not — so reviews there lean on the Console and on AWS-side controls.
The trap: API keys are not tied to people
The single most important documented fact for Claude API reviews: API keys are scoped to the organization or workspace, not to individual users — and they persist when a user is removed. Offboarding a departed engineer from the organization does not disable the key they created. Your review must therefore treat keys as their own population: for each key, identify the workload it serves, the person accountable for it, and its last use; deactivate what nobody claims. The Admin API supports setting a key's status to inactive, and archiving an entire workspace immediately (and irreversibly) revokes all keys within it — useful when decommissioning a whole project. New keys can only be created through the Console, which keeps creation auditable.
A quarterly review procedure
- Enumerate. Export organization members, workspace memberships, and API keys (Admin API on the Claude API; IAM queries on the clouds). Include pending invites — Claude API invites expire after 21 days on their own, but a pile of stale invites signals process drift.
- Cross-check people. Reconcile member lists against HR's current-employee list and confirm role levels match current duties (admin roles especially).
- Cross-check machines. Map every API key and service credential to a living entry in your AI model inventory. Keys without an inventory entry are stale by definition.
- Check usage. The Usage and Cost API breaks down consumption by API key and workspace — a key with zero usage all quarter is a removal candidate; a key with surprising usage is an investigation candidate (see usage anomaly detection).
- Remediate. Remove stale members, deactivate unclaimed keys, downgrade over-broad roles. Do the removals during the review, not as follow-up tickets that die in backlog.
- Document. Record date, reviewer, populations reviewed, findings, and actions taken. This artifact is what an auditor accepts as evidence; the review without it is invisible.
Also include third-party products with access into your systems — the SaaS-with-Claude-inside category from the companion article — since vendor connections are the grants most likely to outlive their sponsor.
Cadence
Quarterly is a common baseline for standard workloads, with higher-risk integrations (customer data, autonomous action) reviewed more often and every review re-run on trigger events: a team reorganization, an incident, a departed admin. Match depth to your risk tiers so the review stays an hour, not a quarter-long project that never finishes.
Where to go next
See audit logging for the evidence trail behind reviews, and the governance checklist for where access reviews sit in the broader program.