fix(completion): forward aws credential kwargs into litellm_params so the responses bridge keeps WIF auth

[mateo-berri]

Relevant issues

Pylon #5084

Linear ticket

Resolves LIT-3859

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 CI/CD checks (e.g., lint, format, unit tests)
• My PR's scope is as isolated as possible; it only solves 1 specific problem
• I have received a Greptile Confidence Score of at least 4/5 before requesting a maintainer review (Greptile reviews automatically once the PR is opened; only comment @greptileai to re-request a review after pushing changes)

Delays in PR merge?

If you're seeing a delay in your PR being merged, ping the LiteLLM Team on Slack (#pr-review).

Screenshots / Proof of Fix

Live proxy with two bedrock_mantle/openai.gpt-5.5 deployments (a responses-only model, so /v1/chat/completions goes through the chat -> Responses API bridge). One deployment uses web identity federation like the reporting customer's config, backed by a real Google-issued OIDC token and a real IAM role (accounts.google.com OIDC provider + role in a dev account, trust policy locked to a single Google account); the other uses static keys. The proxy process is scrubbed of every ambient AWS credential source (no AWS_ACCESS_KEY_ID/AWS_SESSION_TOKEN/AWS_BEARER_TOKEN_BEDROCK/BEDROCK_MANTLE_API_KEY in env, AWS_CONFIG_FILE=/dev/null, AWS_SHARED_CREDENTIALS_FILE=/dev/null, AWS_EC2_METADATA_DISABLED=true), so the deployment litellm_params are the only possible credential source

model_list:
  - model_name: mantle-gpt-5.5-wif
    litellm_params:
      model: bedrock_mantle/openai.gpt-5.5
      api_base: https://bedrock-mantle.us-east-2.api.aws/v1
      aws_region_name: us-east-2
      aws_session_name: litellm-gcp
      aws_role_name: arn:aws:iam::439158074652:role/litellm-wif-proof-role
      aws_web_identity_token: oidc/file//secrets/wif-creds/token
  - model_name: mantle-gpt-5.5-keys
    litellm_params:
      model: bedrock_mantle/openai.gpt-5.5
      api_base: https://bedrock-mantle.us-east-2.api.aws/v1
      aws_region_name: us-east-2
      aws_access_key_id: os.environ/MANTLE_AWS_ACCESS_KEY_ID
      aws_secret_access_key: os.environ/MANTLE_AWS_SECRET_ACCESS_KEY
      aws_session_token: os.environ/MANTLE_AWS_SESSION_TOKEN

general_settings:
  master_key: sk-1234

gcloud auth print-identity-token > /secrets/wif-creds/token
LITELLM_OIDC_ALLOWED_CREDENTIAL_DIRS=/secrets/wif-creds \
  python litellm/proxy/proxy_cli.py --config lit3859_proof.yaml --port 4020

curl -sS http://localhost:4020/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer sk-1234' \
  -d '{"model": "mantle-gpt-5.5-wif", "messages": [{"role": "user", "content": "Reply with exactly: hello from bedrock mantle via wif"}]}'

Before, captured at f2fb6b8 (the commit this branch is based on), both deployments fail with the exact error from the ticket even though the credentials are sitting in the config:

{
    "error": {
        "message": "litellm.APIConnectionError: Bedrock Mantle auth failed: no Bearer token and no usable AWS credentials. Set BEDROCK_MANTLE_API_KEY (or AWS_BEARER_TOKEN_BEDROCK) or pass api_key for Bearer auth, or provide AWS credentials (IAM role / access key / profile / web identity) for SigV4.\nTraceback (most recent call last):\n  File \".../litellm/llms/bedrock_mantle/common_utils.py\", line 86, in sign_request\n    return self._aws_signer._sign_request(\n  File \".../litellm/llms/bedrock/base_aws_llm.py\", line 1528, in _sign_request\n    sigv4.add_auth(request)\n  File \".../botocore/auth.py\", line 429, in add_auth\n    raise NoCredentialsError()\nbotocore.exceptions.NoCredentialsError: Unable to locate credentials\n...",
        "code": "500"
    }
}

