fix(proxy): never log raw virtual keys in key insertion debug output

[yucheng-berri]

Relevant issues

Linear ticket

Resolves LIT-4356

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

Repro setup for both runs: proxy started against a fresh Postgres with --detailed_debug and the full output tee'd to a log file, then a virtual key is generated with a deliberately short custom value so it cannot match the sk-[A-Za-z0-9\-_]{20,} pattern the log-level SecretRedactionFilter relies on

uv run litellm --config config.yaml --port 4356 --detailed_debug 2>&1 | tee litellm.log

curl -sS http://localhost:4356/key/generate \
  -H "Authorization: Bearer sk-1234" -H "Content-Type: application/json" \
  -d '{"key":"sk-short-secret","key_alias":"redaction-repro"}'

Before (unfixed, captured at 939117bb8d): the raw key appears in the debug output at both sites

grep -Fn 'sk-short-secret' litellm.log | grep -i 'insert_data\|Creating Key'
257:13:22:33 - LiteLLM Proxy:DEBUG: key_management_endpoints.py:3780 - prisma_client: Creating Key= {'token': 'sk-short-secret', 'key_alias': 'redaction-repro', ...}
258:13:22:33 - LiteLLM Proxy:DEBUG: utils.py:3595 - PrismaClient: insert_data: {'token': 'sk-short-secret', 'key_alias': 'redaction-repro', ...}

After (fixed, captured at 429ee1d2cb): the same flow with key sk-short-secret3 leaves zero occurrences of the raw key anywhere in the full debug log; both lines now show the SHA-256 hash, which is the same value the DB stores as token_id

$ curl -sS http://localhost:4356/key/generate -H "Authorization: Bearer sk-1234" \
    -H "Content-Type: application/json" -d '{"key":"sk-short-secret3","key_alias":"redaction-after"}'
{"key": "sk-short-secret3", "key_alias": "redaction-after", "token_id": "de8912021302e482b16ee193ab07cac5d2bf1ff7015144925be0b8357bb39e9b", ...}

$ grep -Fc 'sk-short-secret3' litellm.log
0

$ grep -Fn 'de8912021302e482b16ee193ab07cac5d2bf1ff7015144925be0b8357bb39e9b' litellm.log | grep -i 'insert_data\|Creating Key'
107:13:40:25 - LiteLLM Proxy:DEBUG: key_management_endpoints.py:3780 - prisma_client: Creating Key= {'token': 'de8912021302e482b16ee193ab07cac5d2bf1ff7015144925be0b8357bb39e9b', 'key_alias': 'redaction-after', ...}
108:13:40:25 - LiteLLM Proxy:DEBUG: utils.py:3595 - PrismaClient: insert_data: {'token': 'de8912021302e482b16ee193ab07cac5d2bf1ff7015144925be0b8357bb39e9b', 'key_alias': 'redaction-after', ...}

The generated key still works end to end against a real provider (costs real $)

$ curl -sS http://localhost:4356/v1/chat/completions \
    -H "Authorization: Bearer sk-short-secret3" -H "Content-Type: application/json" \
    -d '{"model":"claude-haiku-4-5","messages":[{"role":"user","content":"Say OK"}]}'
{"content": "OK", "id": "chatcmpl-1fcddedb-3b21-4c8b-bd8e-f30902b5e16c", ...}

Keys created via /user/new and auto-generated keys from /key/generate were also exercised on the fixed build; neither leaves a raw key in the log

Type

🐛 Bug Fix

Changes

When debug logging is enabled, the key insertion path logged the complete key data dict before the token was hashed, at two sites: generate_key_helper_fn ("prisma_client: Creating Key=") and PrismaClient.insert_data ("PrismaClient: insert_data:"). Every key creation entrypoint funnels through both (/key/generate, service account keys, /user/new), so any raw virtual key could land in retained or exported debug logs. The log-level SecretRedactionFilter only catches keys matching sk- followed by 20 or more characters, so short or nonstandard custom key values sailed through

