AnthropicClaude Certified Architect – Professional2026-103.2 Analyze authentication and authorization requirements to identify security gaps

Keep credentials outside the agent runtime

Completed by the knowledge check

Learning objective

Protect credentials with secret stores, per-user credential isolation, and short-lived scoped tokens, never in prompts or committed configuration.

Core idea

A credential reference in configuration avoids committing its value, but the process that expands it can still receive the secret. An enterprise architect must also decide where credentials live, which requester can cause them to be used, and how long a leaked credential remains usable.

Treat custody, identity isolation, and authority lifetime as separate controls. A secrets manager protects storage; it does not narrow the credential’s permissions. A short-lived token narrows exposure time; it does not prevent one user’s token from being selected for another user’s request. The design needs all three.

How it works

Store values beyond the agent’s reach

Anthropic recommends storing a Claude API key safely, such as in a secrets manager. For workloads that process untrusted content, its secure-deployment guide recommends a stronger boundary: a proxy outside the agent environment injects credentials into outgoing requests. The agent can request an operation without reading the credential that authorizes it.

Choose the secret-store implementation according to your deployment platform. Anthropic does not prescribe one universal secret-store API for custom tools. Your architecture must specify which service reads the value and why the agent cannot read that service’s storage, environment, or diagnostic output.

For Claude sampling requests, ANTHROPIC_BASE_URL routes Claude Code and the Agent SDK to a proxy that can inspect requests and add credentials before forwarding them. That setting covers sampling API requests, not every service a tool might contact. Use a custom tool or MCP service outside the agent boundary for downstream credentials, rather than assuming this variable secures every integration.

HTTP_PROXY and HTTPS_PROXY route HTTP traffic, but an HTTPS CONNECT tunnel does not expose encrypted request contents to the proxy. Credential injection into arbitrary HTTPS requests requires TLS termination or an external tool service that performs the authenticated request itself. A routing setting alone is not a credential-custody design.

The same guidance warns that read-only filesystem access can expose secrets in .env files and credential directories. Exclude those resources from agent-readable mounts. Read-only prevents modification, not disclosure. Keep values out of prompt text, committed configuration, transcripts, and request logs; otherwise a second copy defeats the intended boundary.

Select credentials by trusted user and destination

A broker must choose a downstream credential using the authenticated user’s identity and the approved destination. A model-generated username or tenant argument cannot select the secret-store entry. See 3.2.1 for the principal decision and 3.2.2 for resource authorization; credential selection must preserve both.

For an application using the Messages API MCP connector (beta, anthropic-beta: mcp-client-2025-11-20, documented for the Claude API, Claude Platform on AWS, and Microsoft Foundry), the per-request server definition carries authorization_token. The application supplies the token for that user and MCP server. Keep the token in transport configuration, outside the conversation body, and redact the field if the application records the request. Its presence outside messages does not mean your own logs cannot capture it.

Use distinct credential records for users and integrations. Do not share a global mutable token variable across concurrent requests: replacing it for user B can change which authority user A’s call spends. An application-owned broker can associate each lookup with a verified principal and an approved resource, then return only the operation result to the agent.

The broker also needs ownership of revocation, expiry, and account changes. If a user loses access, retaining a token in an application cache must not become a way to continue spending the former authority. The concrete lifecycle depends on the issuing service; verify it rather than assuming all downstream tokens behave like Claude API credentials.

Replace static Claude keys where federation fits

Anthropic Workload Identity Federation exchanges a signed identity-provider token for a short-lived Anthropic token bound to a service account. The mechanism is POST https://api.anthropic.com/v1/oauth/token, with grant_type: "urn:ietf:params:oauth:grant-type:jwt-bearer". The resulting Claude API request uses Authorization: Bearer rather than the static-key x-api-key path.

A federation rule specifies which issuer claims may act as the target service account. Its match conditions include subject_prefix, audience, claims, and condition; all configured matchers must pass. Choose conditions that identify the intended production workload rather than a broad set of unrelated jobs.

The rule’s OAuth scope defaults to workspace:developer; do not assume federation automatically gives a narrower role than a workspace API key. Its token_lifetime_seconds accepts 60 through 86,400 seconds, with an API default of 3,600. The Console setup wizard prefills 600 seconds. That distinction matters when an architect claims a ten-minute exposure window: the wizard choice is not the API default. The minted token’s lifetime is the lesser of the rule’s configured lifetime and twice the remaining lifetime of the presented identity-provider JWT, with a minimum of 60 seconds. The rule therefore sets a ceiling; the upstream token can shorten the result.

Federation removes the need to distribute a static Claude API key, but the upstream identity provider becomes a trust dependency. A permissive rule can mint short-lived tokens for the wrong workload repeatedly. Review the issuer, match conditions, target account, workspace access, scope, and lifetime together.

This mechanism authenticates your workload to the Claude API. It does not replace delegated tokens for a user’s business resources. Nor does it establish that a downstream tool token has the same lifetime range or refresh behavior.

Key distinctions and trade-offs

Environment injection avoids a committed value but may place it inside an agent-readable process. External credential injection costs an additional service and routing path, while reducing the secret exposure of that process. Choose the boundary according to the untrusted content and capabilities the agent can reach.

Static service account keys offer straightforward integration. Anthropic lets you choose an expiration and scope a key to a workspace. Federation adds issuer and trust-rule management, while providing short-lived access without a distributed static key. Neither choice authorizes access to another system merely because the credential is valid.

Shorter token lifetimes reduce the useful duration of a leak but increase exchange and refresh demands. Scope reduces authority; lifetime reduces duration; per-user isolation preserves attribution. Defend each independently rather than counting three as one feature called “secure tokens.”

Architecture / decision scenario

A technology company’s code-analysis service runs 80 customer jobs concurrently. The pilot injects a shared repository token into every agent container. Jobs have read access to environment and workspace files, and the service logs complete MCP request bodies for debugging.

The architect rejects moving the same token into a different environment variable: it would still be readable by every job. An external tool broker instead resolves the customer’s credential from a secret store, checks the approved repository operation, and returns the result without the token. Credential selection is keyed by the authenticated customer and destination; logs redact authorization_token and bearer headers.

For Claude inference, the platform team compares a static service account key with federation. Production identity tokens are already available, so it chooses a federation rule restricted to that workload and explicitly sets token_lifetime_seconds: 600. That sets a 600-second ceiling; the identity-provider JWT’s remaining lifetime can shorten the minted token, subject to the 60-second minimum. Omitting the field would leave the rule at the 3,600-second API default, so it would not guarantee the team’s ten-minute ceiling.

The repository-token lifecycle remains the repository integration owner’s responsibility. Acceptance tests overlap two customers’ requests and confirm each uses the correct credential, then inspect prompts, mounts, configuration, and logs for exposed values. The security owner verifies custody; the platform owner verifies the federation rule and refresh behavior.

Common exam traps

Calling an environment variable a secret-store boundary when the agent can read it.
Treating a read-only credential file as safe to expose.
Expecting ANTHROPIC_BASE_URL to secure every downstream tool request.
Assuming an HTTPS CONNECT proxy can inject headers without TLS termination.
Confusing the federation wizard’s 600 seconds with the API default of 3,600.
Using short-lived credentials without verifying user isolation or scope.

What to remember

Keep secret values outside the agent’s reach, select them with trusted user and destination state, and bound their authority and lifetime. For Claude API federation, review the issuer and rule as carefully as the token. A shorter expiry cannot repair the wrong principal or an overbroad scope.