fix(bedrock_mantle): add SigV4 fallback to chat completions auth

[mateo-berri]

Relevant issues

Based on the work of @6matt in #30693; this branch carries those commits onto litellm_internal_staging so we can run CI, with a follow-up that delegates Bearer-token resolution in both configs to the shared mixin. Credit for the original fix goes to @6matt

Linear ticket

Pre-Submission checklist

Please complete all items before asking a LiteLLM maintainer to review your PR

• I have added meaningful tests
• My PR passes all unit tests on make test-unit
• My PR's scope is as isolated as possible; it only solves 1 specific problem
• I have requested a Greptile review by commenting @greptileai and received a Confidence Score of at least 4/5 before requesting a maintainer review

CI (LiteLLM team)

• Branch creation CI run
  Link:

• CI run for the last commit
  Link:

• Merge / cherry-pick CI run
  Links:

Screenshots / Proof of Fix

Ran a live proxy against real Bedrock Mantle with a chat model that has no api_key configured, so it must fall back to SigV4 over default AWS credentials (no Bearer token in the environment).

dev_config.yaml entry used for the run (not part of this PR):

  - model_name: mantle-gpt-oss-120b
    litellm_params:
      model: bedrock_mantle/openai.gpt-oss-120b
      aws_region_name: us-east-1

AWS_PROFILE=... AWS_REGION=us-east-1 python litellm/proxy/proxy_cli.py \
  --config litellm/proxy/dev_config.yaml --detailed_debug 2>&1 | tee litellm.log

curl -sS http://localhost:4000/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer sk-1234' \
  -d '{"model": "mantle-gpt-oss-120b", "messages": [{"role": "user", "content": "Say hello in exactly one short sentence."}]}'

Response:

{
    "id": "chatcmpl-710687e4-6053-42aa-8d64-dd6b8dd7008b",
    "model": "mantle-gpt-oss-120b",
    "object": "chat.completion",
    "choices": [
        {
            "finish_reason": "stop",
            "index": 0,
            "message": {"content": "Hello!", "role": "assistant"}
        }
    ],
    "usage": {"completion_tokens": 99, "prompt_tokens": 75, "total_tokens": 174}
}

The proxy log confirms the outbound request to Mantle was signed with SigV4 (note X-Amz-Date, X-Amz-Security-Token, and an Authorization header whose masked value begins with AW, i.e. AWS4-HMAC-SHA256, not Bearer):

POST Request Sent from LiteLLM:
curl -X POST \
https://bedrock-mantle.us-east-1.api.aws/v1/chat/completions \
-H 'Content-Type: application/json' -H 'X-Amz-Date: 20260617T224704Z' -H 'X-Amz-Security-Token: IQ****w=' -H 'Authorization: AW****ec' \
-d '{'model': 'openai.gpt-oss-120b', 'messages': [{'role': 'user', 'content': 'Say hello in exactly one short sentence.'}], 'stream': False}'

Before this change the same config returns an auth error because the chat backend never signs the request and sends no credentials.

Type

🐛 Bug Fix

Changes

BedrockMantleResponsesAPIConfig authenticates with a Bearer token when one is available and otherwise falls back to AWS SigV4 over the standard credential chain, but BedrockMantleChatConfig was Bearer-only. The chat HTTP handler already calls the sign_request hook on the provider config; the chat config simply inherited the no-op BaseConfig.sign_request, so the same provider behaved differently across its two backends and chat-completions users were forced to set a static key even when IAM-role or default AWS credentials were available.

This factors the Bearer-or-SigV4 logic out of the responses config into a shared BedrockMantleAuthMixin in litellm/llms/bedrock_mantle/common_utils.py and applies it to both configs, so the two paths can never drift apart. The Bearer precedence is litellm_params.api_key, then BEDROCK_MANTLE_API_KEY, then the standard AWS_BEARER_TOKEN_BEDROCK; with no token it SigV4-signs for service bedrock with the region pinned to the already region-resolved request host. The chat config takes an injected aws_signer so the SigV4 branch is unit-testable with a mock signer instead of monkeypatching.

