Secrets, Identity, and Access 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

Store keys and secrets 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 is a durable, hard-to-revoke leak. Use separate keys per environment (dev/staging/prod) so a compromise in one environment doesn't expose another, rotate keys on a schedule, and revoke immediately on exposure.

Identity, Authentication, and Authorization

• Identity & authentication -- validate the caller's identity; authenticate every request rather than assuming a request is legitimate because it reached the system.
• Authorization / access-level verification -- verify the caller is approved for the specific action and data, at the right access level (least privilege), *before* the agent acts on their behalf. An agent acting with the caller's identity should never have broader access than the caller itself would have.
• Access monitoring -- log and monitor authorized (and attempted) access so misuse is detectable, not just theoretically preventable.

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.

Common exam traps

• Hard-coding or committing an API key is the classic leak pattern this domain tests for -- exam items reliably reward env/secret-store storage, environment scoping, and rotation over any form of embedding a key directly in code, prompts, or logs.
• Assuming authentication alone is sufficient. Authenticating *who* the caller is does not verify *what* they're authorized to do -- authorization/access-level verification is a distinct, additional check before the agent acts.