Because Claude Platform on AWS authenticates with AWS SigV4, it inherits AWS's best security habit: temporary credentials from STS, the AWS Security Token Service. Instead of a long-lived access-key pair sitting in a config file, a workload assumes an IAM role and receives a short-lived set — access key, secret key, and a session token — valid for a limited, configurable session duration. When it expires, it's worthless. That is the whole blast-radius argument in one sentence: a long-lived key leaked in a log or a laptop backup is a standing credential until someone notices and revokes it; a leaked STS session is a countdown timer.
How the SDK picks temporary credentials up
You rarely call STS yourself. Every role-based mechanism on AWS — EC2 instance profiles, ECS task roles, Kubernetes IRSA, SSO sign-in, CI federation — delivers STS temporary credentials through the AWS default credential provider chain, and the AnthropicAWS client reads that chain automatically. The tell-tale of temporary credentials on the wire is the x-amz-security-token header, which carries the session token and is required only for temporary credentials (IAM roles, SSO, STS). The SDK sets it for you; there is no flag to flip.
from anthropic import AnthropicAWS
# If this process runs under an assumed role (instance profile,
# task role, SSO session, etc.), the temporary credentials --
# including the session token -- are picked up automatically.
client = AnthropicAWS()
resp = client.messages.create(
model="claude-sonnet-5",
max_tokens=512,
messages=[{"role": "user", "content": "Hello"}],
)If you assume a role explicitly (for example, cross-account access), export the three values STS returns — AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN — and the client finds them at the top of the chain. Session duration is configurable when you assume the role, within the maximum configured on the role itself; check the official AWS documentation for the exact limits that apply to your role setup.
CreateInference on one workspace ARN, held via credentials that expire within hours, is about the smallest attack surface this platform offers. Templates are in the IAM policy guide.The other short-term credential: time-limited API keys
Sometimes the process that needs to call Claude can't do SigV4 at all — an LLM gateway, a serverless function, or a tool that only speaks bearer tokens. For that case, Anthropic documents a second short-lived mechanism: generate a short-term API key from your AWS credentials instead of minting a long-lived key in the AWS Console.
AWS publishes token-generator libraries for JavaScript, Python, and Java. Each reads AWS credentials via the standard provider chain and returns a time-limited token usable in the x-api-key header:
token = TokenGenerator(region="us-west-2").get_token()
client = AnthropicAWS(api_key=token, aws_region="us-west-2")The token's lifetime defaults to 12 hours and is capped at the lesser of three things: the duration you request, the expiry of the underlying AWS credentials, and 12 hours. Two operational notes:
No auto-refresh. Unlike SigV4 chain credentials, the SDK does not refresh short-term API keys. When one expires, generate a new token and construct a new client — build that into your gateway's credential-rotation loop.
IAM still applies. The principal using the token needs the aws-external-anthropic:CallWithBearerToken action alongside whatever route actions it calls. And note the circularity the docs themselves point out: if a process can generate the token locally, it already holds SigV4 credentials — so plain SigV4 is usually simpler. Reserve short-term keys for genuine hand-offs to a separate process.
Choosing between the mechanisms
Default to SigV4 with role-delivered STS credentials: automatic pickup, automatic refresh, no secret handling. Use short-term API keys only when handing a credential across a process boundary to something that can't sign requests. Use long-lived AWS Console API keys last, and only where neither of the above fits — they carry all the standing-credential risk that the short-lived options exist to remove.
Where to go next
The role-based delivery paths each have a guide: EC2 instance roles, IRSA on Kubernetes, and workload identity federation for CI. For rotation practices around any remaining static keys, see credential rotation.