After the first fix, captured at e0463a3, the static-keys deployment returns a real completion from the live us-east-2 Bedrock Mantle endpoint (real tokens billed, no mocks):

{
    "id": "chatcmpl-585b4284-0f82-4bb1-9fd7-ab6b282d8cea",
    "created": 1783811850,
    "model": "mantle-gpt-5.5-keys",
    "object": "chat.completion",
    "choices": [
        {
            "finish_reason": "stop",
            "index": 0,
            "message": {
                "content": "hello from bedrock mantle",
                "role": "assistant"
            }
        }
    ],
    "usage": {
        "completion_tokens": 20,
        "prompt_tokens": 15,
        "total_tokens": 35
    }
}

but the WIF deployment, whose credentials now do reach STS (real AssumeRoleWithWebIdentity succeeds), surfaced a second bug at the same commit; the hardcoded session policy sent with the STS call does not cover the bedrock-mantle action namespace, so the request is denied regardless of what the role's identity policy grants:

{
    "error": {
        "message": "litellm.APIConnectionError: Bedrock_mantleException - {\"error\":{\"code\":\"access_denied\",\"message\":\"User: arn:aws:sts::439158074652:assumed-role/litellm-wif-proof-role/litellm-gcp is not authorized to perform: bedrock-mantle:CreateInference on resource: arn:aws:bedrock-mantle:us-east-2:439158074652:project/default because no session policy allows the bedrock-mantle:CreateInference action\",\"param\":null,\"type\":\"permission_denied_error\"}}...",
        "code": "500"
    }
}

After both fixes, captured at 201730e, the WIF deployment completes the full chain for real (Google OIDC token from file -> STS AssumeRoleWithWebIdentity -> SigV4 -> live Mantle endpoint):

{
    "id": "chatcmpl-dac3820f-55eb-411d-afed-48f9c0961f23",
    "created": 1783812806,
    "model": "mantle-gpt-5.5-wif",
    "object": "chat.completion",
    "choices": [
        {
            "finish_reason": "stop",
            "index": 0,
            "message": {
                "content": "hello from bedrock mantle via wif",
                "role": "assistant"
            }
        }
    ],
    "usage": {
        "completion_tokens": 23,
        "prompt_tokens": 18,
        "total_tokens": 41
    }
}

Streaming through the same WIF deployment also works:

data: {"id":"chatcmpl-41209fb1-951c-46a2-95b3-409d5113d78f","object":"chat.completion.chunk","created":1783812819,"model":"mantle-gpt-5.5-wif","choices":[{"index":0,"delta":{"role":"assistant","content":"stream"}}]}
data: {"id":"chatcmpl-d104dbf4-1093-4f60-9573-fe00c7aeaa8e","object":"chat.completion.chunk","created":1783812819,"model":"mantle-gpt-5.5-wif","choices":[{"index":0,"delta":{"content":"ed"}}]}
...

Customer-identical rig: the runs above fed the Google OIDC token via oidc/file//. To remove even that delta, the same before/after was repeated on a fresh GCE instance (Debian 12, service account attached), where the config uses the customer's exact token style (oidc/google/<service-account-unique-id>) so litellm fetches the identity token from the GCP metadata server itself; no token file, no AWS credentials anywhere on the box

      aws_session_name: litellm-gcp
      aws_role_name: arn:aws:iam::439158074652:role/litellm-wif-proof-role
      aws_web_identity_token: oidc/google/116028322316888866787

Before, captured at f2fb6b8 on the instance, the identical customer error:

litellm.APIConnectionError: Bedrock Mantle auth failed: no Bearer token and no usable AWS credentials. Set BEDROCK_MANTLE_API_KEY (or AWS_BEARER_TOKEN_BEDROCK) or pass api_key for Bearer auth, or provide AWS credentials (IAM role / access key / profile / web identity) for SigV4.

After, captured at cc27528 (branch head) on the instance, a real completion over the full metadata-server -> STS -> SigV4 chain, streaming included:

