Secure Craik

Craik treats governance as a runtime concern. Policy envelopes, capability grants, credential identity, redaction, and sandboxes are all addressable objects — not advisory configuration. This section is the implementation map for everyone responsible for the safety, identity, and audit properties of their Craik install.

Implementation paths

01

Governance fundamentals

Policy is part of the runtime contract.

Start here to understand what "governance" means inside the runtime, then configure the basic envelope you want every task to run inside. Five docs cover the concept, the runtime model, the grant surface, the scope-control flow, and the narrow fail-open exception.

Concept · 01

Governance

The governance surface Craik enforces — policy profiles, capability grants, immutable paths, fail-open visibility, receipts, redaction, memory-proposal defaults, and the policy regression gate. Strict by default; trusted-local is opt-in; automation is fail-closed.

• policy profiles
• capability grants
• immutable paths
• release gate

Read the concept

Runtime-native

Craik should be governance-native. Policy is not an enterprise add-on; it is part of the runtime contract.

— Governance model · §Intro

1. 02Model

   Governance model

   The top-level statement of intent: Craik must be governance-native, not an enterprise add-on. Policy travels with every run, every grant is typed, every immutable boundary is enforced.

   Read
2. 03Grants

   Capability grants

   Side effects require explicit, scoped grants — no ambient authority. Three practical outcomes: allowed, denied, or requires_approval. The v0.1 runtime enforces four capability hooks today.

   Guide
3. 04Scope

   Scope control

   The six intent-lock knobs (accepted_interpretation, in-scope, out-of-scope, allowed autonomy, stop conditions, scope-change rules) plus the mid-run update flow.

   Guide
4. 05Exception

   Fail-open behavior

   Default is fail-closed. Fail-open is profile-gated, opt-in only, and never bypasses redaction, receipts, immutable paths, or memory-write approvals. Automation is always fail-closed.

   Guide

02

Policy

The policy envelope — per-run governance object.

Three docs cover the policy contract: the named profiles Craik ships, the regression-test harness that verifies the profile contract, and the operator workflow for running it locally and in CI.

Profiles · 01

Policy profiles

The named profiles Craik ships — strict (default), trusted-local (opt-in fail-open), and automation (strict-but-headless). Design rationale lives in ADR 0004.

• strict default
• trusted-local
• automation
• ADR 0004

Read profiles

Design rationale

Design rationale: ADR 0004 Policy Envelope Shape — actor, task, profile, grant requirements, redaction posture, and receipt obligations all bound into one typed record.

— Policy profiles · §Intro

1. 02Gate

   Policy tests

   craik policy test is the machine-readable policy regression gate for v0.1. Exits non-zero on any violated check and prints a structured craik.policy_test_report.

   Reference
2. 03Operator

   Running policy tests

   How operators and release engineers run the policy gate locally and in CI — what each of the six checks covers, how to extend the suite, and where the harness touches local state.

   Guide

03

Identity & credentials

Operator identity — separate from credential identity.

Every provider call is bound to both an OIDC operator identity and a typed credential profile. Receipts record both, so audit can answer both "who authorized this" and "which credential carried it" without inspecting secret material. Two docs cover the working surface and the underlying design.

Workflow · 01

Authentication & credentials

The operator-facing surface: OIDC login, credential profiles (api-key, provider OAuth, keyring-ref, vendor-cli), credential pools with rotation and failover, workload identity for CI, and the approval-gated first-use flow. Every credential is referenced — never copied.

• OIDC operator identity
• typed credential profiles
• credential pools
• workload identity

Walk the auth flow

Two identities

Craik separates operator identity from credential identity. The operator is the human or automation identity driving a run. The credential is the provider account used for model calls. Provider receipts record both.

— Authentication · §Intro

1. ADR 0007Accepted

   Credential & identity architecture

   The design rationale. Credentials and operator identity are governance inputs — never incidental plumbing. Every receipt names which human authorized work, which credential carried the call, which policy allowed it, and which grant made the credential usable.

   Read decision

04

Secrets, redaction & release

Secrets travel as references — never values.

Four docs cover the secret lifecycle: where secret material lives, the central redaction utility that scrubs every persistence boundary, the migration policy that refuses to copy secrets across runtime boundaries, and the release process that preserves these properties across version bumps.

Overview · 01

Secrets

Where secret material lives, the owner-only-permissions discipline, what the redaction guard never lets through to receipts / handoffs / logs / case files / memory proposals, why policy and grants don't override redaction, and how to extend the guard for project-specific patterns.

