TimoBy Amotion AI

Identity, Secrets and Key Management: CCDV-F study guide

CCDV-F · Security and Safety, topic weight 1.6% of the exam

Identity, Secrets and Key Management is a topic in Domain 7, Security and Safety (8.1% of the CCDV-F exam), and carries 1.6% on its own. It tests whether you keep Claude API keys and other credentials out of code, prompts and repositories, give each environment and person only the access they need, and can tell who used a key.

What the official guide covers

The Claude Certified Developer Foundations exam guide (version 1.0, effective July 2026) describes this topic as managing secrets, credentials and API keys across Claude development and production environments:

What the guide listsWhat it means in practice
Secrets, credentials and API keys across development and productionKeep keys in a secret manager or environment variables, never in source, prompts or the repository. Each environment has its own key.
Identity validation and authenticationEvery caller, person, service or agent, proves who it is. Prefer short-lived tokens tied to an identity over long-lived static keys.
Access approval and level verificationDecide who may create keys and at what scope, using organisation and workspace roles
Authorised access monitoringReview usage per key, rotate on a schedule and revoke at once when a key is exposed

Where a Claude API key should live

The Python and TypeScript client SDKs read ANTHROPIC_API_KEY from the environment, so your code never needs the key as a literal:

import anthropic

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

Anthropic's API key guidance adds the rest:

  • Keep .env files in .gitignore, and run a secret scanner in CI so a committed key fails the build.
  • Use separate keys for development, testing and production, so one leak does not expose everything.
  • Rotate keys on a schedule and deactivate the old ones.
  • Review usage in the Console and set spend controls.
  • Use a key management system at enterprise scale for central storage, access control and audit trails.
  • If you suspect a key is exposed, revoke it in the Console straight away.

Anthropic takes part in GitHub's secret scanning programme: if a Claude API key appears in a public repository, Anthropic is notified and deactivates the key automatically. Treat that as a safety net, not a plan.

Never put a key or password in a system prompt. Prompts can be extracted, and Claude does not need the secret to call a tool that uses it.

Nor should a key ship in browser or mobile code, where anyone can read it. The TypeScript SDK refuses to run in a browser unless you set dangerouslyAllowBrowser: true. Route calls through your own server, which holds the key.

Separate environments with workspaces

A Claude Console organisation can hold several workspaces. Anthropic's documentation suggests one each for development, staging and production. An API key can be scoped to a single workspace, so it reaches only that workspace's resources, and each workspace can have its own spend and rate limits.

Workspace roles set the level of access:

Workspace roleCan do
Workspace UserUse the playground only
Workspace DeveloperCreate and manage API keys and use the API
Workspace AdminFull control of workspace settings and members
Workspace BillingView workspace billing

For Claude Code teams on the Console, Anthropic lists two invite roles: the Claude Code role can create only Claude Code API keys, and the Developer role can create any kind of key.

Short-lived credentials instead of static keys

Workload Identity Federation lets a workload authenticate to the Claude API without a long-lived sk-ant- key. The workload presents a signed OIDC token from its own identity provider (for example AWS, Google Cloud, Microsoft Entra ID, GitHub Actions or Kubernetes). Anthropic checks it against a federation rule you configure and returns a short-lived access token bound to a service account in your organisation. The SDKs can pick this up from environment variables such as ANTHROPIC_FEDERATION_RULE_ID, ANTHROPIC_ORGANIZATION_ID and ANTHROPIC_IDENTITY_TOKEN_FILE. There is no static key to leak from CI logs or repository secrets.

On Amazon Bedrock and Vertex AI there is no Anthropic key at all: the client signs in with the cloud's own identity, such as AWS credentials or Google Cloud application default credentials, so that cloud's access controls apply.

Credentials in Claude Code

  • Storage. Claude Code stores login credentials in the macOS Keychain, or in ~/.claude/.credentials.json with file mode 0600 on Linux.
  • Rotating keys. The apiKeyHelper setting runs your own command to print a credential, for example a command that reads from your vault. Claude Code caches the result for the session unless CLAUDE_CODE_API_KEY_HELPER_TTL_MS says otherwise.
  • Which credential is used. When several are present, an ANTHROPIC_API_KEY in the environment takes priority over a subscription login once you approve it, which can surprise people. Run /status to see which credential is active.
  • Keeping secrets from Claude. Deny reads of secret files in permissions, and reference tokens in .mcp.json as ${VAR} instead of writing them in.
{
  "apiKeyHelper": "pass show anthropic-api-key",
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ]
  }
}

A committed secret stays in history

A key written into a committed file is in the repository history, every clone and every CI runner that checked it out. Deleting the line in a later commit removes it from the current files only. Treat any committed credential as exposed: rotate it, then move the value out of the file.

Rotation is also why the value must live outside code. Code that reads a key by name keeps working when the value behind the name changes; a key pasted into source cannot be rotated without a code change in every place it was copied.

Environment variable or secret store