{"id":"chatcmpl-b44f6951-8574-4ba4-8c9d-ffc20897b82e","created":1783815213,"model":"mantle-gpt-5.5-wif","object":"chat.completion","choices":[{"finish_reason":"stop","index":0,"message":{"content":"hello from bedrock mantle via wif","role":"assistant"}}],"usage":{"completion_tokens":24,"prompt_tokens":18,"total_tokens":42}}

Type

🐛 Bug Fix

Changes

Two bugs, both required for WIF (and any other aws_* credential style) to work on bedrock_mantle models reached via chat completions

First: chat completions requests to responses-only bedrock_mantle models (mode: responses in the price map, e.g. openai.gpt-5.4/openai.gpt-5.5) are routed through the chat -> Responses API bridge (litellm/completion_extras/litellm_responses_transformation). The bridge's internal aresponses call takes its credentials from litellm_params, which completion() builds via get_litellm_params; that call's explicit argument list forwarded aws_bedrock_project_id but none of the other aws_* credential kwargs (aws_role_name, aws_web_identity_token, aws_session_name, aws_access_key_id, aws_secret_access_key, aws_session_token, aws_profile_name, aws_external_id, aws_sts_endpoint, ...). SigV4 signing then fell back to botocore's default chain and raised NoCredentialsError ("Bedrock Mantle auth failed: no Bearer token and no usable AWS credentials") even though the deployment config carried valid credentials. Direct /v1/responses requests never hit this path, which is why the same deployment worked there. The fix defines AWS_CREDENTIAL_KWARGS_KEYS in litellm/litellm_core_utils/get_litellm_params.py (folded into the existing OPTIONAL_KWARGS_KEYS) and has completion() spread exactly those keys from kwargs into its get_litellm_params call. A side effect is that aws_bedrock_project_id is now only present in litellm_params when the caller passed it, instead of always being present as None; all consumers read it with .get() or pydantic attribute access, so this is safe

