7.4 · 2.0% of the exam · Topic 4 of 4

Identity, Secrets, and Key Management

Manage identities, credentials, secrets, and API keys securely across Claude development and production environments.

Learning objectives

Understand authentication and identity validation.
Apply authorization and access-level verification.
Protect API keys, credentials, and secrets.
Use secure secret management across environments.
Monitor and control authorized access.

Detailed theory

Identity and authentication

Authentication verifies the identity of a user or service before access is granted.

Claude applications should validate identities before allowing access to protected resources or sensitive operations.

Authenticate users and services.
Validate identity before sensitive operations.
Use established identity providers where appropriate.
Do not treat user-provided identity claims as trusted without verification.

Secrets and API keys

API keys, tokens, passwords, and other credentials are secrets that should be protected throughout their lifecycle.

Secrets should not be embedded directly in source code or exposed through logs, client-side code, or model output.

Store secrets in secure secret-management systems.
Keep secrets out of source control.
Use separate credentials for different environments.
Rotate credentials when necessary.
Avoid logging sensitive credentials.

Authorization and access levels

Authorization determines which resources and actions an authenticated identity can access.

Access should be limited according to role, responsibility, and operational need.

Verify permissions before sensitive actions.
Apply least privilege.
Separate read and write access where appropriate.
Require additional approval for high-impact operations.

Authorized access monitoring

Sensitive access should be observable so that unexpected or unauthorized activity can be detected and investigated.

Audit information should provide enough context to understand who accessed a resource and what action occurred without exposing the secret itself.

Record relevant access events.
Monitor sensitive operations.
Protect audit information.
Investigate unexpected access.

Core concepts

Authentication

What: Verifying the identity of a user or service.
Why: Protected resources should only be accessed by verified identities.
When: Before granting access to protected resources.
When not: Authentication alone does not determine permissions.

Authorization

What: Determining what an authenticated identity is allowed to access or perform.
Why: Prevents users and services from exceeding their permissions.
When: Before protected actions and resource access.
When not: Do not confuse authorization with identity verification.

Secret

What: Sensitive credential material such as an API key, password, or access token.
Why: Exposure can allow unauthorized access.
When: Whenever credentials are stored, transmitted, or used.
When not: Do not place secrets in source code or public configuration.

Least privilege

What: Giving an identity only the permissions required for its task.
Why: Limits the impact of compromised credentials or mistakes.
When: Designing access to Claude tools and external systems.
When not: Avoid broad permissions simply for convenience.

Practical examples

Protecting an API key

A Claude application needs an API key to call an external service. The key should be stored in a secure secret-management mechanism rather than committed to source control.

The application retrieves the credential at runtime and uses it only for the required operation.

Separating authentication and authorization

A user successfully authenticates to the application, but authentication alone does not mean the user can delete customer data.

The application must separately verify that the authenticated identity has permission to perform the destructive operation.

Claude-specific considerations

Authentication verifies who a user or service is.
Authorization determines what an authenticated identity is allowed to access or perform.
API keys, tokens, passwords, and credentials should be treated as secrets.
Do not place secrets in source control, client-side code, logs, or model output.
Use secure secret-management mechanisms and separate credentials across environments.
Apply least privilege to identities, tools, APIs, and resources.
Sensitive access should be observable through appropriate audit information.

Architecture decisions

SituationChooseBecause

An API key is currently hard-coded in source code.Move the credential into secure secret management.Source code is not an appropriate place for long-lived secrets.

A user is authenticated but requests an administrative action.Check authorization before executing the action.Authentication does not establish permission to perform every operation.

A Claude tool only needs read access.Grant read permission without write or administrative access.Least privilege reduces the impact of mistakes or compromise.

A credential may have been exposed.Rotate or revoke the affected credential.An exposed secret should no longer be trusted.

Sensitive access needs to be investigated later.Record appropriate access events without logging the secret itself.Auditing should provide useful evidence without exposing credentials.

Tradeoffs

Strong credential management adds operational controls, but it reduces the impact of exposed credentials and unauthorized access.

AxisConvenienceSecurity

Credential storageHard-coded credentials or plain configuration.Managed secrets retrieved at runtime.

PermissionsBroad permissions for convenience.Least-privilege access.

EnvironmentsOne credential reused everywhere.Separate credentials for development and production.

MonitoringMinimal access visibility.Auditable sensitive access without exposing secrets.

Quick reference

Authentication verifies who a user or service is.
Authorization determines what an authenticated identity can access or perform.
Keep API keys, tokens, and passwords out of source code and logs.
Use secure secret management and separate credentials across environments.
Apply least privilege to identities, tools, APIs, and resources.
Monitor sensitive access without exposing the secret itself.

Decision rules for the exam

If the question says…The answer is likely…

"the API key is hard-coded in source code"Move it to secure secret management

"the user is authenticated but requests an admin action"Check authorization before executing the action

"the tool only needs read access"Grant read permission only

"a credential may have been exposed"Rotate or revoke the credential

"sensitive access needs to be investigated later"Record access events without logging the secret

Common exam traps

TrapCorrect answer

Authentication means the user can perform every action.Authentication verifies identity; authorization verifies permission.

API keys can safely be committed to source control.Secrets should be stored using secure secret management.

Giving tools broad permissions is simpler and safer.Use least privilege and grant only required permissions.

Logging credentials helps with debugging.Audit the access event without exposing the credential.

Open the Domain 7 sheet

Exam tips

Authentication answers who the requester is; authorization answers what that identity can do.
If an API key is hard-coded or committed to source control, move it to secure secret management.
Least privilege means granting only the permissions required for the task.
Do not log secrets simply to make access easier to debug.
High-impact operations should have explicit authorization checks.

Common mistakes

Treating authentication as proof that a user can perform every action.
Perform a separate authorization check before protected operations.
Putting API keys in source code.
Use a secure secret-management mechanism and provide credentials at runtime.
Giving every tool broad read/write/admin permissions.
Apply least privilege and grant only the required capabilities.
Logging full credentials for debugging.
Record the access event without exposing the secret.

Practice questions

Original questions for this topic. They are study items, not questions from the live exam.

Scenario questions

Build exercise

Secure Claude credentials

Intermediate · 30 minutes

What you will learn

Identify secrets and credentials.
Separate authentication from authorization.
Apply least privilege.
Define secure access monitoring.

Step 1
Find the secrets
Identify API keys, tokens, passwords, and credentials used by the application.
Why: You cannot protect credentials that have not been identified.
You should see: A list of sensitive credential types.
Step 2
Move secrets out of code
Store credentials using an appropriate secret-management mechanism instead of hard-coding them.
Why: Source code and client applications are unsafe places for long-lived secrets.
You should see: Application configuration references a managed secret.
Step 3
Restrict access
Define which identities and services can use each credential and what actions they can perform.
Why: Least privilege limits potential damage.
You should see: Each identity has only the permissions it needs.

Review checklist

Checks are saved in this browser.

I can distinguish authentication from authorization.
I can identify secrets and API keys.
I keep credentials out of source control.
I apply least privilege.
I understand the purpose of access monitoring.

Key takeaways

Authenticate identities before protected access.
Authorization determines what an identity can do.
Keep API keys and credentials out of source code.
Use secure secret management and environment separation.
Apply least privilege and monitor sensitive access.

Sources

Claude Documentation — Claude platform documentation and application guidance.
Anthropic Safety — Anthropic safety and security information.
CCDV-F blueprint notes — Developer certification study reference.

Domain 7 overview · Quick reference

View progress