feat(bedrock_mantle): add SigV4/IAM auth to Responses API route

[jeremymcgee73]

Relevant issues

Resolves #29665 (SigV4 / IAM-role auth)

Follow-up to #29490, which landed routing and Bearer-token auth for the bedrock-mantle /openai/v1/responses path but explicitly deferred SigV4/IAM auth. This leaves IAM-only deployments (EKS/ECS with IRSA, no long-lived static secrets) with no working path to the Responses endpoint.

Pre-Submission checklist

• 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

Screenshots / Proof of Fix

Tested live against bedrock-mantle.us-east-2.api.aws/openai/v1/responses with IAM creds (Isengard Admin role, no bearer token). Verified sync non-stream, sync stream, and async stream all return 200 with valid Responses payloads, signed with SigV4 from the standard boto3 credential chain.

curl -sS http://localhost:4000/v1/responses \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer sk-anything" \
  -d '{"model":"gpt-5.4-sigv4","input":"hello, what model are you?","stream":true}'

Streaming SSE events returned successfully. Full QA runbook will be added before removing draft status.

Type

New Feature

Changes

BedrockMantleResponsesAPIConfig now multi-inherits BaseAWSLLM and selects auth automatically: a bearer key keeps existing behavior, otherwise it signs with SigV4 from the standard AWS credential chain. Signing uses the provider sign_request hook (added to BaseResponsesAPIConfig), which the Responses HTTP handler invokes after all body mutations and whose returned body bytes it sends verbatim. This mirrors the chat/embedding handler pattern and guarantees the signed body hash matches what goes on the wire.

The default region is corrected to us-east-2 (where these models are currently available), and get_complete_url pins the host region to the resolved signing region so they never diverge.

No routing or price-map changes; #29490 covers those.

[CLAassistant]

All committers have signed the CLA.

[codecov]

Codecov Report

❌ Patch coverage is 97.36842% with 1 line in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
litellm/llms/custom_httpx/llm_http_handler.py	80.00%	1 Missing ⚠️

📢 Thoughts on this report? Let us know!

[Sameerlite]

@greptileai

[greptile-apps]

Greptile Summary

This PR adds SigV4/IAM authentication to the Bedrock Mantle Responses API route, complementing the existing Bearer-token path added in #29490. BedrockMantleResponsesAPIConfig now inherits BaseAWSLLM, detects whether IAM or Bearer auth should be used via a new _use_sigv4 helper, and signs outbound requests through a sign_request hook invoked in llm_http_handler after all body mutations.

• BedrockMantleResponsesAPIConfig multi-inherits BaseAWSLLM and adds _use_sigv4, _explicit_region, and sign_request; the default region is corrected from us-east-1 to us-east-2.
• A no-op sign_request hook is added to BaseResponsesAPIConfig; all four Responses API send paths (sync/async × stream/non-stream) in llm_http_handler now call it and pass data=signed_body when the provider returns bytes.
• Tests cover auth-selection logic, URL construction, region injection, SigV4 signature correctness verified against botocore, and the handler's signed-body branch — all via mocks with no real network calls.

Confidence Score: 4/5

The SigV4 signing flow is correct for primary IAM/IRSA use cases, but _explicit_region (used to build the endpoint URL) does not consult AWS_REGION_NAME, while _use_sigv4 and _get_aws_region_name do — creating a URL vs. signing-region divergence when that env variable is the sole region signal.

Region resolution is split across two helpers: _explicit_region (URL building) omits AWS_REGION_NAME, while _get_aws_region_name (signing) picks it up. A user with only AWS_REGION_NAME=us-west-2 set would get a URL pinned to the default us-east-2 and a signing region also coerced to us-east-2 (because sign_request overwrites region from the URL), silently routing to the wrong region.

litellm/llms/bedrock_mantle/responses/transformation.py — specifically the _explicit_region helper and its relationship to _use_sigv4's env-variable coverage

Important Files Changed

Filename	Overview
litellm/llms/base_llm/responses/transformation.py	Adds a no-op sign_request hook to BaseResponsesAPIConfig; clean extension point with no correctness concerns.
litellm/llms/bedrock_mantle/responses/transformation.py	Adds SigV4/IAM auth alongside existing Bearer-token auth; introduces _use_sigv4, sign_request, and _explicit_region. Region resolution diverges between URL building and signing when AWS_REGION_NAME is the sole signal.
litellm/llms/custom_httpx/llm_http_handler.py	Wires sign_request hook into all four Responses API send paths. Logic is correct and consistent across all call sites.
tests/test_litellm/llms/bedrock_mantle/test_bedrock_mantle_responses_transformation.py	Comprehensive unit tests using mocks only (respx_mock / _RecordingConfig) — no real network calls.

_{Reviews (5): Last reviewed commit: "fix(bedrock_mantle): validate aws_region..." | Re-trigger Greptile}

[Sameerlite]

@jeremymcgee73 Can you please resolve the comments by greptile? Also please take it out of draft once ready for review again

[jeremymcgee73]

@greptileai

[jeremymcgee73]

@greptileai

[veria-ai]

PR overview

All previously flagged issues have been addressed. No open security concerns remain on this pull request.

Security review

No open security issues remain on this pull request.

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

[jeremymcgee73]

@greptileai

[Sameerlite]

Hey @jeremymcgee73 this already got merged: #29788
See if this passing the feat requirements from your side. Else we can fix those

[krrish-berri-2]

@jeremymcgee73 — could you add a screenshot or short video showing that this change works as expected? It really helps reviewers verify the fix quickly. Thanks!

[jeremymcgee73]

Hey @jeremymcgee73 this already got merged: #29788 See if this passing the feat requirements from your side. Else we can fix those

I think we should be good with this MR.