Identity, OAuth and Secrets

Agentic systems multiply the number of places a credential can live and the number of ways it can leak. A model that can read files, call tools and write logs is a model that can exfiltrate a secret it should never have seen. The exam tests whether you can lay out identity end to end: who the application is to Anthropic, who the user is to your systems, and who the agent is to the tools it calls.

Authenticating to the Claude platform

Mechanism	Shape	Use
API key	Long-lived secret created in the Console, scoped to a workspace	Servers and gateways; rotate on a schedule
Admin API key	Separate credential for organisation management	Automation of members, workspaces, keys and usage reporting
OAuth	Token-based login for Claude Code and developer tools	Interactive developer use
Workload identity federation	Exchange a cloud or CI identity token for a short-lived Anthropic token	Production services without static secrets
Cloud platform IAM	AWS credentials, Google application default credentials, Entra ID	When consuming Claude through Bedrock, Vertex AI or Foundry

Workspaces are the unit of isolation inside an organisation: keys belong to a workspace, usage and rate limits can be allocated per workspace, and spend can be tracked per workspace. Give each team or environment its own workspace rather than sharing one key.

Prefer workload identity federation over static API keys for services. A short-lived token derived from the service's cloud identity cannot be copied from a configuration file and used elsewhere, and rotation is automatic.

The gateway as credential broker

The architectural answer to "where do the keys live" is: in one place. A gateway service holds the platform credential, authenticates callers with your enterprise identity provider, applies per-team budgets, and forwards requests. Client applications never hold a model credential. This also gives you one place to rotate keys, one place to audit, and one place to swap the platform client when you move between the Claude API and a cloud platform.

Identity through tools and MCP

The second identity question is which identity the agent presents to the systems it acts on.

• User-delegated. OAuth 2.1 flows carry the end user's authorisation to the MCP server or tool backend. The backing system enforces the user's permissions, so the agent can do nothing the user could not. Preferred for user-facing assistants.
• Service identity. The tool runs under a service account. Acceptable for read-only retrieval over broadly accessible data, or when combined with a policy layer that checks the acting user; dangerous for write tools without one.
• Hybrid. Service identity to reach the system, user ID passed in context for authorisation and audit.

Whatever the pattern, credentials are injected by infrastructure (environment, secret manager, token exchange) and used by tool code. They are never placed in prompts, never returned in tool results, and never written to files an agent can read.

Managed runtimes

Managed Agents provide vaults in which credentials are stored and substituted into outbound requests at egress, so the sandbox never sees the raw secret. This is the model to emulate in self-hosted designs: a proxy or sidecar that adds the credential after the agent has composed the request. For Agent SDK deployments, mount short-lived tokens into the container's environment with the minimum scopes, and scrub them from logs.

Secrets hygiene checklist

1. No secret in a system prompt, user turn, tool description or tool result.
2. Deny agents read access to known secret locations (environment dumps, .env files, credential stores) through permission rules and hooks.
3. Redact secrets patterns from logs and transcripts before storage.
4. Rotate keys on a schedule and immediately on any suspected exposure; the Admin API can automate key lifecycle.
5. Separate development and production workspaces and keys; never test with production credentials.
6. Alert on anomalous usage per key and workspace; a leaked key shows up as unexpected spend.

Audit and accountability

Every request through the gateway should carry the calling user or service identity and a trace ID; every tool call should log the identity the tool acted under. Pass a stable, non-identifying user reference in request metadata so that abuse reports can be correlated without exposing personal data. Together these let you answer the question regulators ask: who did what, on whose behalf, with which permissions.

Exam focus

• API keys are workspace-scoped; workspaces isolate teams and allocate limits and spend.
• Prefer workload identity federation or cloud IAM over static keys for services; use a gateway as the single credential holder.
• Agents acting on systems should use user-delegated OAuth where possible; service identity needs a policy layer for writes.
• Credentials are injected by infrastructure and never pass through prompts, tool results or agent-readable files.
• Managed Agents vaults substitute credentials at egress; emulate this with proxies or sidecars in self-hosted designs.
• Logging must capture caller identity and tool identity with a trace ID, with secrets redacted.