Summary

This issue references and reopens the discussion from #2251, which was closed but remains an important feature request.

Currently, OpenClaw only supports Amazon Bedrock via the AWS SDK default credential chain (environment variables, shared config, instance roles). Users who have Bedrock API keys (bearer tokens) generated from the Amazon Bedrock console cannot use them directly.

This limits flexibility for users who:

• Prefer API key-based authentication over IAM credentials
• Work in environments where AWS SDK credential chain setup is complex
• Want a simpler onboarding experience similar to other AI providers

Proposed Solution

Add support for AWS_BEARER_TOKEN_BEDROCK environment variable as an authentication option for Amazon Bedrock, similar to how opencode implements it.

The authentication precedence should be:

1. Bearer Token - AWS_BEARER_TOKEN_BEDROCK environment variable (new)
2. AWS Credential Chain - Existing behavior (access keys, profiles, instance roles)

This would allow users to simply set:

AWS_BEARER_TOKEN_BEDROCK=xxx openclaw gateway

Why This Matters

Amazon Bedrock now offers API keys as a first-class authentication method through their console. Not supporting this creates friction for users who want to use OpenClaw with Bedrock in the simplest way possible.

Alternatives Considered

• OpenAI-compatible proxy: The current docs suggest placing an OpenAI-compatible proxy in front of Bedrock, but this adds complexity and another service to maintain.
• Stick with AWS SDK chain: Works but requires more setup (IAM users, roles, credentials files) compared to a simple API key.

Additional Context

• Original issue: [Feature]: Support Amazon Bedrock API Key (Bearer Token) Authentication #2251
• opencode implementation reference: https://github.com/anomalyco/opencode/blob/main/packages/web/src/content/docs/providers.mdx#amazon-bedrock
• Current OpenClaw Bedrock docs mention AWS_BEARER_TOKEN_BEDROCK in credential surfacing order but it doesn't appear to be fully implemented

Related Issues

Closes #2251 (when implemented)