Anthropic API Keys Security Guide: Workspaces, Admin Keys and Leak Response

An Anthropic API key is a bearer secret that bills model usage to your organisation and reaches the files, batches and skills stored in its workspace, so a leaked key is both a cost incident and a data incident. Claude API keys now come in several kinds (personal, service account, legacy workspace and Admin API keys), each with different scope, lifetime and failure behaviour, and organisations often treat them all as one undifferentiated "Anthropic key". This guide explains how identity and access work in the Claude Console, how to scope and expire keys, how to replace static keys with Workload Identity Federation, what to monitor through the Usage and Cost and Compliance APIs, and how to respond when a key leaks. It is written for platform, AI engineering and secrets management teams who already run Claude workloads. For the wider threat of stolen AI keys, read the LLMjacking Guide first; this page goes deeper on Anthropic's own controls.

Key takeaways

• Know which key you are holding. Inference keys begin sk-ant-api03-, Console Admin API keys begin sk-ant-admin01-, and GitHub secret scanning recognises five Anthropic secret types, so detection rules and response steps can be precise.
• Prefer identity-backed keys. Personal and service account keys act as a principal and stop working when that principal is removed; legacy workspace keys keep working after their creator leaves.
• Scope and expire every key. Bind keys to a single workspace, choose an expiry (presets run from 3 hours to 30 days) and set an organisation maximum so "Never" is not available.
• Treat Admin API keys as privileged access. A Console Admin API key has no scopes: it can manage users, invites, workspaces and every other key in the organisation.
• Usage data is your fastest detector. Hourly usage grouped by api_key_id and model, plus workspace spend limits, catch abuse long before an invoice does.

How identity and access work in the Claude API

An Anthropic organisation is the billing and administration boundary. Inside it, workspaces separate usage by project, environment or team. Every organisation has a Default workspace that cannot be renamed, archived or deleted and cannot carry a spend limit, and an organisation can hold 100 workspaces by default (archived ones do not count). Files uploaded through the Files API, Message Batches and Skills are scoped to a workspace, and on the Claude API prompt caches are isolated per workspace, so workspace design is also a data separation decision.

Requests authenticate with an API key sent as Authorization: Bearer (the legacy x-api-key header is still accepted), with a short-lived token from Workload Identity Federation (WIF), or, for iOS and macOS apps, with an App Attest token. Anthropic's authentication documentation describes three API key types:

Keys that are not bound to a workspace must send an anthropic-workspace-id header on every request; a missing header returns 400 invalid_request_error and a workspace the principal cannot reach returns 404 not_found_error. Every successful response carries an anthropic-workspace-id header showing which workspace the request counted against, which is a useful assertion in integration tests. Claude Code keys are minted per user at sign-in, cannot be created by hand and stop working when their owner is removed.

When a user is removed from the organisation, their personal keys are archived and are not restored if the user is re-invited. That is the main reason Anthropic recommends identity-backed keys or WIF over workspace keys for new integrations: offboarding then revokes the credential automatically. See the API Key Management Guide for the general lifecycle model.

Admin roles and privileged access

Organisation roles control who can mint keys and who can manage people. Workspace roles control what a member can do inside each workspace.

Admin API keys deserve the same handling as a cloud root credential. In the Claude Console they are created at Settings, Admin keys by members with the admin role, they start sk-ant-admin01-, and they have no selectable scopes: every key can call every endpoint that accepts Admin API keys. Claude Enterprise organisations create keys with fixed scopes instead (for example read:org_audit for read-only audit integrations), and a call outside a key's scopes returns 403 Forbidden. An OAuth token with the org:admin scope reaches the whole organisation regardless of workspace binding, and the service account, federation issuer and federation rule endpoints accept only that token, not an Admin API key.

• Separate administration from inference: run admin automation from a dedicated identity and, as Anthropic suggests, a dedicated shell with ANTHROPIC_API_KEY unset, so an admin session never sends an inference key by mistake.
• Short-lived admin keys: create Admin API keys with the shortest expiry the job allows and store the secret, which is shown once, straight into a vault.
• Single sign-on and SCIM for people: member changes pushed by an identity provider appear in the Compliance Activity Feed as scim_directory_sync_actor, which gives you a clean joiner and leaver trail.

