Anthropic Adds Personal and Service-Account API Keys: Build the Offboarding Test

The Key Is Now an Identity Decision

Anthropic's August 27 release note says that personal and service account keys can now be created in the Claude Console. Both act with the permissions of the linked identity and stop working when that account is removed from the organization. They can be limited to one workspace or used across workspaces the identity may access. Workspace keys remain supported, but Anthropic now labels them a legacy option.

That produces three credentials with different owners and different offboarding semantics:

The second row is the important correction. Replacing a workspace key used by production with a personal key does attach an identity, but it attaches the wrong one. The next employee departure becomes a production credential rotation. Anthropic's authentication guidance says personal keys are for your own tooling and service account keys are for shared or automated workloads. Use that rule as the first gate, before thinking about scope or expiry.

Inventory the Four Links

Do not start the migration with a search for sk-ant-. Start with one register row per deployed credential and four links: secret to runtime, runtime to workload, workload to identity, and identity to workspace. Record the key ID or Console name rather than the secret value; the type; linked person, service account, or workspace; single-workspace or multi-workspace scope; every secret-manager path and injection point; the owner who can rotate it; and one canary request that proves it still works.

A useful inventory row looks like this:

credential: claude-api/payments-prod
console_key: key_payments_prod_2026_08
type: service-account
identity: svc-payments-ai
workspace: wrkspc_payments_prod
injected_into: [payments-worker, refund-review-worker]
canary: POST /v1/messages with max_tokens=1
expected_workspace_header: wrkspc_payments_prod
rotation_owner: platform-oncall

The injected_into list is where most offboarding plans fail. Rotating one secrets-manager record is not enough if an old value also lives in a CI variable, a container environment, or a developer shell profile. The broader discovery discipline in the AI authentication migration plan applies here: inventory issuers, verifiers, stores, clients, workers, and administrative paths from evidence, not memory. The Claude-specific setup and request basics remain in the Claude API chapter.

Choose Scope Before You Deploy

A key created for one workspace works only there and lets requests omit the workspace ID. An identity-backed key that is not limited to one workspace must send anthropic-workspace-id on every request. That header is not decorative routing metadata: an omitted required header is a documented 400, while an unknown workspace or one the identity cannot access is a documented 404. A personal or service account key can reach Admin API endpoints only when it is not scoped to one workspace.

Migrate One Workload Without a Flag Day

For a production workload currently using a workspace key, make the credential change boring:

1. Create the workload identity. Ask an organization admin to create a service account and add it only to the integration's workspace.
2. Create a service account key. Prefer single-workspace scope unless the runtime has an evidenced cross-workspace requirement. Store the value in the existing secrets manager under a new version, never in source.
3. Deploy in parallel. Add a runtime selector such as CLAUDE_CREDENTIAL_VERSION=identity-v1. Keep the old workspace-key version available for rollback; do not make application code know either secret.
4. Canary the real path. Send a small Messages request through the same network, SDK, and runtime identity as production. Verify success and confirm the returned anthropic-workspace-id matches the intended workspace.
5. Shift and observe. Move one instance or a small traffic slice, compare authentication errors and request counts, then move the rest. Roll back the selector if the new credential fails.
6. Retire the old key. Anthropic's documented migration deletes the workspace key after success. An operationally safer checkpoint is to disable it first, because disable is reversible, observe for one normal workload cycle, and then delete it. Deletion is permanent and archives the key.

The canary proves the new secret works. It does not prove the identity boundary. That needs a negative test.

The Offboarding Test Is a Matrix

Run this in a non-production organization or with disposable test identities. Create one person and one service account that both have access to workspace A. Give the service account, but not the person, access to workspace B. Create multi-workspace personal and service account keys so the test names its workspace explicitly. Keep a third control identity unchanged. The score is not "the removed key failed." The score is all four outcomes together:

1. Before removal, the personal and service account keys both succeed in workspace A.
2. The personal key fails in workspace B before removal, proving the fixture is actually scoped.
3. After removing the person from the organization, the old personal key no longer succeeds in workspace A.
4. The service account and control requests still succeed in their expected workspaces.

Do not assert that person removal returns a particular HTTP status unless you have captured and contract-tested that behavior for your account. Anthropic promises that the key stops working, not a specific offboarding response code. Assert "not 2xx" and record the body. The workspace-membership negative case is narrower: the documentation specifies 404 when the workspace does not exist or the identity lacks access.

#!/usr/bin/env bash
set -u

probe() {
  local label="$1" key="$2" workspace="$3"
  local code
  code=$(curl -sS -o "${label}.json" -w '%{http_code}' \
    https://api.anthropic.com/v1/messages \
    -H "x-api-key: ${key}" \
    -H 'anthropic-version: 2023-06-01' \
    -H 'content-type: application/json' \
    -H "anthropic-workspace-id: ${workspace}" \
    --data '{"model":"claude-sonnet-5","max_tokens":1,"messages":[{"role":"user","content":"Reply OK"}]}')
  printf '%-28s %s\n' "$label" "$code"
}

probe personal_workspace_a "$PERSONAL_KEY" "$WORKSPACE_A"
probe personal_workspace_b "$PERSONAL_KEY" "$WORKSPACE_B"
probe service_workspace_a  "$SERVICE_KEY"  "$WORKSPACE_A"
probe service_workspace_b  "$SERVICE_KEY"  "$WORKSPACE_B"
probe control_workspace_a  "$CONTROL_KEY"  "$WORKSPACE_A"

Save the five status codes and response bodies as the baseline. Remove the disposable person from the organization, run the identical script, and diff the results. Then re-invite the person and run it once more: Anthropic says removal archives personal keys and that reinvitation does not restore them, so the old personal key must remain unusable. Create a new key for the returning user instead of trying to revive the archived one.

Test service-account offboarding separately. First remove the disposable service account from workspace B only. Its request to B should become the documented 404 while its request to A and the personal control remain successful. Then, if you need to test full workload retirement, archive a disposable service account and assert that its key no longer succeeds anywhere while unrelated identities remain green. Never use a live production identity to prove the test harness.

When a Static Key Is the Wrong Destination

If the workload already runs with AWS IAM, Google Cloud identity, GitHub Actions OIDC, Kubernetes identity, or another supported OIDC issuer, consider Workload Identity Federation instead of minting another long-lived key. WIF exchanges the provider's JWT for a short-lived Anthropic access token bound to a service account. It removes the static Claude key from the runtime, but it does not guarantee end-to-end security; the upstream identity provider and its rules remain part of the trust chain.

There is one cutover trap specific to federation: ANTHROPIC_API_KEY has higher credential precedence and can silently keep winning. Configure federation in parallel, verify the selected credential source, remove the old key from every container, CI secret, and shell profile, verify again, and only then delete the key. A green API response alone cannot tell you that federation won.

The Exit Criterion Is Selective Failure

The migration is complete when the new workload identity serves production, the old workspace key is deleted, every injection point is accounted for, and the offboarding matrix fails selectively. Removing a person must disable that person's old key without disabling the service. Removing one service-account membership must close that workspace without closing a workspace it still owns. Archiving a disposable service account must stop its keys without touching the control identity. That is stronger evidence than "rotation succeeded," because it tests the lifecycle consequence you adopted identity-backed keys to obtain.