Auxiliary client (title-gen / compress) cannot use AWS Bedrock Bearer Token (AWS_BEARER_TOKEN_BEDROCK) — anthropic SDK 0.87.0 CVE-pin lacks api_key parameter

[Skeptomenos]

Summary

Hermes' main agent path supports AWS Bedrock Bearer Token authentication (AWS_BEARER_TOKEN_BEDROCK) via agent/bedrock_adapter.py, which uses boto3's native Converse API. The auxiliary client path (title-gen, compression-summary, etc.) for the same Bedrock provider does NOT support Bearer Token auth, because:

1. tools/lazy_deps.py:81 pins anthropic==0.87.0 for CVE-2026-34450 / CVE-2026-34452.
2. anthropic==0.87.0 AnthropicBedrock SDK lacks the api_key parameter (added in anthropic >= 0.99.x).
3. Without api_key, AnthropicBedrock falls back to the boto3 SigV4 credential chain, which does not recognize AWS_BEARER_TOKEN_BEDROCK.
4. Result: every auxiliary call against a Bedrock model fails with HTTP 403 "could not resolve credentials from session" (visible to end-users on Slack as a :warning: Auxiliary title generation failed: banner above each gateway reply).

Reproducer environment:

• Hermes Agent v0.14.0 + 49 commits past 2026.5.16 release
• macOS launchd gateway (1 user, single-tenant deployment)
• Provider config: auxiliary.title_generation.provider: bedrock, auxiliary.title_generation.model: us.anthropic.claude-haiku-4-5-20251001-v1:0
• Auth: AWS_BEARER_TOKEN_BEDROCK in .env (HF-provisioned token), AWS_REGION=us-east-1
• Main agent path with same model & token: ✅ Works (boto3 Converse API recognizes Bearer Token)
• Auxiliary path with same model & token: ❌ HTTP 403

Validation matrix (tested 2026-05-20)

Scenario	anthropic version	AWS_BEARER_TOKEN_BEDROCK	Result
Standalone Python in Hermes venv post-manual-upgrade	0.103.1	yes	✅ OK
Same Python, no manual upgrade	0.87.0	yes	❌ "could not resolve credentials"
Hermes gateway runtime (lazy_deps auto-reverts upgrade on next boot)	0.87.0	yes	❌ "could not resolve credentials"
Hermes main agent path (hermes -z --model haiku-4-5)	0.87.0	yes	✅ OK (uses bedrock_adapter → boto3 Converse, not AnthropicBedrock SDK)

Root-cause references

tools/lazy_deps.py:81:

"provider.anthropic": ("anthropic==0.87.0",),  # CVE-2026-34450, CVE-2026-34452

agent/anthropic_adapter.py:760-790 (build_anthropic_bedrock_client):

return _anthropic_sdk.AnthropicBedrock(
    aws_region=region,
    ...  # no api_key=, no AWS_BEARER_TOKEN_BEDROCK pickup
)

Inspected signature of installed anthropic==0.87.0 AnthropicBedrock.__init__:

['self', 'aws_secret_key', 'aws_access_key', 'aws_region', 'aws_profile',
 'aws_session_token', 'base_url', 'timeout', 'max_retries', 'default_headers',
 'default_query', 'http_client', '_strict_response_validation']

→ no api_key parameter.

Secondary finding: provider canonicalization gap

agent/auxiliary_client.py:3481:

pconfig = PROVIDER_REGISTRY.get(provider)
if pconfig is None:
    logger.warning("resolve_provider_client: unknown provider %r", provider)
    return None, None

Literal dict lookup against PROVIDER_REGISTRY keyed bedrock. Main agent path (runtime_provider.py) canonicalizes provider names. Auxiliary does not. This means provider: amazon-bedrock (as exposed by hermes_cli/auth.py:441 and accepted by model_aliases: blocks for the main agent) silently falls through here and emits the misleading AMAZON-BEDROCK_API_KEY env-var-not-found error before the real Bearer Token issue is ever hit.

We worked around this in our config by using provider: bedrock for the auxiliary block, but the alias amazon-bedrock should be accepted in both paths for consistency.

Suggested fixes (in priority order)

