Fail-Open
What you'll learn
- The default Craik posture: fail-closed.
- When fail-open is allowed, and what's still enforced when it is.
- How to preview a fail-open policy envelope and inspect the matching receipt.
- The boundaries fail-open never crosses.
Default posture: fail-closed
When Craik can't enforce a guarantee — missing credential, unreachable provider, ambiguous policy — it stops. The runtime never widens its permissions to keep a run going. Fail-open is a narrow, named exception that operators opt into deliberately.
Why fail-closed is the default
Agent runtimes that quietly continue when guarantees aren't met end up producing receipts, handoffs, and writes that look identical to a clean run. That's the worst possible failure mode: you can't tell from the artifacts whether the system was actually governed.
Craik picks the other side. If the credential profile is unreachable, the run halts with a structured error and a receipt that names what was missing. The next operator inherits clear state instead of an invisible degradation.
Fail-open is profile-gated
In v0.1.0, the only fail-open profile is trusted-local. It exists
for tightly-scoped local development where the operator is the only actor
and the run can't reach external resources. It must be requested explicitly
on every run that uses it — Craik never selects it automatically.
craik policy show --profile trusted-local --trusted-local-fail-open
This prints the resolved policy envelope without applying it. Use it as the first step in any conversation about whether to grant fail-open access for a specific task.
The mandatory receipt preview
Fail-open paths always produce a receipt. Always. Preview the receipt shape alongside the envelope before you authorize a run:
craik policy show \
--profile trusted-local \
--trusted-local-fail-open \
--include-receipt
The receipt records that the run took a fail-open path, names the
operator and credential identity, and is queryable later by both
--task-id and --policy-id. There is no silent fail-open.
What fail-open does not bypass
Even under trusted-local, the runtime still enforces:
Redaction
Receipts continue to pass through the central redaction guard. Secrets never leak into the receipt store, fail-open or otherwise.
Receipts
Every receiptable action still produces a receipt. The fail_open flag is set to true so the path is auditable after the fact.
Immutable paths
Edits to ADR directories and other immutable evidence remain forbidden. Fail-open is about availability, not about widening write authority.
Direct memory write approvals
Direct writes to Stigmem or any memory backend still require the explicit approval flow. Fail-open does not promote memory proposals to facts.
Automation mode is always fail-closed
When Craik is invoked under automation (CI, scheduled gateway runs, webhook ingress), it operates in a strict fail-closed posture. Automation runs must stop on uncertainty rather than widen permissions — there is no operator at the keyboard to authorize a fail-open path.
If your automation workflow is hitting fail-closed exits frequently, that's signal: either the credential profile is unstable, the policy is too tight, or the workflow needs a human review step before it touches the affected capability. Fail-open is not the fix.
A pragmatic checklist
Before authorizing a fail-open run, confirm:
The task is genuinely local and bounded. No external network calls, no shared state, no production data.
You can identify the operator. Fail-open receipts are bound to OIDC operator identity — the run isn't anonymous.
You'll review the receipt afterward. Don't authorize a fail-open run and forget about it.
craik receipts list --policy-id ...is your audit trail.There isn't a cleaner fix. If you find yourself reaching for fail-open repeatedly, the policy envelope or credential profile probably needs to change instead.