• secrets directory
• five redaction categories
• policy + grants don't override
• extensibility

Read the overview

Tier

Craik treats secrets as sensitive runtime material — not as configuration. They live in a single, narrow directory; they never leak into receipts, case files, or handoffs in raw form.

— Secrets · §Key-point

1. 02Guard

   Redaction

   The central runtime redaction utility runs before every persistence boundary. Bearer tokens, key/value secret shapes, auth URLs, configured patterns, and structured fields with secret-like names — all scrubbed before storage.

   Reference
2. 03Policy

   Secret migration policy

   Migrations must never copy secret values across runtime boundaries. Four policy outcomes: redact · strip · reference · reject — never copy as-is.

   Reference
3. 04Process

   Security release process

   Security releases use the same package gates as normal releases, plus additional advisory and disclosure handling — so security fixes never skip the regression suite or the doc-update obligation.

   Process

05

Evidence & memory governance

Memory is governed — truth doesn't silently overwrite truth.

Five docs cover how Craik separates evidence from assumptions, how contradictions surface and resolve, and how every memory update flows through proposals, diffs, and impact previews before it can become a durable fact.

Foundation · 01

Evidence & assumptions

The honesty rule that grounds memory governance. Evidence is source material the runtime can cite. Assumptions are unresolved claims that should not be treated as facts yet. Promotion requires evidence — period.

• evidence_reference fields
• assumption ledger
• promotion rule
• immutable docs as evidence

Read the foundation

Honesty rule

Evidence is source material the runtime can cite. Assumptions are unresolved claims that should not be treated as facts yet. Conflating the two is how an agent runtime starts hallucinating policy.

— Evidence & assumptions · §Key-point

1. 02Inbox

   Contradiction inbox

   First-class workflow record for "two things disagree" — docs vs. implementation, handoff vs. branch state, reviewer vs. implementer. Distinct from Stigmem memory-substrate conflicts; cross-linkable when both exist.

   Guide
2. 03Lifecycle

   Memory proposals

   Create, list, approve, reject — and the promotion rule that requires evidence. Direct durable writes still need a memory.write grant; until then, proposals are the path.

   Guide
3. 04Audit

   Memory diffs

   What a task changed in memory: proposals created, approved, rejected; facts written and read; write failures. The single object reviewers inspect when deciding whether a run's memory effect was acceptable.

   Guide
4. 05Preview

   Memory impact preview

   The read-only forecast before promotion: facts that would be added or invalidated, likely contradictions, proposals missing evidence, and scope visibility counts. Previews never write.

   Guide

06

Sandboxing

Tool execution under policy-bound sandboxes.

Side effects run inside a sandbox backend chosen to match your trust boundary. Six docs cover the sandbox contract, the four backends Craik records (local process, remote shell, Docker, browser), and the environment receipts every sandbox decision emits.

Contract · 01

Sandbox backends

craik.sandbox_backend describes an execution environment backend without binding it to any model provider. The backend names its identity, capability requirements, redaction posture, and the receipts it emits — runners pick a backend by name, not by ambient process state.

• provider-agnostic
• capability requirements
• receipt boundary
• four backends today

Read the contract

Decision boundary

craik.sandbox_backend describes an execution environment backend without binding it to any model provider.

— Sandbox backends · §Intro

1. 02Backend · local

   Local process backend

   Execution through the host process environment. Intentionally a decision boundary — not ambient shell. Local backend doesn't grant runtime authority unless a matching grant exists.

   Reference
2. 03Backend · remote

   Remote shell backend

   SSH or equivalent remote command execution as an auditable boundary. The backend records the decision; it does not open connections or execute commands by itself.

   Reference
3. 04Backend · docker

   Docker sandbox backend

   Containerized execution as an explicit environment boundary. The backend records image, build args, and grant boundaries — it doesn't start containers itself.

   Reference
4. 05Backend · browser

   Browser tool boundary

   Browser automation and tool execution as a policy-controlled sandbox. The boundary captures origin, profile, allowed surfaces, and the receipts emitted for each navigation or action.

   Reference
5. 06Receipt

   Environment receipts

   Normal craik.capability_receipt records for provider, MCP, sandbox, local process, remote shell, browser, and container decisions. One receipt shape across every environment surface.

   Reference

Where to go next

• Build something new → Build
• Run and inspect the system → Operate
• Understand the model → Learn