What causes "Violated Lasso guardrail policy" in BerriAI/litellm?

Inspect the HTTP 400 detail: detection_message lists the blocking findings and lasso_response holds the full Lasso payload — fix the specific policy/deputy it names.

BerriAI/litellm · error · HTTPException

Violated Lasso guardrail policy

Error message

Violated Lasso guardrail policy

What it means

An HTTPException(400) raised by the Lasso guardrail when the Lasso response has violations_detected=true and at least one finding carries action BLOCK. This is the guardrail enforcing policy, not a malfunction: the request or response is rejected, and the detail payload includes a detection_message naming the blocking findings plus the raw lasso_response.

Source

Thrown at litellm/proxy/guardrails/guardrail_hooks/lasso/lasso.py:856

                }
            }

        Args:
            response: The response dictionary from Lasso API

        Raises:
            HTTPException: If any finding has "action": "BLOCK"
        """
        if response and response.get("violations_detected") is True:
            violated_deputies: Final = self._parse_violated_deputies(response)
            verbose_proxy_logger.warning("Lasso guardrail detected violations: %s", violated_deputies)

            # Check if any findings have "BLOCK" action
            blocking_violations: Final = self._check_for_blocking_actions(response)

            if blocking_violations:
                # Block the request/response for findings with "BLOCK" action
                raise HTTPException(
                    status_code=400,
                    detail={
                        "error": "Violated Lasso guardrail policy",
                        "detection_message": f"Blocking violations detected: {', '.join(blocking_violations)}",
                        "lasso_response": response,
                    },
                )
            else:
                # Continue with warning for non-blocking violations (e.g., AUTO_MASKING)
                verbose_proxy_logger.info(
                    "Non-blocking Lasso violations detected, continuing with warning: %s", violated_deputies
                )

    def _check_for_blocking_actions(self, response: LassoResponse) -> list[str]:
        """
        Check findings for actions that should block the request/response.

        Examines the findings section of the Lasso response to identify which

View on GitHub (pinned to 77b7c6c40c)

Solutions

Inspect the HTTP 400 detail: detection_message lists the blocking findings and lasso_response holds the full Lasso payload — fix the specific policy/deputy it names.
If the content class should be softened, change the offending deputy's action in the Lasso policy from BLOCK to AUTO_MASKING/MASK so the guardrail logs and continues instead of blocking.
If the block is correct, handle it client-side: surface a friendly policy-violation message to the user instead of retrying (a retry will block again).
Sanitize the offending input (redact PII, remove flagged phrases) before resubmitting.

Defensive patterns

Strategy: try-catch

Try / catch

# Server/client side: recognize a deliberate Lasso block and stop retrying
from fastapi import HTTPException

try:
    resp = await client.chat.completions.create(**params)
except HTTPException as e:
    detail = e.detail if isinstance(e.detail, dict) else {"error": str(e.detail)}
    if e.status_code == 400 and detail.get("error") == "Violated Lasso guardrail policy":
        findings = detail.get("detection_message", "")
        raise PolicyRejectedError(
            user_message="Your request was blocked by the content policy.",
            findings=findings,  # for internal audit only — never expose lasso_response to users
        ) from e
    raise

Prevention

Tune Lasso deputies so soft violations use MASK/AUTO_MASKING and only high-confidence classes BLOCK.
Replay representative traffic through a staging Lasso policy before tightening BLOCK rules in production.
Never forward the raw lasso_response detail to end users — log it internally for audits.
Map this 400 to a first-class 'policy rejected' error in your API contract so clients do not auto-retry.

When it happens

Trigger: A pre_call or post_call hook sends content to Lasso; the response sets violations_detected=true; _parse_violated_deputies extracts findings and _check_for_blocking_actions finds at least one 'action': 'BLOCK', so litellm raises HTTPException 400 to the caller.

Common situations: End users sending content that Lasso deputies (PII, prompt-injection, toxicity policies) are configured to block; a newly tightened Lasso policy suddenly blocking previously-allowed traffic; testing pipelines that replay real user prompts against a blocking policy.

Related errors

AI-assisted analysis of BerriAI/litellm@77b7c6c40c (2026-08-18). Data as JSON: /api/errors/50ca4cdd6eacf2e0. Report an issue: GitHub.