fix(proxy): redact credential headers from request logging copies

[yucheng-berri]

TLDR

Problem this solves:

• Claude subscription OAuth tokens appear in request logs
• Same leak hits BYOK provider keys and session cookies
• Credentials land in spend logs and every logging callback

How it solves it:

• Mask credential headers in the observability copies only
• Keep the real values on the upstream forwarding path
• Drop transport-only keys from the request body snapshot

Relevant issues

Linear ticket

Resolves LIT-5108

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

Setup follows the Claude Code Max subscription tutorial: forward_client_headers_to_llm_api: true, a virtual key passed as x-litellm-api-key, and the subscription OAuth token arriving in Authorization. store_prompts_in_spend_logs: true so the spend log keeps the request, which is what the Admin UI logs page renders.

The reported flow, against real api.anthropic.com

A real Claude Max subscription token driving a real anthropic/claude-haiku-4-5-20251001 deployment, no API key on the deployment at all, so the subscription token is what authenticates upstream. Token values are masked here; the real value went on the wire.

model_list:
  - model_name: anthropic-claude
    litellm_params:
      model: anthropic/claude-haiku-4-5-20251001

general_settings:
  forward_client_headers_to_llm_api: true
  store_prompts_in_spend_logs: true

curl -sS http://127.0.0.1:20108/v1/messages \
  -H "Authorization: Bearer $SUBSCRIPTION_TOKEN" \
  -H "x-litellm-api-key: Bearer $VIRTUAL_KEY" \
  -H "anthropic-beta: oauth-2025-04-20" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -H "user-agent: claude-cli/2.0.1 (external, cli)" \
  -d '{"model":"anthropic-claude","max_tokens":16,
       "system":[{"type":"text","text":"You are Claude Code, Anthropic'"'"'s official CLI for Claude."}],
       "messages":[{"role":"user","content":"Say ok"}]}'

Before, at ba480a619f:

{"model":"anthropic-claude","id":"msg_011CdgJourZNKz7CTancvoCW","type":"message","role":"assistant",
 "content":[{"type":"text","text":"ok"}],"stop_reason":"end_turn",
 "usage":{"input_tokens":23,"output_tokens":4,"service_tier":"standard"}}
HTTP 200

spend log the Admin UI renders:
  1 of 1 rows contain an sk-ant-oat token
  "authorization": "Bearer <SUBSCRIPTION_TOKEN>"

leak paths in the logging callback payload:
  kwargs.litellm_params.litellm_metadata.headers.authorization
  kwargs.litellm_params.metadata.headers.authorization
  kwargs.litellm_params.proxy_server_request.body.litellm_metadata.headers.authorization
  kwargs.litellm_params.proxy_server_request.body.provider_specific_header.extra_headers.authorization
  kwargs.litellm_params.proxy_server_request.headers.authorization

After, at a9d11ee820, same request, same real subscription:

{"model":"anthropic-claude","id":"msg_011CdgJreWucbJFFRHRxwsx8","type":"message","role":"assistant",
 "content":[{"type":"text","text":"ok"}],"stop_reason":"end_turn",
 "usage":{"input_tokens":23,"output_tokens":4,"service_tier":"standard"}}
HTTP 200

spend log the Admin UI renders:
  0 of 1 rows contain an sk-ant-oat token
  "authorization": "***REDACTED***"

leak paths in the logging callback payload:
  NO LEAK

The 200 on the after leg is the forwarding proof: Anthropic still accepted the subscription token, so only the observability copies changed.

Coverage across the other endpoints

The remaining runs below use a synthetic sk-ant-oat01- value, safe to show verbatim, against a real paid provider deployment for anthropic-claude and a local listener for anthropic-upstream that records exactly what LiteLLM sends upstream.

for MODEL in anthropic-claude anthropic-upstream; do
  curl -sS http://127.0.0.1:20108/v1/messages \
    -H "Authorization: Bearer sk-ant-oat01-LIT5108FAKESUBSCRIPTIONTOKENdoNotLogMe" \
    -H "x-litellm-api-key: Bearer $VIRTUAL_KEY" \
    -H "anthropic-version: 2023-06-01" \
    -H "content-type: application/json" \
    -H "user-agent: claude-cli/2.0.1 (external, cli)" \
    -d "{\"model\":\"$MODEL\",\"max_tokens\":16,\"messages\":[{\"role\":\"user\",\"content\":\"Say ok\"}]}"
done

The same request shape was also driven at /v1/chat/completions and /v1/responses; all four calls returned HTTP 200 on both runs.

Before, at ba480a619f

Spend log column the Admin UI reads:

$ psql -c 'select "proxy_server_request" from "LiteLLM_SpendLogs";'
4 of 4 rows leak the token
  "authorization": "Bearer sk-ant-oat01-LIT5108FAKESUBSCRIPTIONTOKENdoNotLogMe"

Where the token sat inside each logging callback payload:

payload 0 (acompletion):
  kwargs.litellm_params.metadata.headers.authorization
  kwargs.litellm_params.metadata.requester_metadata.headers.authorization
  kwargs.litellm_params.proxy_server_request.body.metadata.headers.authorization
  kwargs.litellm_params.proxy_server_request.body.metadata.requester_metadata.headers.authorization
  kwargs.litellm_params.proxy_server_request.body.provider_specific_header.extra_headers.authorization
  kwargs.litellm_params.proxy_server_request.headers.authorization
  kwargs.standard_logging_object.metadata.requester_metadata.headers.authorization
payload 1 (aresponses):
  kwargs.litellm_params.litellm_metadata.headers.authorization
  kwargs.litellm_params.proxy_server_request.body.litellm_metadata.headers.authorization
  kwargs.litellm_params.proxy_server_request.body.provider_specific_header.extra_headers.authorization
  kwargs.litellm_params.proxy_server_request.headers.authorization
payload 2 (anthropic_messages):
  kwargs.litellm_params.litellm_metadata.headers.authorization
  kwargs.litellm_params.proxy_server_request.body.litellm_metadata.headers.authorization
  kwargs.litellm_params.proxy_server_request.body.provider_specific_header.extra_headers.authorization
  kwargs.litellm_params.proxy_server_request.headers.authorization

standard_logging_object is the payload handed to every callback, so the token was reaching Langfuse, Datadog, OTEL and the rest.

After, at c69905b58a

$ psql -c 'select "proxy_server_request" from "LiteLLM_SpendLogs";'
0 of 4 rows leak the token
  "authorization": "***REDACTED***"

leak paths inside each logging callback payload:
  payload 0 (acompletion):       NO LEAK
  payload 1 (aresponses):        NO LEAK
  payload 2 (anthropic_messages): NO LEAK
  payload 3 (anthropic_messages): NO LEAK

Forwarding is unchanged; this is what the Anthropic endpoint received on both runs:

authorization: Bearer sk-ant-oat01-LIT5108FAKESUBSCRIPTIONTOKENdoNotLogMe
anthropic-beta: oauth-2025-04-20

Admin UI logs page

What an operator actually sees. Log in at http://127.0.0.1:20108/ui/, open Logs, click the request row, and switch Request & Response to JSON.

Before, at ba480a619f, the subscription token is rendered in the request headers:

After, at c69905b58a, the same view on the same request shape:

Every credential class, one request

Driving one request carrying all of them, and checking the whole proxy_server_request object:

proxy_server_request["headers"]:
  {"content-type": "application/json",
   "authorization": "***REDACTED***",
   "x-api-key": "***REDACTED***",
   "cookie": "***REDACTED***",
   "hl-project-id": "risk-hl-project",
   "traceparent": "00-1111...-2222...-01",
   "user-agent": "claude-cli/2.0.1 (external, cli)"}

LEAK [oat]:         False
LEAK [virtual-key]: False
LEAK [byok]:        False
LEAK [cookie]:      False

transport intact:
  provider_specific_header.extra_headers = {'authorization': 'Bearer sk-ant-oat01-CORETOKEN'}
  data['api_key']  = BYOK-KEY

Non-credential headers keep their real values, so guardrails and tracing are unaffected.

Proxy stdout

The stdout secret filter only matches Bearer and sk- shaped values, so the request-header debug line printed an MCP auth token in cleartext. That line now formats the redacted copy:

Request Headers: {'x-mcp-auth': '***REDACTED***', 'content-type': 'application/json'}

Type

🐛 Bug Fix

Changes

clean_headers deliberately keeps a few credential headers so the upstream request still authenticates. The problem was that the very same dict object was then stored as proxy_server_request["headers"] and as metadata["headers"] / litellm_metadata["headers"], so anything reading those for observability got the raw credential.

redact_credential_headers now builds a separate masked copy, and the three observability assignments use it while _headers keeps the real values for add_provider_specific_headers_to_request and the forwardable-header path. The masked set is SpecialHeaders.litellm_credential_header_names(), the set the proxy already treats as caller credentials, plus cookie and proxy-authorization, which survive clean_headers with no configuration at all.

The request-header debug line now formats the redacted copy too; the stdout secret filter only matches Bearer and sk- shaped values, so an MCP auth token survived it.

Masking the header dict alone was not enough. proxy_server_request["body"] is a snapshot of the whole request data dict, and three of its keys carry the same credentials one level down: provider_specific_header (the OAuth token, for Anthropic-compatible providers), api_key (the client-supplied BYOK key) and headers (the forwardable x-* set). Those three are transport-only and have to keep their real values, so they join secret_fields in the body-snapshot exclusion rather than being masked.

Behavior changes

Two payload fields now show ***REDACTED*** where they used to carry a real credential value. Both are the intended effect rather than a side effect, but they are observable:

requester_custom_headers in the enterprise standard-logging metadata sweeps every x-* header out of proxy_server_request["headers"], so x-api-key and the MCP auth headers change value there. litellm.extra_spend_tag_headers emits "{name}: {value}" request tags for admin-listed header names, so a deployment that listed a credential header gets a redacted tag value.

proxy_server_request["body"] no longer contains provider_specific_header, api_key or headers. No first-party consumer reads any of those out of the body snapshot.

Known remaining scope

This change covers the credential headers the proxy already recognises. Three related leaks into the same spend-log column are deliberately left for their own PRs, since each is a different credential family or a different code path:

MCP client-side auth headers, both the configurable x-mcp-auth name and the per-server x-mcp-{server_alias}-{header_name} family, still reach the logging copies. Covering them needs runtime config resolution that is worth reviewing on its own.

The generic passthrough at litellm/proxy/pass_through_endpoints/pass_through_endpoints.py stores the unfiltered request.headers, and /queue/chat/completions in litellm/proxy/proxy_server.py stores raw headers while stripping only authorization from its metadata copy. Neither goes through add_litellm_data_to_request.

Final Attestation

• The tests check the right things, including the edge cases, and regressions in the respective real-world customer use-cases are not possible after this PR

---

Note

Medium Risk
Touches security-sensitive logging and spend-log persistence on the main pre-call path; behavior changes are intentional (redacted values in some metadata fields, fewer keys in body snapshots) but upstream forwarding should remain unchanged per tests.

Overview
Fixes credential leakage into spend logs, Admin UI request JSON, logging callbacks, and debug logs when the proxy forwards client auth headers (e.g. Anthropic subscription OAuth in Authorization, BYOK x-api-key, cookies).

Adds redact_credential_headers to build observability-safe header copies (***REDACTED*** for known credential header names plus cookie / proxy-authorization). add_litellm_data_to_request now stores those copies in proxy_server_request["headers"] and metadata headers slots, while _headers still carries real values for provider forwarding and provider_specific_header.

Also expands the proxy_server_request["body"] snapshot exclude list with provider_specific_header, headers, and api_key so nested transport credentials are not persisted in audit/spend payloads. Tests cover OAuth/BYOK/cookie paths, header classification, and debug logging.

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

[greptile-apps]

Greptile Summary

The PR prevents sensitive request data from appearing in observability copies while preserving the transport values needed for upstream requests.

• Adds a centralized helper for producing logging-safe header copies.
• Uses sanitized headers for request metadata, spend-log snapshots, and verbose request-header logging.
• Excludes transport-only credential fields from the stored request-body snapshot.
• Adds regression coverage across supported request paths, credential classes, forwarding behavior, and debug output.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains; the previously reported debug statement now formats the sanitized header copy, while the adjacent raw-header diagnostic remains protected by its redacted string representation.

Important Files Changed

Filename	Overview
litellm/proxy/litellm_pre_call_utils.py	Separates observability-safe request data from transport data and fully addresses the previously reported debug-log issue.
tests/test_litellm/proxy/test_litellm_pre_call_utils.py	Adds focused regression tests confirming sanitized observability copies while preserving upstream forwarding behavior.

_{Reviews (7): Last reviewed commit: "Merge remote-tracking branch 'origin/lit..." | Re-trigger Greptile}

[yucheng-berri]

@greptileai please review the current head 9683d9b

The request-header debug line now formats the redacted copy; the stdout secret filter only matches Bearer and sk- shaped values, so an MCP auth token survived it in cleartext. Added a regression test that fails when the raw dict is logged.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[yucheng-berri]

@greptileai please review the current head 3d4a858

Two Devin findings addressed: the configured MCP auth header name now resolves through get_secret_str so a secret-manager value is masked, and the added inline comments were replaced by a named constant.

[yucheng-berri]

@greptileai please review the current head a9d11ee

Addressed Devin's hot-path finding: the MCP auth header name lookup is now cached per process with lru_cache, since get_secret_str is a blocking secret-manager SDK call and this runs on every proxied request.

[codspeed-hq]

Merging this PR will not alter performance

✅ 31 untouched benchmarks

---

_{Comparing litellm_lit5108_redact_oauth_header_in_logs (b17807d) with litellm_internal_staging (7dab1ff)¹}

Footnotes

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

[yucheng-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 a9d11ee. Configure here.}

[yucheng-berri]

@greptileai please review the current head c69905b

Narrowed the scope: the MCP header-name resolution, its per-request config and secret-manager lookups, and the x-mcp- prefix rule are removed. Those cover a different credential family than this ticket reports and are tracked separately.

[yucheng-berri]

@greptileai review latest head

[yucheng-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 c69905b. Configure here.}

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
1 out of 2 committers have signed the CLA.

✅ yucheng-berri
❌ devin-ai-integration[bot]
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[yucheng-berri]

@greptileai MCP header coverage was cut deliberately, not missed. It needs per-request runtime config resolution that introduced a config-reload staleness bug, so it ships separately; it is listed under Known remaining scope. The debug line still masks authorization, cookie, ocp-apim-subscription-key and proxy-authorization, the exact values the stdout secret filter does not catch, and nothing masked before is unmasked now. Please re-review the current head 4d9f79d

[yucheng-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 4d9f79d. Configure here.}

[devin-ai-integration]

Devin Review found 1 new potential issue.

View 2 additional findings in Devin Review.

[devin-ai-integration]

🟡 New test code is not formatted the way the project requires, so the automated checks fail

Three consecutive blank lines were added between the new test functions (at tests/test_litellm/proxy/test_litellm_pre_call_utils.py:5652-5654, and again at 5678-5680) and the file now ends without a final newline, which the project's mandatory formatter rejects.
Impact: The pull request fails the required formatting check, blocking merge until reformatted.

Black formatting rules enforced in CI

CONTRIBUTING.md states "Black formatting is enforced in CI. All PRs must pass the Black formatting check" and CLAUDE.md requires running make pre-commit before committing. Black collapses runs of more than two blank lines between top-level definitions and requires a trailing newline at end of file. The new blocks at tests/test_litellm/proxy/test_litellm_pre_call_utils.py:5652-5654 and tests/test_litellm/proxy/test_litellm_pre_call_utils.py:5678-5680 each contain three blank lines, and the final line tests/test_litellm/proxy/test_litellm_pre_call_utils.py:5872 has no newline terminator, so make format-check / make lint fails.

Suggested change

	@pytest.mark.parametrize(
	@pytest.mark.parametrize(

---

Was this helpful? React with 👍 or 👎 to provide feedback.