litellm - ✅(Solved) Fix [Bug]: disable_global_guardrails per key/team has no effect (singular/plural key mismatch) [1 pull requests, 1 comments, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
BerriAI/litellm#25487Fetched 2026-04-11 06:13:57
View on GitHub
Comments
1
Participants
1
Timeline
4
Reactions
0
Author
Participants
Timeline (top)
commented ×1cross-referenced ×1labeled ×1subscribed ×1

Error Message

No error — the feature silently does nothing.

Fix Action

Fixed

PR fix notes

PR #25488: fix(guardrails): use plural key in get_disable_global_guardrail

Description (problem / solution / changelog)

Rename disable_global_guardrail → disable_global_guardrails to match the key name used by litellm_pre_call_utils.py, the API endpoints, and the UI when propagating key/team metadata.

The singular form was introduced in PR #16983 and has never matched the plural form written by the rest of the codebase, so the feature silently did nothing.

Relevant issues

Fixes #25487

Pre-Submission checklist

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

  • I have Added testing in the tests/test_litellm/ directory, Adding at least 1 test is a hard requirement - see details
  • 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
  • I have requested a Greptile review by commenting @greptileai and received a Confidence Score of at least 4/5 before requesting a maintainer review

Delays in PR merge?

If you're seeing a delay in your PR being merged, ping the LiteLLM Team on Slack (#pr-review).

CI (LiteLLM team)

CI status guideline:

  • 50-55 passing tests: main is stable with minor issues.
  • 45-49 passing tests: acceptable but needs attention
  • <= 40 passing tests: unstable; be careful with your merges and assess the risk.
  • Branch creation CI run
    Link:

  • CI run for the last commit
    Link:

  • Merge / cherry-pick CI run
    Links:

Type

🐛 Bug Fix

Changes

get_disable_global_guardrail() in custom_guardrail.py checks for the key disable_global_guardrail (singular), but every producer — litellm_pre_call_utils.py (key and team metadata propagation), the API endpoints, and the UI — writes disable_global_guardrails (plural). The keys never match, so setting disable_global_guardrails: true on an API key or team has no effect.

The mismatch was introduced in PR #16983 (2025-11-22) across two commits 10 minutes apart — the method used singular, the propagation used plural.

Fix: Rename disable_global_guardrail → disable_global_guardrails in the consumer method and update corresponding tests.

Files changed:

  • litellm/integrations/custom_guardrail.py — 4 lines: singular → plural in get_disable_global_guardrail()
  • tests/test_litellm/integrations/test_custom_guardrail.py — 4 lines: update test data to use plural key
  • tests/test_litellm/proxy/guardrails/guardrail_hooks/test_panw_prisma_airs.py — 1 line: update test param to use plural key

Changed files

  • litellm/integrations/custom_guardrail.py (modified, +4/-4)
  • tests/test_litellm/integrations/test_custom_guardrail.py (modified, +4/-4)
  • tests/test_litellm/proxy/guardrails/guardrail_hooks/test_panw_prisma_airs.py (modified, +1/-1)

Code Example

curl -X POST 'http://0.0.0.0:4000/key/generate' \
  -H 'Authorization: Bearer sk-master' \
  -H 'Content-Type: application/json' \
  -d '{"metadata": {"disable_global_guardrails": true}}'
RAW_BUFFERClick to expand / collapse

What happened?

Setting disable_global_guardrails: true on an API key or team metadata has no effect — default_on: true guardrails still run unconditionally.

get_disable_global_guardrail() in custom_guardrail.py checks for the key disable_global_guardrail (singular), but every producer — litellm_pre_call_utils.py (key and team metadata propagation), the management API endpoints, and the UI — writes disable_global_guardrails (plural). The keys never match, so the method always returns False.

The mismatch was introduced in PR #16983 (2025-11-22) across two commits 10 minutes apart. The plural form is used consistently everywhere else; the singular form only exists in get_disable_global_guardrail() and its unit test.

Steps to Reproduce

  1. Create a key with global guardrails disabled:
curl -X POST 'http://0.0.0.0:4000/key/generate' \
  -H 'Authorization: Bearer sk-master' \
  -H 'Content-Type: application/json' \
  -d '{"metadata": {"disable_global_guardrails": true}}'
  1. Make a request with that key to a route with a default_on: true guardrail
  2. Observe the guardrail still runs — the disable_global_guardrails flag is silently ignored

Relevant log output

No error — the feature silently does nothing.

What part of LiteLLM is this about?

Proxy

What LiteLLM version are you on ?

v1.82.3 (bug present since v1.55.1, PR #16983)

Twitter / LinkedIn details

No response

extent analysis

TL;DR

Update the get_disable_global_guardrail() function in custom_guardrail.py to check for the correct key disable_global_guardrails (plural) to fix the issue.

Guidance

  • Identify and update the get_disable_global_guardrail() function to use the correct key disable_global_guardrails (plural) to match the rest of the codebase.
  • Verify the fix by recreating the scenario described in the "Steps to Reproduce" section and checking that the guardrail is correctly disabled.
  • Review the code history to ensure that the singular form disable_global_guardrail is not used elsewhere, to prevent similar issues in the future.
  • Consider adding tests to ensure that the get_disable_global_guardrail() function behaves correctly with both the plural and singular forms of the key.

Example

# custom_guardrail.py
def get_disable_global_guardrail():
    # Update the key to match the rest of the codebase
    return metadata.get('disable_global_guardrails', False)

Notes

The issue is specific to the custom_guardrail.py file and the get_disable_global_guardrail() function. The fix should be applied to this function to resolve the issue.

Recommendation

Apply the workaround by updating the get_disable_global_guardrail() function to use the correct key disable_global_guardrails (plural), as this is a targeted fix that addresses the root cause of the issue.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

litellm - ✅(Solved) Fix [Bug]: disable_global_guardrails per key/team has no effect (singular/plural key mismatch) [1 pull requests, 1 comments, 1 participants]