Support Amazon Bedrock API keys (bearer token / AWS_BEARER_TOKEN_BEDROCK) as an authentication method

[blinkagent]

Summary

AI Bridge currently authenticates to Amazon Bedrock exclusively via SigV4, using either static AccessKey/AccessKeySecret pairs or the AWS SDK default credential chain (task role, env vars, IMDS, IRSA, SSO). AWS now offers an alternative auth mechanism specifically for Bedrock: Bedrock API keys, passed as Authorization: Bearer <token> headers.

We would like AI Bridge to support Bedrock API keys as a first-class configuration option, either as an explicit config field or by honoring the standard AWS_BEARER_TOKEN_BEDROCK environment variable.

Motivation

Testing / evaluation phase

Organizations evaluating Coder AI Gateway and Coder Agents against Bedrock often want to prove out the integration before committing to production IAM changes. Bedrock API keys give evaluators:

• A single credential they can drop into a config file / secret manager and immediately test
• No need to create a dedicated IAM user or role for Coder
• No need to update task role policies (which may require review by security teams)
• Ability to revoke the key without touching IAM at all

Today, using SigV4 for a POC means either creating an IAM user (fighting long-term key policies) or modifying an ECS task role (a change that may not survive to production). Both create friction that delays evaluation.

Cross-account / multi-org deployments

Many enterprise customers run Coder in one AWS account (or Organizational Unit) and gate Bedrock access to a different account/OU under stricter governance. Today this requires:

• Configuring cross-account role assumption in the SDK default credential chain (external ID, session policies, etc.)
• Or provisioning static access keys for a Bedrock-scoped IAM user in the AI account and shipping them to the Coder account

Bedrock API keys are ideal for this scenario: an admin in the AI account generates a short-term or long-term API key scoped to Bedrock, hands it to the Coder account, and no trust relationship or role assumption needs to be set up between accounts.

Alignment with AWS's recommended flow

AWS is actively promoting Bedrock API keys as the recommended auth for Bedrock clients (see API keys docs). Both boto3 and the AWS JS SDK now honor AWS_BEARER_TOKEN_BEDROCK out of the box. Coder is currently locked to the older SigV4-only flow because the AWS SDK for Go v2 has not yet added bearer-token support for bedrock-runtime.

Proposed behavior

1. If AWS_BEARER_TOKEN_BEDROCK is set (env var or config field), AI Bridge uses it as the Authorization: Bearer <token> header on Bedrock requests and skips SigV4 signing.
2. If both a bearer token and static SigV4 credentials are provided, prefer the bearer token (matches AWS SDK precedence).
3. Configuration surface: add CODER_AIBRIDGE_BEDROCK_API_KEY (or similarly named) env var / CLI flag so operators can set it explicitly without relying on the AWS-standard env var.
4. Document the option alongside existing Bedrock auth methods.

Implementation notes

• The AWS SDK for Go v2 bedrock-runtime client does not currently expose a bearer-token auth scheme; you may need to bypass the SDK's signing middleware and use a plain HTTP client (or the SDK's smithy-go custom auth scheme once available).
• The Bedrock endpoint URL is unchanged (https://bedrock-runtime.<region>.amazonaws.com), only the auth header differs.
• Bedrock API keys work only for bedrock and bedrock-runtime actions. InvokeModelWithBidirectionalStream and Agents/Data Automation APIs are excluded, per AWS docs. AI Bridge only uses InvokeModel/InvokeModelWithResponseStream, so this is fine.

References

• AWS docs: Use an Amazon Bedrock API key
• AWS docs: How Amazon Bedrock API keys work
• Current SigV4 path in AI Bridge: intercept/messages/base.go
• Related: PR coder/coder#24346 (added SDK default credential chain)

---

Requested by Manuel Anda at Torc.

[linear-code]

ENG-2989