What You Need to Know
This topic covers three jobs that developers usually treat as one. They are managing secrets, credentials and API keys across development and production; identity validation, authentication and level verification; and authorised access monitoring. A credential proves a caller may use the Claude API. Identity is whose authority a request carries. Attribution is knowing, afterwards, which caller made a request.
This lesson uses one made-up example throughout: a company that runs an online learning platform. A Claude chat assistant on its website answers questions from learners about their courses. A second service drafts replies to billing enquiries. A contract developer built both services on one personal key. The key was made under her login in the company's organisation.
Where Keys Live, and Why the Client Cannot Hold One
Learn the rule as a result of distributing code, not as a list of forbidden places. Anything that you ship to a client is public: a JavaScript bundle, a mobile binary, a desktop application. The running code must read the credential, so anyone who runs the code can read it too. Minification, renaming and encoding are obfuscation, not secrecy: the code reverses them on every start. The same reasoning applies to source control, log lines, screenshots and the prompt itself. Each one is a copy that continues to exist after the moment it was needed, and it goes to places that you did not plan. Every visitor can read a key in the learning platform's chat assistant.
The fix is a boundary, a backend between the client and Claude, not a better place to hide the key. The client sends its requests to your backend. The backend holds the credential and calls Claude. This boundary gives three benefits. It removes the credential from the client. It gives you a place to authenticate the end user and authorise what they may ask for. A direct call never had that place. And it is the point where you enforce per-user rate limiting and quota, so one user cannot spend the whole organisation's budget. The learning platform's chat box sends text to its server. The server adds the key, calls Claude and limits each user.
Keep keys in a secrets manager or the platform secret store. The keys are injected at run time. Use a distinct key for each environment. Never share a key between development and production. Then a leak from a laptop repository is not a production incident. In code, the key is read from the environment, never written as a literal. The company's server and the contractor's laptop hold different keys.
import anthropic
# The SDK picks up ANTHROPIC_API_KEY from the environment. Injected at run time
# from a secrets manager, distinct per environment, never a literal in source.
client = anthropic.Anthropic()Claude Managed Agents has its own secret store, called vaults. As of September 2026, vaults are in beta. You register the third-party credentials of an end user once. Then you reference the vault by ID when you create a session. An environment_variable credential is in the sandbox as an opaque placeholder. The real secret replaces the placeholder at egress, when traffic leaves the sandbox. The agent never sees the value. When a secret is rotated, running sessions get the new value without a restart. The secret replaces the placeholder only in outbound traffic. So a token that the sandbox fetches with the stored secret arrives unredacted. An exchange-based flow sends a stored secret and gets a token back. One example is a client-credentials grant, where a service sends its client ID and secret and receives an access token. Run exchange-based flows yourself and store the resulting token. Vaults are also workspace-scoped, so any key with workspace access can reference them.
Lifetime, Rotation, and the Exposure Playbook
A static key is an sk-ant-api... secret. It is sent as a bearer token in the Authorization header. Every client SDK reads it from ANTHROPIC_API_KEY. As of September 2026, the docs describe the older x-api-key header as legacy, but it is still supported. The documented good practice is: store API keys in a secrets manager, rotate them periodically, and disable or delete any key you suspect has leaked. You can undo a disable. A delete archives the key permanently.
Each key has a type. You choose the type when you create the key, and the type decides whose identity the key carries. A personal key is identity-backed: every request made with it acts as the user it belongs to, with their roles. A service account key acts as a service account. The docs name the service account as the identity for shared or automated workloads, such as CI and production services. Such a workload has its own identity and does not break when a person leaves. A workspace key acts as no one and belongs to its workspace. It still works, but the docs call it legacy and prefer identity-backed keys or Workload Identity Federation. On the contractor's key, both services act as her. They belong on a service account key.
Expiration is often mistaken for the answer. You choose the expiration when you create the key. The options are a preset of 3 hours, 1 day, 7 days or 30 days, a custom duration, or Never. You cannot change it afterwards. An expired key returns a 401 authentication_error, and you cannot reactivate it. The docs say expiration limits the lifetime of a leaked credential but is not a substitute for secret hygiene (careful handling of secrets). If the company chose Never, it cannot shorten the expiration after a leak. Only disabling or deleting the key stops it from working.
Workload Identity Federation is the structural improvement. The workload has an identity token from an identity provider (IdP) that you already trust. At POST /v1/oauth/token, the workload exchanges that token for a short-lived Claude token. The SDK refreshes the Claude token automatically. There is no sk-ant-api... string to create, distribute or rotate. The docs give one caveat. The trust chain is only as strong as the configuration of the identity provider. A long-lived secret one step earlier in the chain still weakens the trust chain.
The response to an exposed key has four steps, in this order.
- Stop the credential from working. Disable, delete or rotate it. Until the exposed key stops working, the attacker still has a working credential while you do the other steps. So every other step waits.
- Remove it from wherever it leaked. Git history, build caches, copies on a content delivery network (CDN) and screenshots keep their own copies. So when you delete the current file, you have not removed the key.
- Fix the design that put it there. That design is usually the client-side architecture, not a careless commit.
- Review the access logs for use you did not authorise. Only then decide whether the incident is closed.
If the learning platform's key appears in its JavaScript, the company disables the key first. Then the company removes the key from git history and the CDN, moves the call server-side and checks the logs.
In code, step one is an Admin API call that updates the key's status. inactive disables the key reversibly, and archived is the permanent delete. You create API keys only in the Claude Console. The Admin API can only read, rename and change the status of existing keys. So that API is for revoking and auditing keys, not for creating them.
# An Admin API key (sk-ant-admin...) goes in the x-api-key header.
curl --request POST "https://api.anthropic.com/v1/organizations/api_keys/$KEY_ID" \
--header "anthropic-version: 2026-10-21" \
--header "content-type: application/json" \
--header "x-api-key: $ANTHROPIC_ADMIN_KEY" \
--data '{"status": "inactive"}'Verification at the Point of Use, and Attribution After the Fact
Authenticate the caller when the request first reaches your backend. Then verify the level at the point of use: for each action, not once at entry. An elevated operation re-checks entitlement. It does not reuse the answer that the session got when it opened. An agent that acts for a person carries that person's authority in its tool calls, not the authority of a service account. Approval flows belong here too. They cover who may authorise an elevated action, and how that decision is recorded so that it can be produced later. A learner who signed in an hour ago is still re-checked before a refund.
Monitoring gets skipped because nothing signals a monitoring failure. Yet scenarios test it. You cannot investigate a key that has no attribution. If three services share one credential, an anomalous spike identifies none of them. The first fix is a distinct key for each service. This fix comes before any better alert, so that the alert has a source to identify. Usage and cost attribution works per key and per workspace. So if you scope keys by project or environment, every line of spend is linked to a caller. With one key for each of the company's services, a spike identifies its source.
The Admin API lists keys with their status, workspace and expires_at. So you can audit rotation instead of remembering it. The Usage and Cost API and the Rate Limits API report the numbers. The Compliance API Activity Feed holds the audit record.
For Claude Code, as of September 2026, the audit source is OpenTelemetry events. OpenTelemetry is an open standard for collecting logs, metrics and traces from software. OTLP is its transfer protocol. The OTLP logs exporter delivers these events. They connect tool calls, MCP activity and permission decisions to the user who triggered them. Two settings decide whether that record answers "who ran this". Tool arguments, such as the Bash command, are logged only when you set OTEL_LOG_TOOL_DETAILS=1. A session that is authenticated with an API key carries no account. So attach the identity of each person with OTEL_RESOURCE_ATTRIBUTES through managed settings.
The organisation roles are user, claude_code_user, developer, billing and admin. Workspace roles are separate. So the question "who may manage keys" has a concrete answer. Offboarding removes a person from the organisation, and its effect depends on the key type. Personal keys stop working and are archived when their owner is removed. Service account keys keep working unless the service account itself is archived. Legacy workspace keys keep working no matter who created them. So when you remove a person who has left, their personal keys stop working. That is why a production service should never run on a personal key. Removing the contractor would stop both services that day.
In the exam
The guide asks for all three jobs together. Questions on this topic are rarely about whether a practice is good. They ask which step comes first, and every wrong answer is a real step in the wrong order. Or they ask whether the scenario needs prevention or attribution. For the backend boundary, count three benefits, because wrong options usually fix only the first. Two documented details make good questions: the organisation roles, and what offboarding does to each key type.
A Dated Exception: App Attest
Verified 2026-08-21, this exception is narrow. App Attest lets a genuine, attested installation of a registered iOS or macOS app call the Claude API directly, with no back end or proxy. The installation proves that it is genuine through Apple's App Attest service. Anthropic then issues short-lived tokens that are scoped to your workspace. These tokens expire after one hour and authorise only Messages API calls. App Attest is an attestation mechanism for native apps. It is not permission to put a key in a web page, and a browser bundle remains the wrong architecture. The learning platform's website still needs its server.
Exam Traps
Answering the exposure scenario with server-side calls and a secrets manager while the exposed key stays valid
Both steps are right but come later. Every hour spent building them is an hour the exposed key still works. Disable or rotate the key first, then fix the design.
Treating expiration, a shorter time to live or a rate limit as the control that fixes a leaked key
Expiration limits how long a leaked credential stays usable, but the docs call it no substitute for secret hygiene (careful handling of secrets), and it is fixed at creation. A workspace rate or spend limit caps the bill, not access. Disable or delete the key.
Assuming an identity check at the session boundary covers a privileged action later in the session
Authentication at the start of the session answers who the caller is, once. Authorisation has to be answered per action, at the point of use. An agent acting on somebody's behalf carries that person's authority in its tool calls, not a service account's.
Reading an attribution scenario as a prevention scenario, and answering with throttling, alerting or heavier logging
The gap is a shared credential with no per-caller identity, and throttling cannot supply one. A key per service in its own workspace links every line of spend to a caller.
Practice Scenario
A company that sells customer relationship management (CRM) software runs three services on one production Claude API key: a sales-email drafter, a call-note summariser and a support bot. The monthly spend jumps sharply and the console shows the total but nothing about which service caused it. Finance will accept a breakdown only if it comes from the console itself. What does the team most need?
Build Exercise
Give Every Caller Its Own Identity, Then Prove You Could Investigate One
What you'll learn
- How to inventory every place a Claude credential currently exists
- How to split a shared key into per-service, per-workspace identities
- How to run the four steps for an exposed key in the documented order against a disposable key
- How to turn on the attribution you would need during an incident
- Inventory every place a Claude credential exists for your project: environment files, CI settings, deployment configuration, laptops, and anywhere a screenshot or a log line might have captured one.
Why: You cannot rotate what you cannot find, and the copies people forget are exactly the ones that outlive the rotation.
You should see: A written list, longer than you expected, with at least one entry you had not thought about.
- Split the shared key. Issue a distinct key per service, each in its own workspace. Inject each key from a secrets manager at run time. Keep development keys separate from production ones.
Why: Distinct keys give you an investigable trail and an isolated failure at the same time, which is the pair of benefits that the right answer gives in attribution scenarios.
You should see: One key per service, each visible separately in usage and cost reporting.
- Make every client constructor read the key from the environment so no literal remains in source, then grep the repository history rather than the working tree, because history is where the old copies are kept.
Why: Deleting the current file is not removal, and a history scan is the step that makes the clean-up complete.
You should see: A client constructor with no arguments everywhere, and a clean history scan or a list of commits to deal with.
- Rehearse the four steps for an exposed key against one non-production key, in order: set it to inactive through the Admin API, confirm the 401, remove it from the place it was stored, then check what the removal of a person who has left would and would not revoke.
Why: Rehearsing the order is the point, because what separates a good answer from a wrong one on this topic is which step ran first.
You should see: A 401 authentication_error from the deactivated key, and a written note on what offboarding does not touch.
- Turn on the attribution you would need in an incident: usage and cost reporting per workspace, and an alert on an unusual pattern rather than only on a monthly total. Write down the question who used this and when, next to the exact report that answers it.
Why: An alert that cannot name a caller only tells you that something happened, and the pairing of a question with the report that answers it is what makes the monitoring useful.
You should see: One named report per question, and an alert that fires on a pattern rather than at the end of the month.
Sources
- Authentication — Anthropic, the three methods, the Authorization header and the legacy x-api-key header, ANTHROPIC_API_KEY, key types, disable and delete, key expiration, Workload Identity Federation and App Attest
- Admin API — Anthropic, changing a key status to inactive or archived, Console-only creation, what happens to each key type when a user is removed, roles, workspaces and the monitoring surfaces
- Security — Anthropic, secure credential storage and OpenTelemetry monitoring for Claude Code
- Monitoring — Anthropic, OpenTelemetry events as the audit source for Claude Code, OTEL_LOG_TOOL_DETAILS and OTEL_RESOURCE_ATTRIBUTES
- Authenticate with vaults — Anthropic, Managed Agents vaults, egress substitution and its outbound-only limit
- API and data retention — Anthropic, the Compliance API Activity Feed retention and what the audit record covers
- Claude Certified Developer Foundations Exam Guide — Domain 7, Identity, Secrets, and Key Management — Anthropic