Both log statements now replace the token value with its SHA-256 hash before the dict reaches the logger. The hash is exactly what the DB stores (token_id), so the log line keeps its diagnostic value for correlating with the LiteLLM_VerificationToken row, and it is not a usable credential since user_api_key_auth rejects bearer tokens that do not start with sk- precisely to prevent token hashes from being used. The redaction is structural (never pass the raw value to the logger) rather than pattern based, so it holds for any key format

Regression tests extend the existing mapped test files and were mutation checked: both fail on the unfixed code and pass with the fix. update_data, /key/update, and /key/regenerate were audited and already hash before logging; no other raw key sink exists in the insertion path

Follow-up commit 72ad739 hardens the redacting log guard to tolerate a None token value (Greptile finding; no current caller passes one) and pins that with a test

Behavior changes

Debug log output only: the token field in the two messages above now shows the hashed token instead of the raw key. No API response, return value, exception, or DB write changes. Callers inserting rows without a token field (user, team, config, spend) log exactly as before

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

Low Risk
Debug-log-only redaction with no API, DB, or auth behavior changes; reduces credential exposure in logs.

Overview
Fixes a secret leak in proxy debug logs when virtual keys are created: two debug lines (generate_key_helper_fn “Creating Key=” and PrismaClient.insert_data) previously logged the full key_data dict while token was still the raw key. Regex-based SecretRedactionFilter misses short or nonstandard custom keys, so those values could end up in retained --detailed_debug output.

Both log sites now structurally replace token with its SHA-256 hash (same as stored token_id) before the dict is passed to the logger. insert_data only redacts when token is present; None tokens still log without crashing.

Regression tests assert raw keys never appear in DEBUG output for /key/generate and PrismaClient.insert_data, including the None token case.

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

[greptile-apps]

Greptile Summary

This PR fixes two debug-log sites where a raw virtual key could appear in retained logs when --detailed_debug is enabled. Both generate_key_helper_fn and PrismaClient.insert_data now substitute the token field with its SHA-256 hash before the dict reaches the logger, matching the value already stored in the DB and not usable as a credential.

• key_management_endpoints.py: a new dict {**key_data, "token": hash_token(token=token)} is created solely for the log call; the original key_data passed to insert_data is unchanged.
• utils.py: the log dict is similarly shadowed, guarded with data.get("token") is not None so callers inserting user/team/config rows without a token field log exactly as before.
• Three focused regression tests cover the main flow, the None-token edge case, and an end-to-end generate_key_fn path.

Confidence Score: 5/5

Safe to merge. Only debug log output is changed; no API responses, DB writes, or authentication logic are affected.

Both changed log sites correctly shadow the raw token with its SHA-256 hash using a throwaway dict, leaving the original data dict untouched for subsequent DB operations. The guard in utils.py correctly handles absent or None tokens. Three new mock-only tests directly verify the raw key is absent from logs and the hash is present.

No files require special attention.

Important Files Changed

Filename	Overview
litellm/proxy/management_endpoints/key_management_endpoints.py	Adds hashed token substitution in the "Creating Key" debug log; token variable is always a non-None string at that point, so the hash_token call is safe.
litellm/proxy/utils.py	Guards the debug log with data.get("token") is not None before hashing; correctly passes data through unchanged for non-key table inserts and when token is absent/None.
tests/test_litellm/proxy/management_endpoints/test_key_management_endpoints.py	Adds regression test verifying raw key is absent from logs and SHA-256 hash is present; test uses mocks only, no real network calls.
tests/test_litellm/proxy/utils/prisma_and_spend/test_prisma_client_writes.py	Adds two tests for insert_data: one verifying token hashing in the debug log, one verifying None token does not crash the logger.

_{Reviews (2): Last reviewed commit: "fix(proxy): tolerate None token in inser..." | Re-trigger Greptile}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[yucheng-berri]

@greptileai

[codspeed-hq]

Merging this PR will not alter performance

✅ 31 untouched benchmarks

---

_{Comparing litellm_lit4356_key_debug_redaction (90e6ba5) with litellm_internal_staging (668df94)}

[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 72ad739. Configure here.}