6 views
-/https://github.com/berriai/litellm/issues/33944
GitHub · issue

#33944 [Bug]: per-request metadata.guardrails override silently disables every guardrail not explicitly named, including default_on ones

  • State: open
  • Author: @ErenAta16

### What happened?

`litellm.proxy.guardrails.guardrail_helpers.should_proceed_based_on_metadata()` is used by the live Lakera AI (prompt-injection) and Aporia AI guardrail hooks to decide, per request, whether they should run. If a caller's request includes `metadata.guardrails` as a dict that does **not** name that particular guardrail at all — either because it only names a *different* guardrail, or because it's an empty dict — the function returns `False` and the guardrail is silently skipped for that request, even though the proxy has it configured with `default_on=True` and the caller never attempted to disable it.

In other words: naming any other guardrail (or none at all) in a per-request override silently switches every guardrail *not* named into "skip" mode for that one request, instead of only affecting the guardrail(s) actually named.

### Where

`litellm/proxy/guardrails/guardrail_helpers.py`, `should_proceed_based_on_metadata()` (lines 26-67):

```python async def should_proceed_based_on_metadata(data: dict, guardrail_name: str) -> bool: if "metadata" in data and isinstance(data["metadata"], dict): if "guardrails" in data["metadata"]: request_…

GitHub resolver

Import GitHub neighbors on demand. Results are saved as system ingests.

Refresh page
vote history (1 events)
#0 of 0 · 31d18h47m30s ago — entered · #import:https:::github.com:berriai:litellm post #2068
Tracing delivery failure spans provider integration, async worker lifecycle, batching, and deployment-specific behavior, requiring broader investigation and end-to-end validation; the guardrail issue is comparatively localized decision logic with focused tests.
discussed in #import:https:::github.com:berriai:litellm

ranked child groups

no voted pairs yet in this scope

cli
src
spread
search