Skip to content

Error handling

Guardrail execution errors

Two modes apply when a guardrail throws or fails at runtime (bad config, missing dependency, invalid model name, network error inside the check, etc.). This is separate from policy hits (content that triggers a guardrail’s rule).

Fail-safe (default)

With raise_guardrail_errors=False (the default), a failed guardrail does not stop the pipeline. You get a normal GuardrailResult with:

  • execution_failed=True
  • enforcement_triggered=False (an execution error is not treated as a safety violation)
  • original_exception and an error field in info when useful

The request can continue; inspect results for execution_failed if you need to react in application code.

# Default: raise_guardrail_errors=False
client = MendGuardrailsAsyncOpenAI(config="config.json")
# Continues even when a guardrail fails to execute; check results[].execution_failed

The same flag exists on MendGuardrailsClient, MendGuardrailsSyncClient, LangChain middleware, and other entry points that forward it into run_guardrails.

Fail-secure (strict)

With raise_guardrail_errors=True, the first guardrail execution failure is re-raised so you can fail closed.

# Strict: raise_guardrail_errors=True
client = MendGuardrailsAsyncOpenAI(
    config="config.json",
    raise_guardrail_errors=True,
)
# Raises if a guardrail fails to execute (after results are collected)

Note: This only affects guardrail execution errors. Safety violations (content that triggers enforcement) are controlled by suppress_enforcement and related policy settings — see Enforcement.