What happened?

Azure Content Safety guardrails (azure-prompt-shield and azure-text-moderation) silently skip when requests come through the /v1/responses (OpenAI Responses API) endpoint. The guardrails check data.get("messages") but the Responses API uses input instead, so the handlers exit early with a warning log.

This means content moderation and prompt injection detection are completely bypassed for any traffic using the Responses API, despite PR #15686 adding framework-level guardrail support for this endpoint.

Relevant log output

{"message": "Azure Prompt Shield: not running guardrail. No messages in data", "level": "WARNING"}
{"message": "Azure Text Moderation: not running guardrail. No messages in data", "level": "WARNING"}

How to reproduce

1. Configure Azure guardrails in litellm_config.yaml:

guardrails:
  - guardrail_name: azure-prompt-shield
    litellm_params:
      guardrail: azure/prompt_shield
      mode: pre_call
      api_key: os.environ/AZURE_GUARDRAIL_API_KEY
      api_base: os.environ/AZURE_GUARDRAIL_API_BASE

  - guardrail_name: azure-text-moderation
    litellm_params:
      guardrail: azure/text_moderations
      mode: pre_call
      api_key: os.environ/AZURE_GUARDRAIL_API_KEY
      api_base: os.environ/AZURE_GUARDRAIL_API_BASE

1. Send a request to /v1/responses:

curl -X POST http://localhost:4000/v1/responses \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-4.1-mini",
    "input": [{"role": "user", "content": "Some harmful content here"}],
    "guardrails": ["azure-prompt-shield", "azure-text-moderation"]
  }'

1. Observe proxy logs: both guardrails log the warning and exit without scanning.

2. Send the same content via /v1/chat/completions:

curl -X POST http://localhost:4000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-4.1-mini",
    "messages": [{"role": "user", "content": "Some harmful content here"}],
    "guardrails": ["azure-prompt-shield", "azure-text-moderation"]
  }'

1. Guardrails run correctly via /v1/chat/completions.

Root cause

Both Azure guardrail handlers only look for messages in the request data. When the request comes through /v1/responses, the user content is in the input field instead.

prompt_shield.py — async_pre_call_hook (line ~133):

new_messages: Optional[List[AllMessageValues]] = data.get("messages")
if new_messages is None:
    verbose_proxy_logger.warning(
        "Azure Prompt Shield: not running guardrail. No messages in data"
    )
    return data

text_moderation.py — async_pre_call_hook (line ~228):

new_messages: Optional[List[AllMessageValues]] = data.get("messages")
if new_messages is None:
    verbose_proxy_logger.warning(
        "Azure Text Moderation: not running guardrail. No messages in data"
    )
    return data

Both are in:

• litellm/proxy/guardrails/guardrail_hooks/azure/prompt_shield.py
• litellm/proxy/guardrails/guardrail_hooks/azure/text_moderation.py

Suggested fix

The async_pre_call_hook in both handlers should fall back to data.get("input") when messages is not present. PR #15686 added get_guardrails_messages_for_call_type() at the framework level — the Azure handlers should use it (or at minimum check input as a fallback):

new_messages = data.get("messages") or data.get("input")
if new_messages is None:
    ...

A more robust approach would be to use the call_type parameter (already passed to async_pre_call_hook) to determine which field to read from, consistent with how PR #15686 handles guardrail message extraction.

The same pattern likely affects async_post_call_success_hook in text_moderation.py which reads response.choices[0].message.content — for Responses API the output structure is different.

LiteLLM version

v1.82.6-nightly (also confirmed on v1.82.3-stable)

Related

• #14152 — Original bug: Responses API does not support guardrails
• #15686 — PR that added framework-level guardrail support for /v1/responses and /v1/messages
• #12268 — PR that added Azure Content Safety guardrails

Are you a LiteLLM customer?

No

Twitter / LinkedIn details

N/A