Glossary

Fail-closed

When a control can't confirm an action is safe, it denies rather than allows.

category ▸ Governance

audit/verify
#101hash ✓#102hash ✓#103hash ✓#104hash ✓#105hash ✓
head 0x9f3a…c1ok: true
verifyChain ▸ chained SHA-256 · signed receipts
What it means

Fail-closed, in plain language.

A fail-closed control defaults to denial. If the system cannot positively establish that an action is authorized — a missing permission, an expired identity, an unreachable check — it refuses the action rather than letting it through. The opposite, fail-open, defaults to allowing the action when a check is uncertain or unavailable.

For security-critical decisions, fail-closed is the safe default: the cost of wrongly blocking a legitimate action is an annoyance; the cost of wrongly allowing a dangerous one can be a breach. The discipline of being explicit about which controls fail closed and which fail open is itself a sign of a mature governance design.

In Cortex

How Cortex implements it.

This term isn't abstract here — it maps to a real capability in the runtime. Here is exactly how Cortex enforces or relates to it.

Governance

Cortex's access and authorization controls fail closed: an expired agent identity cannot mint a token (403 IDENTITY_EXPIRED), an off-allow-list model is rejected (403 MODEL_NOT_ALLOWED), a restricted ontology field read is denied (403), and a high-injection tool input is blocked at the MCP Gateway.

Where blocking would harm availability rather than safety, Cortex is deliberately fail-open and says so: if reliability scoring is unavailable it does not block publish, and an unreachable ontology check during an action logs and proceeds. The choice is explicit, not accidental.

See Fail-closed enforced, not just defined.

Book a walkthrough and watch the controls in this glossary return real verdicts, seal real evidence, and trace every fact back to its source.