Two pre-existing chat-config inconsistencies are fixed along the way. The chat path now honors AWS_BEARER_TOKEN_BEDROCK as a Bearer source the way the responses path already did, and the misleading BEDROCK_MANTLE_{REGION}_API_KEY region-aware fallback advertised in the chat docstring (which the code never read) is removed.

Tests extend tests/test_litellm/llms/bedrock_mantle/test_bedrock_mantle_transformation.py with a TestBedrockMantleChatAuth class covering Bearer-skips-SigV4, the BEDROCK_MANTLE_API_KEY and AWS_BEARER_TOKEN_BEDROCK Bearer sources, SigV4 signing with the credential scope resolved from the request host, and a clear ValueError when neither a token nor usable credentials exist. Each case fails against the no-op sign_request the chat config inherited before this change.

---

Note

Medium Risk
Touches authentication for outbound Bedrock Mantle requests (Bearer vs SigV4 and region scoping); behavior change for chat without API keys, with broad unit/e2e test coverage.

Overview
Bedrock Mantle chat completions now use the same Bearer-or-SigV4 auth as the Responses backend, instead of inheriting a no-op sign_request and failing when only IAM/default AWS credentials are available.

Auth is centralized in BedrockMantleAuthMixin (common_utils.py): Bearer from api_key → BEDROCK_MANTLE_API_KEY → AWS_BEARER_TOKEN_BEDROCK, else SigV4 for service bedrock. On SigV4, the signing region is pinned to the Mantle host in api_base (not a mismatched aws_region_name), with caller Authorization stripped so SigV4 is not overridden.

BedrockMantleChatConfig and BedrockMantleResponsesAPIConfig both mix in the shared helper; duplicate auth/region logic is removed from Responses. Chat gains injectable aws_signer for tests, honors AWS_BEARER_TOKEN_BEDROCK, and drops the unused BEDROCK_MANTLE_{REGION}_API_KEY doc claim.

Tests add TestBedrockMantleChatAuth (Bearer paths, SigV4, region mismatch, missing creds, e2e litellm.completion).

^{Reviewed by Cursor Bugbot for commit 949815a. Bugbot is set up for automated code reviews on this repo. Configure here.}

[mateo-berri]

@greptileai

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[greptile-apps]

Greptile Summary

This PR centralizes Bedrock Mantle authentication into a new BedrockMantleAuthMixin (common_utils.py) and applies it to both the Chat Completions and Responses backends, fixing a bug where chat-completions users relying on IAM roles or default AWS credentials received auth errors because the chat config inherited a no-op sign_request.

• BedrockMantleAuthMixin implements shared _resolve_bearer_token (precedence: litellm_params.api_key → BEDROCK_MANTLE_API_KEY → AWS_BEARER_TOKEN_BEDROCK), _resolve_region, and a sign_request that signs with Bearer when a token is available and falls back to SigV4 (service bedrock) otherwise; the SigV4 path pins the credential-scope region to the api_base URL host to prevent scope/URL mismatches.
• BedrockMantleChatConfig now inherits the mixin, gains an injected aws_signer for testability, and _get_openai_compatible_provider_info now correctly surfaces all three Bearer sources (including AWS_BEARER_TOKEN_BEDROCK) via _resolve_bearer_token.
• Tests cover all Bearer sources, SigV4 host-derived region, region/URL disagreement, missing-credential error, and an end-to-end litellm.completion smoke test — all using mocked HTTP/credentials, no real network calls.

Confidence Score: 5/5

Safe to merge — the change is additive for chat users (previously broken without a static key, now works with IAM/SigV4) and preserves all existing behavior for users who already supply a Bearer token.

