Fail-closed
An architectural decision: if the security control becomes unavailable, the request is stopped rather than passed through uninspected. The default protects the data, not the convenience.
Why it matters
Fail-closed is the decision to, in the face of a failure in the security control, stop the request rather than let it through. It matters because every control faces the same question at the worst moment — what happens when the check can't run? — and there are only two opposite answers. Failing open is letting the call proceed when the detector is down; failing closed is blocking it when verification isn't possible. The choice defines whether the control truly protects or only protects when convenient.
The treacherous detail is that failing open looks harmless, because the failure is rare and silent. But it's precisely at the instant of failure that sensitive data slips out unseen. A control that fails open offers protection only while everything works — meaning it stops protecting exactly when it would be needed. In practice it isn't protection, it's a false sense of it.
How it works
The failure behavior has to follow the policy's intent. If the organization declared that a given piece of data may not leave without a check, that rule must hold even when verification is unavailable. In a fail-closed architecture, the detector being unavailable results in a block: the call is refused, not let through. The worst possible outcome becomes a stopped request that can be retried — instead of a silent, irreversible leak.
Technically, this usually translates into short timeouts and explicit responses: if the inspection layer doesn't answer in time, the default path is to deny. The default is the part that matters most, because it's what holds when something goes wrong and no one is watching. Fail-closed makes protecting the data the default, and convenience the exception that has to be consciously chosen.
How Horse Labs handles it
At Horse Labs, the DLP guardrail is fail-closed: with the PII tier set to Block and Presidio unreachable, the call is blocked, not let through. Sensitive data doesn't leave without a check even during a failure. The choice is deliberate — the worst case is a refused request that can be retried, never data that leaked and won't come back.
Nuance
Fail-closed isn't the right answer for everything, and it's important to say so. In systems where availability is the most critical asset, failing closed can be worse than the risk it avoids. The decision is always about what's being protected: when the asset is sensitive data that can't escape, fail-closed is the correct posture, because a leak is irreversible and a stopped call isn't. The mistake is adopting the default without deciding — inheriting fail-open out of inertia and finding out, too late, that the control gave way at the first pressure.