BerriAI/litellm · error · GuardrailRaisedException
Sensitive data detected by {self.guardrail_name}
Error message
Sensitive data detected by {self.guardrail_name} What it means
This GuardrailRaisedException is the guardrail doing its job in block mode: sensitive data matched a detection rule, the guardrail is not configured to reroute (should_route_on_sensitive_data() is false), so the call is aborted with 'Sensitive data detected by <guardrail_name>'. The exception propagates out of the guardrail hook and the request never reaches the provider unless caught or excluded.
Source
Thrown at litellm/integrations/custom_guardrail.py:431
GuardrailRaisedException: When configured to block, or when routing is
configured but no session_id is available
"""
if self.should_route_on_sensitive_data():
try:
self.raise_sensitive_data_route_exception(
route_to_model=self.sensitive_data_route_to_model,
request_data=request_data,
detection_info=detection_info,
)
except ValueError:
raise GuardrailRaisedException(
message=(
f"Sensitive data detected by {self.guardrail_name} (routing skipped: request has no session_id)"
),
guardrail_name=self.guardrail_name,
)
else:
raise GuardrailRaisedException(
message=f"Sensitive data detected by {self.guardrail_name}",
guardrail_name=self.guardrail_name,
)
@staticmethod
def get_config_model() -> type["GuardrailConfigModel"] | None:
"""
Returns the config model for the guardrail
This is used to render the config model in the UI.
"""
return None
@classmethod
def get_supported_event_hooks(cls) -> list[GuardrailEventHooks] | None:
"""
Returns the event hooks this guardrail supports, for the UI to render.
View on GitHub (pinned to 6c2dcb801b)
Solutions
- Remove or redact the sensitive content from the prompt before sending it
- If masking is preferred over blocking, enable mask mode (e.g. pii_replace_with / sensitive_data_route_to_model or guardrail-specific mask config) so text is transformed instead of rejected
- Scope the guardrail: disable it for specific keys/teams, exclude entity types, or tighten the detection rules that produced the false positive
Example fix
# before
messages = [{"role": "user", "content": "Email john.doe@corp.com about the invoice"}]
# after (pre-redact, or use a masking guardrail config)
messages = [{"role": "user", "content": "Email <EMAIL> about the invoice"}] Defensive patterns
Strategy: try-catch
Try / catch
from litellm.integrations.custom_guardrail import GuardrailRaisedException
try:
result = litellm.completion(model="gpt-4o", messages=msgs)
except GuardrailRaisedException as e:
# policy decision: inform user, log, or sanitize + retry
return sanitize_and_retry(msgs, e) Prevention
- Redact PII client-side before sending when block-mode guardrails are active
- Prefer mask-mode over block-mode for user-facing apps to avoid hard failures
- Log guardrail_name from the exception to identify which rule fired and tune it
When it happens
Trigger: A guardrail without sensitive_data_route_to_model (mask/route not enabled) runs on a request whose prompt or messages contain a matched entity (e.g. Presidio PII, bedrock guardrail, regex custom guardrail) and detection returns true. Happens on pre_call/during_call hooks depending on the guardrail's event_hook config.
Common situations: PII blocking enabled company-wide and users pasting SSNs/emails/credit-card numbers; custom guardrails whose detect() is too broad (blocking benign inputs); testing guardrail configs with the same prompt used to test detection.
Related errors
- Sensitive data detected by {self.guardrail_name} (routing sk
- Cannot route sensitive data without a session_id. Ensure the
- Event hook {hook} is not in the supported event hooks {suppo
- Event hook {event_hook} is not in the supported event hooks
- Guardrail {self.guardrail_name or type(self).__name__} imple
AI-assisted analysis of BerriAI/litellm@6c2dcb801b (2026-08-15).
Data as JSON: /api/errors/566a33f675460387.
Report an issue: GitHub.