The auth logic is factored cleanly into a mixin and shared between both backends, eliminating the drift that caused the original bug. The Bearer-or-SigV4 precedence chain is identical to what the Responses backend already had in production. Tests are comprehensive, mock-only, and cover every branch including the edge case where api_base region and aws_region_name disagree. No pre-existing issues were found unaddressed.

No files require special attention.

Important Files Changed

Filename	Overview
litellm/llms/bedrock_mantle/common_utils.py	New file: BedrockMantleAuthMixin with shared Bearer-or-SigV4 sign_request, _resolve_bearer_token, and _resolve_region logic. Well-structured, exception handling is correct, URL-host region pinning is intentional and tested.
litellm/llms/bedrock_mantle/chat/transformation.py	BedrockMantleChatConfig now inherits BedrockMantleAuthMixin, wires _aws_signer in init, and delegates dynamic_api_key resolution to _resolve_bearer_token (fixing both BEDROCK_MANTLE_API_KEY and AWS_BEARER_TOKEN_BEDROCK coverage).
litellm/llms/bedrock_mantle/responses/transformation.py	BedrockMantleResponsesAPIConfig now inherits BedrockMantleAuthMixin; duplicated _resolve_region, sign_request, and bearer-resolution logic removed and replaced by the mixin. validate_environment now calls _resolve_bearer_token consistently.
tests/test_litellm/llms/bedrock_mantle/test_bedrock_mantle_transformation.py	Adds TestBedrockMantleChatAuth covering Bearer precedence, all env-var sources, host-derived SigV4 region, region/URL mismatch, missing-credential ValueError, and an end-to-end completion smoke test with patched HTTP handler (no real network calls).

_{Reviews (4): Last reviewed commit: "fix(bedrock_mantle): pin chat SigV4 scop..." | Re-trigger Greptile}

[greptile-apps]

Greptile Summary

This PR fixes a missing SigV4 fallback in the Bedrock Mantle chat completions path. Previously BedrockMantleChatConfig inherited the no-op BaseConfig.sign_request, so requests with no Bearer token always failed to authenticate even when IAM or default AWS credentials were available.

• Introduces BedrockMantleAuthMixin in common_utils.py with the shared Bearer-or-SigV4 logic (including _resolve_bearer_token and _resolve_region), then applies it to both BedrockMantleChatConfig and BedrockMantleResponsesAPIConfig via MRO, eliminating the previous duplication and drift risk.
• Adds an injected aws_signer parameter to BedrockMantleChatConfig.__init__ so the SigV4 branch is unit-testable without monkeypatching, and backs it with 6 new mock-only tests covering all Bearer sources, SigV4 region resolution from the URL host, and the no-credentials ValueError.

Confidence Score: 4/5

The auth fix is contained entirely within the Bedrock Mantle provider directory, the Responses path is behaviour-identical after the refactor, and the new tests validate each auth branch with injected mocks rather than live credentials.

The core sign_request logic is a clean lift-and-shift from the Responses config; both old and new code are functionally identical for the Responses path and the new Chat path exercises the same code. The one asymmetry worth noting is that _get_openai_compatible_provider_info does not include AWS_BEARER_TOKEN_BEDROCK in the dynamic_api_key it returns, so that source is resolved only inside sign_request rather than also appearing in validate_environment or in the logged api_key, unlike what the Responses config does in its validate_environment override.

litellm/llms/bedrock_mantle/chat/transformation.py — _get_openai_compatible_provider_info still excludes AWS_BEARER_TOKEN_BEDROCK from the returned api_key, creating a minor asymmetry with the Responses backend's validate_environment.

Important Files Changed

Filename	Overview
litellm/llms/bedrock_mantle/common_utils.py	New file introducing BedrockMantleAuthMixin with shared Bearer-or-SigV4 logic; logic is functionally identical to the old sign_request on the Responses config, plus a static _resolve_bearer_token helper.
litellm/llms/bedrock_mantle/chat/transformation.py	Adds BedrockMantleAuthMixin to the MRO, injects aws_signer in init, and updates the docstring; no logic removed from other methods.
litellm/llms/bedrock_mantle/responses/transformation.py	Cleanly removes the now-moved sign_request and _resolve_region implementations; all other methods are unchanged.
tests/test_litellm/llms/bedrock_mantle/test_bedrock_mantle_transformation.py	Adds 6 new unit tests covering each Bearer source, the SigV4 path including region-from-host resolution, and the no-credentials ValueError; all mock-only, no real network calls.

