Guardrail API V2 - user api key metadata, session id, specify input type (request/response), image support

[ghost]

Title

Guardrail API V2 - user api key metadata, session id, specify input type (request/response), image support

curl -X POST https://your-guardrail-api.com/beta/litellm_basic_guardrail_api \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -d '{
    "texts": [
      "Hello, can you help me with this task?"
    ],
    "images": null,
    "request_data": {
      "user_api_key_hash": "88dc28d0f030c55ed4ab77ed8faf098196cb1c05df778539800c9f1243fe6b4b",
      "user_api_key_alias": "production-key",
      "user_api_key_user_id": "user_12345",
      "user_api_key_user_email": "user@example.com",
      "user_api_key_team_id": "team_67890",
      "user_api_key_team_alias": "engineering-team",
      "user_api_key_end_user_id": "end_user_abc",
      "user_api_key_org_id": "org_xyz"
    },
    "input_type": "request",
    "litellm_call_id": "chatcmpl-123456789",
    "litellm_trace_id": "trace-abc-def-ghi",
    "additional_provider_specific_params": {
      "threshold": 0.8,
      "language": "en"
    }
  }'

Example Response (NONE):

{
  "action": "NONE"
}

Relevant issues

Make Guardrail API more useful for integration providers

Pre-Submission checklist

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

• I have Added testing in the tests/litellm/ directory, Adding at least 1 test is a hard requirement - see details
• I have added a screenshot of my new test passing locally
• 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

Type

🆕 New Feature

Changes

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
litellm	Ready	Preview	Comment	Dec 2, 2025 4:13am

To address the issue, only non-sensitive fields should be included in logging. This can be achieved by constructing a filtered dictionary excluding sensitive keys from the log output. Sensitive fields commonly include "user_api_key_hash", "user_api_key_token", "user_api_key" and any other fields related to authentication secrets, including all values in the "GenericGuardrailAPIMetadata" that could be used for authentication or authorization.

Key changes:

• In the log statement (line 140), instead of logging all key-values, construct a dictionary excluding sensitive keys such as "user_api_key_hash", "user_api_key_token" and similar.
• Ideally, define a list of sensitive keys, and filter them out from the logged dictionary.
• Only modify the specific lines responsible for logging (lines 138–141).
• No outside dependencies are needed; standard Python is sufficient.
• You may need to add a helper in the function to perform the filtering.

---

The best way to fix this is to avoid logging the specific values of the flags associated with user API key handling (send_user_api_key_alias, send_user_api_key_user_id, and send_user_api_key_team_id). Instead, you can log that these flags are set (e.g., "Configured", "Not configured") without disclosing exact values, or simply avoid logging them altogether. The code to change is within the constructor (__init__) of ZscalerAIGuard, specifically the call to verbose_proxy_logger.debug on line 52-56.
Recommended fix: Replace the f-string logging statement with a generic message such as "User API key flags configured" or remove it altogether.
No additional imports or definitions are required; just change or remove the problematic debug log in the constructor.

The best way to fix the problem is to ensure that when logging extra_headers, any header values that are sensitive (such as Authorization or any headers that may contain user API keys) are masked or excluded before logging. We will create a sanitized/shallow-copied version of extra_headers for logging purposes.
Steps:

• In _prepare_headers, before logging extra_headers, create a copy of the dict where the values for sensitive keys (like "Authorization") are replaced with a safe placeholder, e.g., "****".
• Only log this sanitized dict instead of the full one.
• This involves adding a small helper/snippet directly before the log line in _prepare_headers.
• No external imports are required, only built-in features.