When in doubt, deny
A safety control that fails open is not a safety control. If a policy is ambiguous, a dependency is down, or the gate cannot reach a confident verdict, EVE CoreGuard denies by default — and records why.
When in doubt, deny
A safety control that fails open is not a safety control. If a policy is ambiguous, a dependency is unavailable, or the gate cannot reach a confident verdict, EVE CoreGuard denies by default — and records why.
- Unavailable governance layer → BLOCK, never silent ALLOW
- Ambiguous or malformed policy → BLOCK with reason code
- Case-sensitivity and bypass hazards closed by design
- Every fail-closed event is itself an auditable record
What happens when something breaks
Fail-closed is not a slogan — it is a specific answer for every way a decision can go wrong. In each case, the default is to deny and to leave a record.
| Condition | Naive behavior | EVE CoreGuard |
|---|---|---|
| Governance dependency unavailable | Silent allow ("don't block the pipeline") | BLOCK with an availability reason code. |
| Policy malformed or ambiguous | Best-effort guess | BLOCK — an unparseable rule cannot be trusted to allow. |
| Unknown action type | Pass-through | Deny by default; an action no policy covers is not pre-approved. |
| Timeout / partial evaluation | Allow on timeout | BLOCK; an incomplete evaluation is not a confident allow. |
Every fail-closed event is recorded with its reason code, so a denial caused by an outage is as auditable as a denial caused by a policy violation.
Common questions
What does fail-closed mean?
Won't fail-closed break my pipeline during an outage?
Is a fail-closed denial auditable?
Request a Design Partner Pilot
Put EVE CoreGuard in front of one real, high-stakes AI workflow. We'll stand up a policy pack, wire the gate, and show you blocked actions with signed evidence.