Second: _auth_with_web_identity_token attaches an inline session policy to AssumeRoleWithWebIdentity, which acts as a permission ceiling on the resulting credentials. It covered bedrock:* invoke actions and the aws-external-anthropic:* namespace (added for claude_platform in #30200) but not bedrock-mantle:*, so once credentials were forwarded, every Mantle request over OIDC/WIF auth still failed with "no session policy allows the bedrock-mantle:CreateInference action" no matter how permissive the role's identity policy was. The fix adds a BedrockMantleLiteLLM statement allowing bedrock-mantle:CreateInference (the only action the provider's chat and responses surfaces need), with the same aws:SecureTransport condition as the existing statements. Static-credential and IRSA paths were unaffected since they do not attach this session policy

The ticket proposed switching dict(litellm_params) to model_dump() in async_response_api_handler; I tested that first and it does not address the bug, since pydantic >= 2.10 iteration already includes __pydantic_extra__ and the params are dropped earlier, in completion()

Regression tests: test_acompletion_forwards_aws_credentials_through_responses_bridge in tests/test_litellm/test_main.py drives acompletion on a responses-only Mantle model, parametrized over both credential styles (role/web-identity/session and static key/secret/session-token), and asserts each kwarg reaches get_credentials and that the outgoing request is SigV4 signed; TestBedrockMantleActionsCovered in tests/test_litellm/llms/bedrock/test_web_identity_session_policy.py asserts the session policy grants bedrock-mantle:CreateInference with the hardening conditions intact. Each fails without its corresponding fix and passes with it (verified by mutating AWS_CREDENTIAL_KWARGS_KEYS and the session policy)

[greptile-apps]

Greptile Summary

Fixes two independent bugs that together prevented AWS credential kwargs (aws_role_name, aws_web_identity_token, aws_access_key_id, etc.) from reaching the SigV4 signer when chat-completions requests are routed through the chat → Responses API bridge, and removes a session-policy ceiling that silently denied all bedrock-mantle:CreateInference calls made via OIDC/WIF auth.

• get_litellm_params.py / main.py: Extracts AWS_CREDENTIAL_KWARGS_KEYS from OPTIONAL_KWARGS_KEYS and replaces the single aws_bedrock_project_id=kwargs.get(...) arg in completion() with a dict-comprehension spread of all present AWS credential keys, so the responses bridge picks them up from litellm_params rather than falling back to botocore's ambient credential chain.
• base_aws_llm.py: Adds a BedrockMantleLiteLLM IAM statement to the inline STS session policy, allowing bedrock-mantle:CreateInference under aws:SecureTransport, matching the pattern established for the existing Bedrock and Claude Platform statements.
• Tests: New unit tests in test_web_identity_session_policy.py verify the policy statement is correct and not over-broad; test_main.py adds an end-to-end mock test parametrized over WIF and static-key credential styles, asserting kwargs propagation and SigV4 signing without real network calls.

Confidence Score: 5/5

The changes are well-scoped and additive; the credential forwarding fix is a straightforward refactor and the session policy addition follows the established pattern with no regressions.

Both fixes are narrowly targeted and well-tested. The credential forwarding change replaces one hard-coded key with a frozenset-driven spread. The session policy addition is purely additive. All tests are properly mocked with no real network calls.

No files require special attention.

Important Files Changed

Filename	Overview
litellm/litellm_core_utils/get_litellm_params.py	Extracts AWS credential keys into a separate AWS_CREDENTIAL_KWARGS_KEYS frozenset and composes it back into OPTIONAL_KWARGS_KEYS via union; adds a backward-compatible alias _OPTIONAL_KWARGS_KEYS
litellm/main.py	Replaces the single hard-coded aws_bedrock_project_id=kwargs.get(...) arg with a dict-comprehension spread of all AWS_CREDENTIAL_KWARGS_KEYS present in kwargs, forwarding the full AWS credential set into litellm_params
litellm/llms/bedrock/base_aws_llm.py	Adds a BedrockMantleLiteLLM statement to the inline STS session policy allowing bedrock-mantle:CreateInference with aws:SecureTransport condition, unblocking WIF/OIDC auth for Bedrock Mantle models
tests/test_litellm/llms/bedrock/test_web_identity_session_policy.py	Adds TestBedrockMantleActionsCovered class with four unit tests verifying the new session policy statement is correct and not over-broad
tests/test_litellm/test_main.py	Adds a parametrized mock test covering WIF and static-key credential paths, verifying kwargs propagation and SigV4 signing without real network calls

_{Reviews (2): Last reviewed commit: "test(main): assert the responses bridge ..." | Re-trigger Greptile}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[mateo-berri]

@greptileai

[veria-ai]

High: Client-controlled AWS profiles are used for signing

This forwards aws_profile_name from the request even though the proxy's banned-parameter check does not reject it. BaseAWSLLM passes that value to boto3.Session(profile_name=...), so an authenticated caller can make a bridged Mantle request using any named AWS profile installed on the proxy host instead of the deployment's configured identity. Restrict bridge propagation to configuration-sourced authentication parameters, or ban aws_profile_name from proxy request bodies unless client-side credentials are explicitly enabled.

[veria-ai]

PR overview

This pull request updates the completion-to-responses bridge so AWS credential-related keyword arguments are forwarded into litellm_params, preserving Workload Identity Federation authentication for bridged LiteLLM calls.

There is one open security concern: request-supplied AWS profile names can be propagated into signing logic, allowing an authenticated caller to select any AWS profile present on the proxy host rather than the deployment’s intended identity. That creates a clear credential-boundary bypass if multiple profiles are installed. No issues have been addressed yet, so the PR still needs a restriction to configuration-sourced authentication parameters or explicit rejection of client-controlled AWS profile selection.

Open issues (1)

• High: Client-controlled AWS profiles are used for signing — litellm/main.py:5328

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

[codspeed-hq]

Merging this PR will not alter performance

✅ 31 untouched benchmarks

---

_{Comparing litellm_fix_lit3859_wif_bridge (cc27528) with litellm_internal_staging (e7f4144)¹}

Footnotes

1. No successful run was found on litellm_internal_staging (5e1928c) during the generation of this report, so e7f4144 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