See the Service Account Security Guide for ownership and review patterns that apply equally to Anthropic service accounts.

Integrations, API tokens and service accounts

Choosing a credential

WIF exchanges an identity provider's JWT at POST /v1/oauth/token for a short-lived Claude API access token. Supported issuers include AWS IAM, Google Cloud and any standards-compliant OIDC issuer such as GitHub Actions, Kubernetes service accounts, SPIFFE, Microsoft Entra ID and Okta. Anthropic's own documentation warns that federation is only as strong as the identity provider configuration: a long-lived secret earlier in the chain can still undermine it. Pin federation rules to specific subjects (repository and branch, namespace and service account) rather than whole issuers. The Workload Identity Federation Guide covers claim matching in depth.

Third-party platforms that store your key

Coding agents, AI gateways and deployment platforms often ask you to paste a provider key, and they become a concentrated target. In the OpenCode Console breach stored OpenAI, Anthropic and Google keys were taken from a legacy system and users reported unauthorised usage within hours, and in the Railway breach an attacker decrypted customer environment variables while, Railway says, hunting for AI provider keys. Give each such platform its own service account key, in its own workspace, with a monthly spend limit and an expiry, so revocation is one action and the blast radius is one workspace. Where you run a gateway yourself, the AI Gateway and LLM Gateway Guide explains how to keep provider keys behind it.

Logging and detection

Secret scanning signatures

Anthropic keys have distinctive prefixes, which makes them high-confidence detections. GitHub's supported patterns list five Anthropic secret types, all as partner patterns for public repositories:

The open source Gitleaks default configuration has rules anthropic-api-key (keyword sk-ant-api03) and anthropic-admin-api-key (keyword sk-ant-admin01), both anchored on the prefix, a fixed-length body and a trailing AA. Note that Enterprise scoped keys begin sk-ant-api01-, so a rule keyed only on api03 will miss them; add a custom rule if you run Claude Enterprise. Anthropic is a member of GitHub's secret scanning partner programme: when GitHub finds a Claude key in a public repository it notifies Anthropic, which automatically deactivates the key and emails the affected user. That protects public GitHub only. Private repositories, other forges, container images, notebooks, chat tools and logs need your own scanning; see the Git Secret Scanning Guide and the Push Protection Guide.

Usage, cost and audit telemetry

• Usage report: GET /v1/organizations/usage_report/messages returns token usage in 1m, 1h or 1d buckets, filterable and groupable by api_key_id, workspace_id and model. Data usually lands within about five minutes, so alert only on completed buckets and poll about once a minute.
• Cost report: GET /v1/organizations/cost_report gives daily USD cost grouped by workspace, which suits reconciliation and budget alerts. Playground usage appears with a null api_key_id and the Default workspace with a null workspace_id, so bucket nulls explicitly or you will miss them.
• Key inventory: the Admin API lists keys with status, scope, principal and expires_at; a null expires_at means the key never expires.
• Compliance Activity Feed: where the Compliance API is enabled, /v1/compliance/activities records administrative and authentication activity, retains it for six years and makes events queryable within a minute. Recording starts when the API is enabled and is not retroactive, so enable it before you need it. Actions taken with an Admin API key appear under the admin_api_key_actor actor type.

What to alert on

• A key's hourly token volume several times above its 14-day baseline, or any usage from a key that is meant to be idle.
• A model appearing for a key that has never used it, particularly the most expensive tier.
• New keys with no expiry, new Admin API keys, or keys created outside change windows.
• Spend threshold alerts on any workspace, and any secret scanning alert for anthropic_admin_api_key.

Hardening baseline

Roll the baseline out in phases so production workloads do not break.

