7.3 Identity, Secrets, and Key Management

Securing a Claude application includes the ordinary identity and credential hygiene any production system needs — the model does not change these requirements. API keys and secrets belong in environment variables or a secrets manager. They must never be hard-coded in source, committed to version control, or pasted into prompts or logs — each of those creates a durable, hard-to-revoke leak that outlives the moment it happened.

Notice what makes each of those three wrong locations especially dangerous: they persist. A key hard-coded in source lives on in every clone of the repository and every deployed build until someone finds and removes it. A key committed to version control lives on in git history even after it's deleted from the current file — removing the line doesn't remove the commit. A key pasted into a prompt or log can be captured by anything downstream that has access to prompts or logs: observability tooling, a debugging session, a support ticket with a pasted transcript. None of these are one-time exposures; they're durable ones, which is exactly why rotation and revocation exist as separate, ongoing practices rather than one-time setup steps.

• •Belongs: environment variables, a dedicated secrets manager.
• •Never belongs: hard-coded in source, committed to a repo, pasted into a system prompt, written to logs.
• •Scope per environment — dev, staging, and prod each get their own keys.
• •Rotate on a schedule, and revoke immediately the moment a key is exposed.

Authentication and authorization are distinct checks, and skipping either one leaves a gap. Identity and authentication mean validating the caller's identity and authenticating every request, rather than assuming a request is legitimate simply because it reached the system. Authorization — access-level verification — means separately confirming the caller is approved for this specific action and this specific data, at the right access level, before the agent acts on their behalf. An agent acting with a caller's identity should never end up with broader access than the caller would have directly.

This distinction matters most exactly where it's easiest to collapse: an agent that proxies requests on behalf of a human user. It's tempting to treat "the request came from an authenticated session" as the whole security story, but authentication only answers who is asking. A correctly authenticated user might still not be entitled to the specific record, tool, or action their request implies — a support agent authenticated as themselves should not thereby be able to ask the system to pull another customer's billing history just because the session is valid. Authorization has to be checked per action and per data item, every time, not assumed once at login and carried forward.

The last piece is access monitoring: log and monitor authorized (and attempted) access so misuse is detectable, not just theoretically preventable by the controls above. A system that authenticates and authorizes correctly but keeps no record of who accessed what still can't answer "was this misused?" after the fact — detection is a distinct requirement from prevention.

Attempted access deserves equal billing with authorized access in what gets logged. A denied authorization check is itself a signal — a single denial is probably a legitimate mistake, but a pattern of repeated denials against different records from the same caller is exactly the kind of thing that indicates probing or a compromised credential. If only successful, authorized actions are logged, that signal never surfaces, and the system loses its best early warning that something is wrong before any data has actually been exposed.

Worked example: which is a safe way to handle an API key? Store it in an environment variable or secrets manager, scoped per environment and rotated — not hard-coded in source, not committed to the repo "for the team," and not pasted into the system prompt. Secrets belong in env/secret stores, never in code, version control, or prompts.

It's tempting to treat an existing Zero Data Retention (ZDR) agreement as a single switch that covers everything an organization does with Claude. That assumption is exactly what creates a scoping surprise later. ZDR eligibility varies by model and by platform, and it is not automatically guaranteed just because an organization already has a ZDR agreement in place. Not every current model is ZDR-eligible, and this isn't limited to the direct Claude API -- it applies just as much across Amazon Bedrock, Google Vertex AI, and Microsoft Foundry.

Concretely, a team could have a fully executed ZDR agreement at the organization level, deploy a newer or higher-capability model that simply hasn't had its ZDR status confirmed yet, and discover mid-project that the specific model/platform combination they picked isn't covered -- even though 'ZDR' appears in their contract.