litellm/tests/test_litellm/proxy/guardrails
Hi120ki c9757cd0d7 fix(guardrails): populate applied_guardrails when Model Armor blocks content (#20034)
Previously, when Model Armor guardrail blocked a request/response,
the `applied_guardrails` field was not populated in the logs because
`add_guardrail_to_applied_guardrails_header()` was called after the
HTTPException was raised.

This fix moves the `add_guardrail_to_applied_guardrails_header()` call
to before the blocking check in all hooks:
- async_pre_call_hook (pre_call mode)
- async_moderation_hook (during_call mode)
- async_post_call_success_hook (post_call mode)
- async_post_call_streaming_iterator_hook (streaming)

This ensures that even when a guardrail blocks content, the guardrail
name is properly recorded in the logs for observability.

Added regression tests to verify applied_guardrails is populated when
content is blocked.

Co-authored-by: Cursor <cursoragent@cursor.com>
2026-02-02 18:21:44 +05:30
..
guardrail_hooks fix(guardrails): populate applied_guardrails when Model Armor blocks content (#20034) 2026-02-02 18:21:44 +05:30
test_guardrail_endpoints.py [Fix] CI/CD #1 - mypy | check_code_and_doc_quality | guardrails_testing (#18195) 2025-12-18 06:31:01 -08:00
test_guardrail_registry.py added test for updating in memory guardrails 2025-09-17 17:16:49 -07:00
test_init_guardrails.py Litellm fix GitHub action testing (#11163) 2025-05-26 14:41:42 -07:00
test_pillar_guardrails.py Revert "Stabilise mock tests" 2026-01-17 06:26:18 +09:00
test_prompt_security_guardrails.py fixing prompt-security's guardrail implementation (#19374) 2026-01-21 20:09:40 -08:00