Comments Outside Diff (1)

1. litellm/llms/bedrock_mantle/chat/transformation.py, line 65-66 (link)

   AWS_BEARER_TOKEN_BEDROCK not surfaced through _get_openai_compatible_provider_info

   _get_openai_compatible_provider_info sets dynamic_api_key = api_key or get_secret_str("BEDROCK_MANTLE_API_KEY") and does not include AWS_BEARER_TOKEN_BEDROCK. When that env var is the only auth source, dynamic_api_key is None, so validate_environment (via the OpenAI parent) never sets an Authorization header and the logging layer logs no key. Auth ultimately succeeds because sign_request → _resolve_bearer_token re-checks AWS_BEARER_TOKEN_BEDROCK, but the two resolution paths are now subtly asymmetric. Adding or get_secret_str("AWS_BEARER_TOKEN_BEDROCK") to dynamic_api_key here would make them consistent with the Responses config's validate_environment, which already includes that source.

_{Reviews (2): Last reviewed commit: "style(bedrock_mantle): use X | None over..." | Re-trigger Greptile}

[mateo-berri]

Addressed both P2 "Comments Outside Diff" in 1b2d022.

Both spots resolved the Bearer token inline, duplicating the precedence chain in BedrockMantleAuthMixin._resolve_bearer_token. They now delegate to it:

• BedrockMantleResponsesAPIConfig.validate_environment calls self._resolve_bearer_token(litellm_params.api_key) instead of repeating the api_key -> BEDROCK_MANTLE_API_KEY -> AWS_BEARER_TOKEN_BEDROCK chain, so the early Authorization header can no longer drift from the authoritative sign_request
• BedrockMantleChatConfig._get_openai_compatible_provider_info now returns self._resolve_bearer_token(api_key) as dynamic_api_key, which also fixes the asymmetry you flagged where a sole AWS_BEARER_TOKEN_BEDROCK was dropped from the key handed back to the framework

Existing responses validate_environment tests cover the three Bearer sources unchanged, and a new test_api_key_from_aws_bearer_token_bedrock_env locks in the chat behavior (it fails against the previous inline lookup).

@greptileai

[greptile-apps]

The changes look good. The refactoring is clean and correctly addresses both issues:

1. BedrockMantleResponsesAPIConfig.validate_environment now delegates to self._resolve_bearer_token(litellm_params.api_key) — the precedence chain lives in exactly one place.
2. BedrockMantleChatConfig._get_openai_compatible_provider_info returns self._resolve_bearer_token(api_key) as dynamic_api_key, which correctly includes AWS_BEARER_TOKEN_BEDROCK as a Bearer source (fixing the asymmetry).

One small thing worth confirming: _get_openai_compatible_provider_info may return None as dynamic_api_key when no Bearer token is found. The framework then passes api_key=None into validate_environment and subsequently into sign_request. Worth verifying that the parent OpenAILikeChatConfig.validate_environment doesn't reject or short-circuit on a None api_key before sign_request gets invoked — if it does, the SigV4 path could silently fail. A test that traces the full chain with api_key=None through to sign_request being called (rather than just checking the output) would make this airtight.

Everything else looks solid. The mixin approach is the right structural call here.

[mateo-berri]

Added that end-to-end test in 1d0e2db.

