Bearer Token / API Key Authentication for chat_aws_bedrock()

[Tazinho]

Hi Hadley, just ran into the issue that I couldn't natively request our internal Bedrock endpoints which rely on Bearer Token authentication (API key via Authorization: Bearer <key> header, no SigV4 signing). I built a workaround using httr2 as a proof of concept, but of course I'm losing all ellmer features like streaming, tool calling, etc. Is this something that could be resolved on the ellmer side? I believe it has quite some impact for enterprise users behind API gateways. Let me know in case you need any further info.

Problem

chat_aws_bedrock() requires IAM credentials via paws.common, which doesn't support the Bearer Token authentication that AWS Bedrock launched in July 2025. This prevents users who access Bedrock through enterprise API gateways (which issue API keys instead of IAM credentials) from using ellmer natively.

Reproduction

Sys.setenv(AWS_BEARER_TOKEN_BEDROCK = "my-api-key")

chat <- chat_aws_bedrock(
  base_url = "https://my-company-gateway.example.com/bedrock",
  model = "us.anthropic.claude-sonnet-4-5-20250929-v1:0"
)
# Error: No IAM credentials found.

Python's boto3 supports this via AWS_BEARER_TOKEN_BEDROCK — it skips SigV4 signing and sends Authorization: Bearer <key> instead.

Proposal

Add a credentials parameter (similar to chat_azure_openai()) that, when provided:

1. Skips paws.common IAM credential resolution
2. Sends the key as Authorization: Bearer <key> header
3. Does not apply SigV4 signing

# Desired API
chat <- chat_aws_bedrock(
  base_url = "https://my-company-gateway.example.com/bedrock",
  model = "us.anthropic.claude-sonnet-4-5-20250929-v1:0",
  credentials = "my-api-key"
)

Workaround

Currently requires calling the Bedrock Converse API directly via httr2, losing all ellmer features (streaming, tool calling, parallel_chat(), etc.).

[gadenbuie]

Thanks for opening this issue! Could you please include links to documentation for the new features you're referring to?

[DyfanJones]

Hi all, here is some context around the bearer token and how paws handles it:

Aws documentation:
https://docs.aws.amazon.com/bedrock/latest/userguide/api-keys-use.html

Paws:

• https://github.com/paws-r/paws/blob/022c4baec490be724091bd4fba6a12c0f5c3e4fb/paws.common/R/credential_providers.R#L30-L91
• https://github.com/paws-r/paws/blob/main/paws.common/R/signer_bearer.R
• https://github.com/paws-r/paws/blob/022c4baec490be724091bd4fba6a12c0f5c3e4fb/paws.common/R/signer_v4.R#L101-L115

In summary once the AWS_BEARER_TOKEN_BEDROCK or AWS_BEARER_TOKEN has been identified in the environment variables and your using the bedrock services the token is passed to: Authorization: Bearer <key> instead of using the v4 signer.

Paws supports bearer tokens in the locate_credentials function. However the part you are missing is the skipping of the v4 signer.

Sys.setenv("AWS_BEARER_TOKEN"= "b0b")
paws.common::locate_credentials()
#> $access_key_id
#> [1] ""
#> 
#> $secret_access_key
#> [1] ""
#> 
#> $session_token
#> [1] ""
#> 
#> $access_token
#> [1] "b0b"
#> 
#> $expiration
#> [1] Inf
#> 
#> $region
#> [1] ""

^{Created on 2026-05-29 with reprex v2.1.1}