1. Patch build_anthropic_bedrock_client to detect AWS_BEARER_TOKEN_BEDROCK and route via boto3 Converse API directly (mirroring the main agent's bedrock_adapter._get_bedrock_runtime_client). This unblocks Bearer Token auth without waiting for an anthropic SDK upgrade. Trade-off: loses anthropic SDK features like prompt caching / thinking budgets — acceptable for auxiliary tasks (title-gen, compress-summary) which don't need them.

2. Bump anthropic past 0.99.x once a CVE-clean version exists, then add api_key=os.environ.get("AWS_BEARER_TOKEN_BEDROCK") to the AnthropicBedrock(...) call in build_anthropic_bedrock_client. Future-proof.

3. Canonicalize provider name in auxiliary_client.py:3481 to accept both amazon-bedrock and bedrock (matching main agent path).

Workaround (current)

Auxiliary providers stay on a non-Bedrock provider (e.g., Azure OpenAI). Main agent Bedrock aliases work fine.

Refs

• HF deployment context: https://github.com/hellofresh/fusion-kitchen/pull/832 (defensive auxiliary revert that preserves the workaround)
• HF deployment context: https://github.com/hellofresh/fusion-kitchen/pull/836 (documentation closeout for our Phase 19 Bedrock parallel-deck integration)

[alt-glitch]

Related: #28085 (open PR fixing auxiliary_client.py bearer-token routing with BedrockConverseAuxiliaryClient), #24507 (routes Claude through Converse API for bearer auth), #27765 (closed, skipped bedrock in call_llm paths).

This issue documents the root cause (anthropic==0.87.0 CVE pin lacks api_key parameter) that unifies several open PRs attempting to fix bearer-token auth on auxiliary code paths.

[Skeptomenos]

Same root cause is also visible in the main agent path (not just auxiliary) under one specific runtime configuration — flagging here so the fix scope captures it.

When model.default is set to a Claude model on Bedrock (e.g. us.anthropic.claude-sonnet-4-6), runtime_provider.py hits the is_anthropic_bedrock_model() branch and pins:

provider: bedrock
api_mode: anthropic_messages

That routes through agent/anthropic_adapter.py:build_anthropic_bedrock_client → AnthropicBedrock(aws_region=region). With the 0.87.0 CVE-pinned SDK that constructor has no api_key parameter (same signature you noted in the auxiliary path), so AWS_BEARER_TOKEN_BEDROCK is ignored and the SigV4 fallback fails:

RuntimeError: could not resolve credentials from session
  provider=bedrock
  model=us.anthropic.claude-sonnet-4-6
  base_url=https://bedrock-runtime.us-east-1.amazonaws.com

Failure path is identical to your validation matrix's row 3 ("Hermes gateway runtime, anthropic 0.87.0, AWS_BEARER_TOKEN_BEDROCK") — the main-loop call follows the same anthropic-SDK code path, which is why the boto3 Converse workaround you cite (working for non-Claude Bedrock models like Nova / DeepSeek / Llama) doesn't help here: is_anthropic_bedrock_model() short-circuits to AnthropicBedrock SDK before Converse is reached.

Net effect with bearer-token auth (no IAM creds): Bedrock+Claude is fully blocked on both auxiliary and main paths — single-model setups (model.default: us.anthropic.claude-*) and delegation.model: fan-out both hit this.

Adjacent fix: #26769 bumps anthropic 0.86 → 0.102 in tools/lazy_deps.py, which restores the api_key parameter and lets the bearer token reach the SDK. That's the same SDK bump suggested as fix #2 in the issue body. It covers both paths in this issue.

Workaround for now: revert model.default to a non-Bedrock provider until #26769 lands.

[Skeptomenos]

2026-06-01 update — still reproducing after a full Bedrock-default cutover; AWS_BEARER_TOKEN does not fix it

We've since made Bedrock the default provider (Claude Sonnet 4.6 main, Opus 4.8 delegation) on a bearer-token-only host (no SigV4 creds, no ~/.aws). The main loop works via a vendored carry-patch of #24507 (routes Claude → Converse under AWS_BEARER_TOKEN_BEDROCK). The auxiliary path is still broken, and we can now add two concrete findings:

1. Promoting AWS_BEARER_TOKEN_BEDROCK → standard AWS_BEARER_TOKEN does NOT help the aux client.
The #24507 patch also exports AWS_BEARER_TOKEN for boto3. That fixes the main Converse client, but the aux path builds its own AnthropicBedrock SDK client, which calls session.get_credentials() (SigV4 chain) — and that chain does not treat AWS_BEARER_TOKEN/AWS_BEARER_TOKEN_BEDROCK as credentials. So aux still fails. Confirmed live (agent.log, every session):

INFO  agent.auxiliary_client: Auxiliary title_generation: using auto (eu.amazon.nova-micro-v1:0) at https://bedrock-runtime.eu-west-1.amazonaws.com
WARNING agent.title_generator: Title generation failed: could not resolve credentials from session

2. provider: auto does not rescue it either. With auxiliary.<task>.provider: auto, auto resolves to the main provider (bedrock) and still builds the SigV4-only AnthropicBedrock client → same failure — even for the Amazon Nova model (eu.amazon.nova-micro-v1:0), because the failure is in the SDK auth layer, before the model ID matters.

Net: on a bearer-only host there is no config-only fix — the vendored anthropic==0.87.0 SDK has zero bearer support, so any aux task that reaches it fails regardless of model or provider: auto/bedrock.

Our resolution path: provision standard SigV4 IAM credentials (access-key pair or role) so the AnthropicBedrock SDK / boto3 SigV4 chain resolves natively — which also lets us retire the bearer token and the #24507 main-loop carry-patch entirely.

This reinforces suggested fix #1 in the issue (route the aux Bedrock path through boto3 Converse, mirroring bedrock_adapter) as the durable upstream fix for bearer-only deployments — it would remove the SigV4 requirement for aux the same way #24507 did for the main loop.