test_completion_no_bearer_signs_with_sigv4_end_to_end drives litellm.completion(model="bedrock_mantle/openai.gpt-oss-120b") with no Bearer token anywhere and AWS creds in the environment, then asserts the outbound request (captured at the HTTP layer) carries Authorization: AWS4-HMAC-SHA256 ... /us-east-2/bedrock/aws4_request. That exercises the whole chain rather than sign_request in isolation, so it would fail if the parent OpenAILikeChatConfig.validate_environment ever short-circuited on api_key=None before sign_request runs. Confirmed validate_environment only sets a Bearer header if api_key is not None and never rejects None, so the SigV4 path stays reachable.

@greptileai

[mateo-berri]

bugbot run

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

Autofix Details

Bugbot Autofix prepared a fix for the issue found in the latest run.

• ✅ Fixed: Chat SigV4 region URL mismatch
  • In sign_request, the credential-scope region is now extracted directly from the Mantle api_base host so the SigV4 scope always matches the URL even when aws_region_name disagrees, with _resolve_region used only as a fallback for non-standard proxy hosts.

_{You can send follow-ups to the cloud agent here.}

[CLAassistant]

All committers have signed the CLA.

[mateo-berri]

@greptileai

[mateo-berri]

bugbot run

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit 949815a. Configure here.}

[Sameerlite]

LGTM

[veria-ai]

Medium: AWS SigV4 headers sent to client-controlled hosts

When no bearer token is set, this signs the request for whatever api_base is passed in. On the proxy path, api_base is a supported client-side credential override, so a caller can send a Bedrock Mantle request with api_base pointing at a host they control and collect the proxy's SigV4 Authorization and X-Amz-Security-Token headers. Require SigV4 only for the resolved Mantle endpoint or an admin-configured base, or reject client-supplied/custom api_base unless the request also supplies a bearer token.

[mateo-berri]

The premise here is incorrect: api_base is not a client-side override on the proxy by default. It sits in _BANNED_REQUEST_BODY_PARAMS (litellm/proxy/auth/auth_utils.py:254), and is_request_body_safe -> _check_banned_params rejects any client-supplied api_base with a 400 before the request ever reaches a provider. That guard is enforced unconditionally; the only way a caller's api_base is honored is if an admin has explicitly opted in via general_settings.allow_client_side_credentials (proxy-wide) or configurable_clientside_auth_params on the deployment. This is exactly the SSRF/key-exfil hole tracked in huntr 4001e1a2 that the banned-param blocklist exists to close, so the "caller points api_base at a host they control and collects the SigV4 headers" path is closed for bedrock_mantle like every other provider.

If an admin does turn on allow_client_side_credentials, that is a deliberate, provider-wide decision to let callers route with the proxy's credentials, and it applies identically to the OpenAI api_key, the Azure AD token, Vertex credentials, and the main bedrock provider's own SigV4 signing. Nothing in this PR widens that surface.

On the SDK path there is no untrusted caller; the developer sets api_base in their own process.

Finally, this SigV4-to-api_base behavior is not new. It is the pre-existing logic from BedrockMantleResponsesAPIConfig that this PR factored into the shared mixin, and it mirrors how litellm's main bedrock provider signs. Restricting Mantle's SigV4 to a host allowlist would diverge from every other AWS-signed provider and break legitimate custom endpoints (VPC/PrivateLink, FIPS, GovCloud). Treating this as a no-op for the PR

---

Generated by Claude Code

[veria-ai]

PR overview

This PR updates Bedrock Mantle chat completions authentication to fall back to AWS SigV4 signing when no bearer token is configured. The touched auth utility code builds the request headers used for Bedrock Mantle calls.

There is one open security issue: on the proxy path, a caller-controlled api_base can cause the SigV4 fallback to send AWS authorization headers to an arbitrary host. That exposes proxy-generated AWS auth material to an attacker-controlled endpoint, so the fallback should be restricted to trusted Mantle endpoints or require bearer-token authentication for custom bases. No issues have been fixed yet.

Open issues (1)

• Medium: AWS SigV4 headers sent to client-controlled hosts — litellm/llms/bedrock_mantle/common_utils.py:93

Fixed/addressed: 0 · PR risk: 6/10