SituationWhere the value livesWhy
One machine or one pipeline run needs itEnvironment variable injected at run time, such as a CI secretNothing written to disk or committed
Several services or people need it, or reads must be auditedA secret manager that returns it to authorised callersOne rotation updates every consumer, and each read is recorded

Give each integration its own credential, scoped to what that integration needs, and keep a list of which services use it. Then a rotation breaks nothing you did not know about, and a leak reaches only one system.

Credentials for MCP servers

Match the method to the service's identity model:

  • A service where each person signs in (a SaaS tool): OAuth. When a remote server answers 401 or 403, Claude Code marks it as needing authentication; you sign in through /mcp in a browser, and Claude Code stores and refreshes the token for you.
  • A service account (an internal API): an API key in an environment variable, referenced from the configuration.
  • A local stdio server: no network credential. File permissions and permission deny rules are the boundary.

For the service-account case, .mcp.json holds only the reference:

{
  "mcpServers": {
    "warehouse": {
      "type": "http",
      "url": "https://warehouse.internal/mcp",
      "headers": { "Authorization": "Bearer ${WAREHOUSE_MCP_TOKEN}" }
    }
  }
}

Claude Code reads its own credential variables, such as ANTHROPIC_API_KEY, as empty inside a remote server's url and headers, so a configuration cannot forward your Claude key to someone else's server. Plugin authors can mark a configuration value sensitive, which keeps it in secure storage instead of settings.json.

OAuth redirect URIs are registered per host. A sign-in flow that works in staging fails in production until the production URI is registered, and many organisations require a separate OAuth app per environment. Put that step in the deployment checklist.

Agents should use a credential without seeing it

When an agent needs a GitHub token or a database password, Anthropic's secure deployment guide recommends a proxy outside the agent's security boundary that injects the credential into outgoing requests. The agent sends requests without credentials; the proxy adds them, enforces an allowlist of endpoints and logs every call. An MCP server or custom tool that forwards requests to a service outside the boundary achieves the same thing: the agent sees the tool, not the secret.

Which approach fits

SituationChooseWhy
Local development against the APIKey from a secret manager loaded into an environment variable, from a development workspaceNothing in code; a leak only reaches development
CI job on GitHub Actions calls ClaudeWorkload Identity Federation with the job's OIDC tokenNo stored long-lived key
Developers use rotating keys from a vault in Claude CodeapiKeyHelperClaude Code fetches the current key itself
Contractors only need Claude CodeConsole invite with the Claude Code roleThey cannot create general-purpose keys
An agent needs a database passwordProxy or MCP server outside the agent's boundaryThe agent never holds the secret
A key shows up in a public repositoryRevoke and replace it, then review its usageLimits and measures the damage

Rules that decide exam answers

  • No secret in code, prompts, the repository or client-side apps. Environment variables, secret managers and helpers are the right answers; encoding or hiding a key in a file is not.
  • One key per environment, scoped to a workspace. A shared key across development and production fails the least privilege test.
  • Short-lived and identity-bound beats long-lived and static. Where the workload has its own identity, federate it.
  • The agent uses a credential without seeing it. Prefer a proxy or tool that injects the secret.
  • Give the smallest role that does the job. Pick the role that allows the task and nothing more.
  • Rotate on a schedule; revoke at once on exposure. A key committed to a repository is exposed even after a later commit deletes it. A new key written back into the same file repeats the leak.

Where it appears in the exam

Identity, Secrets and Key Management is 1.6% of scored items in Domain 7, Security and Safety (8.1%), so expect about one question in a 53-item exam. Expect a team moving an app from development to production, a CI pipeline that calls Claude, a key that leaks, or a choice of role for a new team member.

Two sample questions

These are original Timo practice questions. They are not official exam questions.

Question 1

A team's GitHub Actions workflow calls the Claude API to label new issues. Security wants to stop storing a long-lived Claude API key as a repository secret. What should the team do?

Answer: A. Federation replaces the stored key with a short-lived token tied to the job's identity. B hides a secret in the repository, which is worse. C still stores a long-lived key, just for less time. D puts a secret where prompts can leak it.

Question 2

Ten contractors need to use Claude Code on one project, billed to the company's Claude Console organisation. They must not be able to create API keys for other applications. How should they be set up?

Answer: C. The Claude Code role can create only Claude Code API keys, which matches the need exactly. A shares one secret and gives broader access. B relies on a request instead of a control. D grants full control of a workspace, far more than needed.

Build exercise

  1. In the Claude Console, create development and production workspaces and one key in each. Store both in a secret manager and load the development key through ANTHROPIC_API_KEY.
  2. Add a secret scanner to a pre-commit hook or CI job. Commit a fake key-shaped string on a test branch and confirm the check fails.
  3. In Claude Code, set apiKeyHelper to a command that reads the key from your secret manager. Run /status and confirm which credential is active.
  4. Add the Read deny rules above, ask Claude to read .env, and confirm it is refused. Then open the Console usage view and find the calls made with each key.

Practise this topic

Sources