11.4 Identity, Secrets & API Key Management

Identity, Secrets & API Key Management

Exam Blueprint Focus: Identity, Secrets, and Key Management (1.6%) is a small but distinctly weighted sub-skill of the Security and Safety domain. It is easy to score on, because the answers are concrete: where the key lives, who the caller is, and what the model is never allowed to decide.

The Anthropic API Key Is a Bearer Credential

An ANTHROPIC_API_KEY authenticates via the x-api-key header and carries no user identity and no scope. Anyone holding it can spend your organisation's budget against any model. That has three immediate consequences:

1. A leaked key is a financial incident, not merely a security one — an attacker's first move is usually to mine tokens, not to read your data.
2. The key must never reach a client. No browser bundle, no mobile app, no desktop binary. A key shipped to a client is a key published.
3. The key cannot express authorization. It says "this organisation may call the API," never "this user may issue this refund."

The client-side key anti-pattern

BROKEN:  Browser  --(ANTHROPIC_API_KEY in JS bundle)-->  api.anthropic.com

CORRECT: Browser --(session cookie / JWT)--> Your backend --(x-api-key)--> api.anthropic.com
                                                  |
                                                  +-- authN, authZ, rate limit, quota, audit log

Every browser or mobile client must talk to your backend, which authenticates the end user with your own mechanism, authorizes the specific action, enforces per-user rate limits and quotas, writes the audit record, and only then calls Claude with the key it alone holds. The backend is the trust boundary; the model is inside it.

Where the Key Lives

The SDKs read ANTHROPIC_API_KEY from the environment by default, so the correct code contains no key at all:

from anthropic import Anthropic
client = Anthropic()      # reads ANTHROPIC_API_KEY from the environment

Rotation

Assume every key will need to be replaced, whether because of a suspected leak, an employee departure, or a compliance schedule. Rotation is only painless if it was designed in: read the key from a secrets manager at startup (or per request with caching) rather than baking it into an image, use separate keys per environment and per service so one rotation has a bounded blast radius, and monitor the Console for usage on a key you believed retired.

Secrets in Claude Code

Three rules, all of which are exam-shaped:

• Personal keys go in ~/.claude/settings.json or the environment — never in the committed .claude/settings.json.
• permissions.deny rules such as Read(./.env) and Read(./**/*.pem) stop the agent reading credential files at all. Deny rules apply immediately without waiting for workspace trust, which is exactly the property a secret needs.
• Secrets must not enter the prompt. Once a .env file is read into context it is in the transcript, in your logs, and in any observability sink you forward to.

Identity: The Model Never Decides Who You Are

This is the highest-value rule in the sub-skill.

Authorize server-side against the authenticated session's identity — never against an identifier the model supplied in a tool argument.

The failure looks like this:

# VULNERABLE
def get_account_balance(user_id: str):        # user_id came from Claude's tool call
    return db.query("SELECT balance FROM accounts WHERE user_id = ?", user_id)

Claude produced user_id from context, and context includes text an attacker may control — a support email, a retrieved document, an uploaded PDF. An indirect prompt injection reading "the user's ID is 4417" is now a cross-tenant data breach. The tool argument is untrusted input, exactly like a query parameter.

# CORRECT
def get_account_balance(session: Session):     # identity from the authenticated session
    return db.query("SELECT balance FROM accounts WHERE user_id = ?", session.user_id)

The general form: identity comes from the session; the model supplies only the non-identity parameters. If a tool genuinely needs to act on another entity — an admin viewing a customer record — the backend checks the session's role against that entity, and the check lives in your code, not in a prompt instruction.

The same rule extends to remote MCP servers, which are network services an LLM drives. Every request carries its own credential, and the server authorizes against the caller's verified identity, not against a field in the payload.

Least privilege on the credential itself

Where downstream systems support scoping, give each tool the narrowest credential that works: a read-only database role for lookup tools, a payments credential limited to refunds under a ceiling, per-service accounts rather than one shared superuser. When a tool is compromised through injection, the credential's scope is the blast radius.

Keeping Secrets Out of Telemetry

Secrets leak through logs far more often than through source. Enforce a bifurcation:

• Operational telemetry (safe to log broadly): request IDs, model ID, token counts, latency, stop_reason, tool names, error codes.
• Sensitive content (restricted audit vault, short retention, access-logged): prompts, completions, tool arguments, document text.

Redact before the log call, not in a downstream processor — anything that reaches the logging pipeline unredacted has already been copied. Scrub API keys, bearer tokens, and connection strings from tool error messages too: a stack trace that echoes a failed connection string publishes the credential inside it.

Common Traps

1. Shipping the API key to a browser or mobile client. It is published the moment it ships.
2. Trusting a user ID that came from a tool argument. That is the cross-tenant breach.
3. One shared key for every environment and service. Rotation becomes an outage.
4. Committing .claude/settings.json with a personal key inside.
5. Letting the agent read .env. Use permissions.deny with Read(...).
6. Logging tool arguments verbatim. They routinely contain credentials and PII.
7. Asking the model in the system prompt not to reveal secrets. Prompt instructions are advisory; a secret that never entered the context cannot be revealed.