Security overview.

What ZAK trusts, and what it does not

ZAK assumes the thing doing the work can be wrong, compromised, rushed, or incomplete. The governance boundary is where authority, evidence, and safety checks happen.

• Executor: model / workflow / human system that produces an output (untrusted by default).
• Governance engine: evaluates laws and enforces outcomes (must be deterministic and minimal).
• Receipt layer: produces tamper-evident artifacts for audit (hash, chaining, signatures).
• Storage: append-only semantics determine long-horizon audit strength.

Rules that should not be bypassed

The governance envelope encodes invariants that are intended to be mechanically enforced: consent required, audit logging enabled, and signature verification required.

When something is unclear, fail closed

• Transform failures: if safe transform fails, output is withheld (silence) instead of leaking raw output.
• Denials: denials are first-class and always receipt-producing.
• Ambiguity: uncertain or missing constraint information should default to stricter handling.

What we design against

• Policy bypass attempts: prompt injection / authority override / workflow shortcutting.
• Receipt tampering: mitigated by hash verification and (in production) signature + append-only storage.
• Replay/double-submit: mitigated by request IDs and idempotency keys on action endpoints.
• Key custody: signing keys must be isolated and audited (HSM/KMS patterns).

Where to check the claims

• Proof — generate a receipt and verify locally.
• Receipt schema — inspect the audit surface.
• Verification guide — offline verification steps.