Check for existing issues
What happened?
When testing the tool permission Guardrail, I found that the request metadata in the Request Logs is logging the request prompt in the guardrail_information[].guardrail_response.messages and guardrail_information[].guardrail_response.proxy_server_request.body field. This is happening at least with the Tool Permission Guardrail, I haven't tested others.
I expected this to respect the store_prompts_in_spend_logs configuration option and redact the prompt and tool call parameters.
I've also noticed while compiling this report that is it also logging the request bearer token in guardrail_information[].guardrail_response.secret_fields.raw_headers.authorization.
I'm using the latest stable so I've checked the newer non-stable version release notes and this doesn't seem to have been addressed by those versions.
Steps to Reproduce
- Make a test call with a Tool Permission Guardrail set:
curl -X POST 'https://{BASE_URL}/chat/completions' \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer {API_KEY}' \
-d '{
"model": "{MODEL}",
"messages": [
{
"role": "system",
"content": "You are an LLM helping me reproduce a bug."
},
{
"role": "user",
"content": "Output ONLY the word: I-AM-A-TEAPOT"
}
],
"guardrails": ["test-tool-block"]
}'
- Find the request in the Request Logs view in the Admin UI and search the Metadata for
I-AM-A-TEAPOT to easily find the locations of the request prompt (and probably response if a post_call guardrail was used?).
Relevant log output
...
"guardrail_response": {
"model": "removed",
"messages": [
{
"role": "system",
"content": "You are an LLM helping me reproduce a bug."
},
{
"role": "user",
"content": "Output ONLY the word: I-AM-A-TEAPOT"
}
],
...
"proxy_server_request": {
"url": "http://removed/chat/completions",
"body": {
"model": "removed",
"messages": [
{
"role": "system",
"content": "You are an LLM helping me reproduce a bug."
},
{
"role": "user",
"content": "Output ONLY the word: I-AM-A-TEAPOT"
}
],
"guardrails": [
"test-tool-block"
]
},
"method": "POST",
"headers": {
"via": "2.0 Caddy",
"host": "removed",
"accept": "*/*",
"user-agent": "curl/8.18.0",
"content-type": "application/json",
"content-length": "325",
"accept-encoding": "gzip",
"x-forwarded-for": "removed",
"x-forwarded-host": "removed",
"x-forwarded-proto": "https"
}
...
What part of LiteLLM is this about?
Proxy
What LiteLLM version are you on ?
v1.81.0-stable
Twitter / LinkedIn details
No response
Check for existing issues
What happened?
When testing the tool permission Guardrail, I found that the request metadata in the Request Logs is logging the request prompt in the
guardrail_information[].guardrail_response.messagesandguardrail_information[].guardrail_response.proxy_server_request.bodyfield. This is happening at least with the Tool Permission Guardrail, I haven't tested others.I expected this to respect the
store_prompts_in_spend_logsconfiguration option and redact the prompt and tool call parameters.I've also noticed while compiling this report that is it also logging the request bearer token in
guardrail_information[].guardrail_response.secret_fields.raw_headers.authorization.I'm using the latest stable so I've checked the newer non-stable version release notes and this doesn't seem to have been addressed by those versions.
Steps to Reproduce
I-AM-A-TEAPOTto easily find the locations of the request prompt (and probably response if a post_call guardrail was used?).Relevant log output
What part of LiteLLM is this about?
Proxy
What LiteLLM version are you on ?
v1.81.0-stable
Twitter / LinkedIn details
No response