1. Inventory (week 1): list every key through the Admin API, map each to an owner, workload and workspace, and flag workspace-type keys, keys with null expires_at, and keys with no usage in 30 days. The Service Account Inventory Template gives a format.
2. Structure workspaces: create workspaces per environment and per integration, move production out of the Default workspace (it cannot have a spend limit), and set monthly spend limits and per-model rate limits on each. Workspace limits can be set lower than, never higher than, organisation limits.
3. Set an expiry policy: configure an organisation maximum expiration so "Never" disappears from the key dialog. Expiry is fixed at creation, so this only affects new keys: track old ones to replacement.
4. Migrate workloads: move cloud and CI workloads to WIF; move other shared workloads from workspace keys to service account keys scoped to one workspace. Anthropic's replacement sequence is to create the new key, deploy it, confirm requests succeed, then delete the workspace key.
5. Test, then revoke: use Disable first (reversible, Admin API status inactive) and watch for errors for a few days before Delete (permanent, status archived). Disable is your rollback path.
6. Turn on detection: enable secret scanning and push protection everywhere code lives, schedule the usage anomaly job, and enable the Compliance API if your plan includes it.
7. Review quarterly: re-certify organisation admins, developers and Admin API keys, and archive workspaces that are no longer used (archiving archives all their keys within seconds and cannot be undone).

Small teams can stop at personal keys per developer, one production service account key per application, spend limits and secret scanning. Larger organisations should make WIF the default for production, forbid workspace keys by policy, route provider access through a gateway so application teams never hold keys, and feed usage data into the SOC.

Leak response

1. Identify the key type and ID: the prefix tells you whether it is an inference key or an Admin API key; match it to the key list in the Console or Admin API.
2. Disable or delete immediately: in the Console API keys page use the key's menu, or set status to inactive through the Admin API. Do not wait for Anthropic's automatic deactivation, which applies only to public GitHub findings.
3. Issue a replacement with the same scope and a short expiry, and redeploy through your secret manager.
4. Review usage for the key ID in 1-hour buckets back to the earliest possible exposure, and check workspace files, batches and skills that the key could reach.
5. For an Admin API key, assume organisation compromise: review member and invite changes, new keys and workspace changes in the Compliance Activity Feed, and rotate every key created since the exposure.
6. Remove the secret from its source (history rewrite, image rebuild, log purge) and record the root cause. The Secrets Rotation Runbook Template provides the evidence fields.

Framework mapping

Common misconfigurations

• Production in the Default workspace: it cannot have a spend limit or be archived, so a leaked key there has no cost ceiling below the organisation limit.
• Keys that never expire: without an organisation maximum, "Never" remains the easy choice and keys outlive projects. Check for null expires_at.
• Legacy workspace keys left running: they belong to no one, survive the creator's departure and are invisible to offboarding.
• Admin API key used as an inference key: one secret then carries both billing exposure and full control of users and keys. Keep admin automation on a separate identity and host.
• One shared key pasted into many tools: when a platform such as OpenCode Console or Railway is breached you cannot tell which use was abused, and revocation breaks everything at once.
• Relying on GitHub auto-revocation: it does not cover private repositories, other forges, Docker images, notebooks or support tickets, and Enterprise sk-ant-api01- keys can slip past default scanner rules.

Practitioner checklist

• Export the full key list and assign an owner, workload and workspace to every key.
• Replace legacy workspace keys with service account keys or WIF, using disable before delete.
• Set an organisation maximum key expiration and remove "Never".
• Move production out of the Default workspace and set spend and rate limits on every workspace.
• Limit organisation admin, owner and developer roles; review them quarterly.
• Store Admin API keys in a vault with short expiry and use them only from a dedicated admin identity.
• Enable secret scanning and push protection, with custom rules for any key format your scanner misses.
• Run an hourly usage anomaly job grouped by api_key_id and model, and alert on new models and idle keys.
• Enable the Compliance API (where available) before an incident, as it does not backfill.
• Rehearse the leak response runbook, including the Admin API key path.

Standards and references

• Anthropic: Claude API authentication
• Anthropic: Workspaces
• Anthropic: Admin API overview
• Anthropic: Usage and Cost API
• Anthropic Help Center: API key best practices
• GitHub Docs: Supported secret scanning patterns
• NIST: SP 800-53 Rev 5, Security and Privacy Controls
• Gitleaks: Project repository and default rules

Related NHI Mgmt Group resources: LLMjacking Guide · OpenAI API Keys Security Guide · Workload Identity Federation Guide · Secrets Management Guide