Third-party safety rails FAIL OPEN on backend error (safety vendor down = guardrail allows everything)

Summary

Several rails that call an external safety service map every backend failure mode — HTTP status != 200, a missing key in the JSON response, aiohttp.ClientError, asyncio.TimeoutError, or any Exception — to a not-blocked verdict. Because a flow blocks only when the action returns "unsafe", an outage / timeout / transient error on the safety backend causes the rail to allow all traffic. A guardrail that fails open under load or partial outage provides false assurance precisely when it is most needed.

Instances (all deterministic, execution-proven)

Each simulated via the real failure path (HTTP 500 / dropped connection / timeout), confirming the action returns the not-blocked value while the rail is otherwise live.

Expected vs actual

• Expected: a safety-rail backend error should fail CLOSED — block the request, or raise so the app can decide — not silently allow.
• Actual: the error is swallowed to "safe", and the (potentially harmful) content passes.

Proposed direction

Make the error path configurable with a fail-closed default for safety rails (block on backend error, or raise a clear exception), and distinguish "the backend said allow" from "the backend errored". Happy to send focused PRs per rail.

Related

injection_detection omit-mode also fails open on a UTF-8 decode error of a YARA match (actions.py:214-226), and the sensitive_data_detection PII rail leaks real SSNs via the inherited Presidio recognizer (fixed at the root by a separate Presidio PR).

Start with the listed failure paths in library/jailbreak_detection/actions.py and request.py, library/crowdstrike_aidr/actions.py, and library/fiddler/actions.py. Trace how backend errors become allow verdicts, then verify that backend errors are distinguishable from explicit allows and that the default safety-rail behavior is fail-closed across the affected rails.