7.4 — Identity, Secrets, and Key Management

CCDV-F Domain 7 · Task 7.4

What You Need to Know

Three jobs: managing secrets/credentials/API keys; identity validation and authentication; authorised access monitoring.

Where Keys Live

Anything shipped to a client is public. The client talks to your backend, which holds the credential and calls Claude. Benefits: credential off the client; place to authenticate the end user; enforcement point for per-user rate limiting and quota.

Keep keys in a secrets manager, injected at run time. Distinct key per environment. Environment read, never a literal.

Key Types

Type	Identity
Personal key	Acts as the user it belongs to
Service account key	Acts as a service account — for shared/automated workloads
Workspace key	Acts as no one; legacy

Expiration chosen at creation (3h / 1d / 7d / 30d / custom / Never); cannot be changed. Limits lifetime of a leaked credential but is not a substitute for secret hygiene.

Workload Identity Federation — workload exchanges an IdP identity token for a short-lived Claude token. No sk-ant-api... string to mint, distribute or rotate.

Exposure Playbook (Order Matters)

1. Kill the credential — disable, delete or rotate first
2. Remove it from wherever it leaked — git history, build caches, CDN, screenshots
3. Fix the design that put it there
4. Review the access logs for unauthorised use

Admin API can only read, rename and change status of existing keys (not provision).

Verification and Attribution

Authenticate at the edge; verify level at the point of use, per action. Agent acting on somebody’s behalf carries that person’s authority in its tool calls. Distinct key per service so an anomalous spike names its source. Usage and cost attribution runs per key and per workspace.

Offboarding: personal keys stop and are archived when owner is removed; service account keys keep working unless the service account is archived; workspace keys keep working whoever created them.