litellm-guardrails-safety

LiteLLM Guardrails Safety

Workflow

1. Create a threat model and classify input, output, tool, MCP, data exfiltration, and privilege escalation risks.
2. Verify the LiteLLM version, guardrail provider, mode, authorization, and failure semantics.
3. Choose pre_call、post_call、pre_mcp_call and other correct execution points.
4. Set protections that must be enforced to default-on; tool permissions adopt default-deny and a minimal allowlist.
5. Restrict both tool names and parameters, avoiding allowing only the name while leaving high-risk arguments unchecked.
6. Clearly define the fail-open or fail-closed behavior for provider errors and guardrail errors.
7. Test allow, deny, mask, rewrite, provider error, and guardrail error.

When tool permission config, PII config, and test specifications are needed, read Experiments and References。

Security Baseline

• High-risk security controls adopt fail-closed unless the threat model clearly proves that degradation is acceptable.
• Do not use guardrails to replace keys, teams, model access, sandboxing, or audit logs.
• Allow rules must not use unrestricted .*。
• Custom hooks must not log secrets, full sensitive prompts, or unmasked personal data.

Acceptance

• The threat model and each rule are traceable.
• Unmatched tools are denied by default.
• Parameter restrictions have valid and violating fixtures.
• Guardrail failure behavior is reproducible, and high-risk paths are not silently allowed.