Principle:Anthropics Anthropic sdk python Authentication Configuration

Knowledge Sources	Anthropic Python SDK Anthropic API Docs
Domains	Cloud_Deployment, LLM, Infrastructure
Last Updated	2026-02-15 00:00 GMT

Overview

Each cloud provider uses a distinct authentication mechanism. The Anthropic Python SDK abstracts these differences behind a common client initialization interface, but internally implements provider-specific authentication flows: AWS SigV4 request signing for Bedrock, Google OAuth2 token management for Vertex AI, and Azure AD token providers or API keys for Foundry. All three clients follow an environment variable fallback pattern where credentials can be explicitly provided as constructor arguments or automatically inferred from the runtime environment.

Cloud Provider Authentication Patterns

AWS SigV4 Request Signing (Bedrock)

AWS Bedrock requires every HTTP request to be signed using the Signature Version 4 (SigV4) algorithm. The SDK implements this through a _prepare_request() override that intercepts outgoing httpx.Request objects and attaches SigV4 authentication headers.

The signing flow works as follows:

1. A boto3.Session is created from the provided credentials (or resolved from the environment).
2. The session's credentials are extracted via session.get_credentials().
3. A botocore.auth.SigV4Auth signer computes the Authorization, X-Amz-Date, and optionally X-Amz-Security-Token headers.
4. The signed headers are injected into the outgoing request.

The credential resolution chain follows standard AWS conventions:

• Explicit constructor arguments (aws_access_key, aws_secret_key, aws_session_token)
• Named profile via aws_profile
• Environment variables (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN)
• Instance metadata / IAM roles (resolved transparently by boto3)

Google OAuth2 Token Management (Vertex AI)

Vertex AI authenticates via OAuth2 bearer tokens. The SDK supports three authentication strategies, tried in order:

1. Explicit access token -- If access_token is provided, it is used directly as a Bearer token.
2. Explicit credentials object -- If a GoogleCredentials object is provided, the SDK refreshes it when expired and extracts the token.
3. Application Default Credentials (ADC) -- If neither is provided, the SDK calls google.auth.default() with the cloud-platform scope, which resolves credentials from GOOGLE_APPLICATION_CREDENTIALS, the GCE metadata server, or gcloud auth application-default login.

Token refresh is handled automatically: the _ensure_access_token() method checks credentials.expired before each request and calls credentials.refresh(Request()) as needed. In the async client, these blocking operations are offloaded to a thread via asyncify().

Azure AD and API Key Authentication (Foundry)

Azure AI Foundry supports two mutually exclusive authentication methods:

1. API key -- A static key passed as api_key or read from ANTHROPIC_FOUNDRY_API_KEY. It is sent as the api-key header (not the standard Authorization header).
2. Azure AD token provider -- A callable (Callable[[], str] for sync, Callable[[], str | Awaitable[str]] for async) that is invoked on every request to obtain a fresh bearer token. This supports token rotation without client recreation.

The _prepare_options() method checks for the Azure AD token first; if absent, it falls back to the API key. Providing both raises a MutuallyExclusiveAuthError.

Environment Variable Fallback Pattern

All three providers follow a consistent pattern where constructor arguments take precedence over environment variables:

Provider	Constructor Arg	Environment Variable Fallback
Bedrock	aws_region	AWS_REGION, then boto3 session, then us-east-1 default
Bedrock	base_url	ANTHROPIC_BEDROCK_BASE_URL
Vertex	region	CLOUD_ML_REGION (required -- raises ValueError if missing)
Vertex	project_id	ANTHROPIC_VERTEX_PROJECT_ID, then resolved from ADC
Vertex	base_url	ANTHROPIC_VERTEX_BASE_URL
Foundry	api_key	ANTHROPIC_FOUNDRY_API_KEY
Foundry	resource	ANTHROPIC_FOUNDRY_RESOURCE
Foundry	base_url	ANTHROPIC_FOUNDRY_BASE_URL

This layered resolution enables zero-configuration usage in cloud environments (where IAM roles, metadata servers, or secret managers populate environment variables) while still allowing explicit overrides for local development and testing.

Related Pages

Implemented By

• Implementation:Anthropics_Anthropic_sdk_python_Cloud_Provider_Auth