Compliance & evidence
What Kaizen can produce for a reviewer, and what it deliberately will not retain.
What Kaizen can show
Who did what
The append-only audit trail records every consequential operation with its actor, target (when already authorized), outcome, and a bounded reason category. Coverage includes tool use, actions, approvals, denials, membership and invitation changes, resource lifecycle, task control and execution, configuration changes, and sandbox isolation denials.
Because every agent flows through the same funnel — individual agents do not implement their own audit path — enabling a new agent cannot create a gap.
What a scheduled run actually did
Each run carries an append-only, gap-free task_run_event timeline: state
transitions, reason categories, step and attempt correlation, duration, token
and cost counts, exact policy and target versions, and opaque source
references.
The timeline is reconnectable and reproducible: replaying it creates no new event and no audit row.
What version was in force
Tasks pin an exact target version. Agents append versions rather than overwriting. Artifacts are immutable per version. Occurrences preserve schedule revision and timezone-data version.
So "what did this run actually execute?" has an exact answer, not an inference from the current definition.
Who could see what, and why
The chat header and library cards show the current viewer's own access reason — Owner, Direct, Project, or a combination. Project deletion and membership removal both surface an impact preview before they commit, and the resulting pointer changes are audited.
Configuration state
The operator surface can report effective configuration and diff it, so "what was this deployment set to?" is answerable without reading environment variables off a running container.
Cryptographic baseline
Every code-producing Kaizen build and runtime stage uses a FIPS-validated Chainguard base. That covers the application and worker images, the web tier's nginx, PostgreSQL, SeaweedFS, Valkey, Tika, the pi harness, the sandbox worker and its per-run base, and the egress proxy. No stage compiles against a stock provider and hands the result to a validated one.
Nine release Dockerfiles also start with the digest-pinned
kamiwaza-licenses source image. This notice-only stage is not asserted to
have a FIPS-validated base: it supplies text files under /licenses/, not
compiled code or runtime executables. The final runtime stages still use the
Chainguard/FIPS bases above.
The code-bearing runtime images carry a NIST-validated redistribution of the OpenSSL FIPS provider and run in approved-only mode: only approved algorithms are available, and MD5 and SHA-1 are refused outright rather than downgraded. Entropy comes from a userspace jitterentropy source, so a FIPS-mode host kernel is not required. The module boundary stays inside the container.
Two consequences are worth stating to a reviewer before they find them:
- Approved-only mode is not advisory. PostgreSQL's
md5()raisescould not compute MD5 hash: unsupported, and Python'shashlib.md5()raisesUnsupportedDigestmodError. Kaizen uses SHA-256 wherever it needs a digest, including for display-only pseudonyms in usage reporting. - A validated base does not validate every dependency. Some Python wheels ship their own statically linked cryptography rather than calling the system provider. Where that is true, those specific operations run on unvalidated code even though the surrounding image is validated. Treat the image baseline and the dependency inventory as two separate claims, and ask for both.
TLS against these containers requires TLSv1.3, or TLSv1.2 with the RFC 7627 extended master secret extension. A client without RFC 7627 cannot connect.
What Kaizen will not produce
These are design decisions, and a reviewer should expect them:
| Not retained | Why |
|---|---|
| Chat text or answers in audit records | An audit log holding chat content needs the same protection as chat, while being read more widely |
| Raw tool arguments and results | Same reason; traces carry opaque references instead |
| Hidden model reasoning | Never projected into any member-visible or audit record |
| Raw provider errors on any member-visible or audit surface | Normalized into safe categories first; the server log is a deliberate exception |
| Presence history | Heartbeats, tab counts, devices, IP addresses, typing text, last-seen — not monitoring data Kaizen keeps |
| ACL membership lists in denials | Would leak the thing the denial protects |
| Credentials, tokens, cookies, auth headers | Never in task rows, queue payloads, logs, audit payloads, or member responses |
The server log is the one place a provider's own error text is kept, so that an upstream failure can be diagnosed without capturing traffic inside the pod. It is bounded and passes the same redaction as every other record, and none of it reaches a member response, an audit payload, a task trace, or a metric. See Observability.
If a control requires content-level logging of conversations, that is a deployment-level decision to make deliberately and elsewhere — not something to switch on inside Kaizen's audit funnel.
Retention
Retention windows are deployment policy, not a product constant. Occurrence, run, trace, notification, and audit records each follow their own independent policy and outlive the live object they describe.
Deletion changes reachability, not history. Guaranteed erasure is a separate, reviewed operation applied in bounded owner-scoped batches with removed counts recorded — never a side effect of a member clicking delete.
See Data handling & retention.
Evidence for common questions
| Reviewer asks | Where to look |
|---|---|
| "Can an agent see more than the user?" | Permissions — enforcement is in-query; tools re-resolve at call time |
| "Can the AI take an action on its own?" | Approvals — the member's resolved mode controls prompts; grants, ACLs, MFA, sandboxing, and audit remain mandatory |
| "What happens to code the AI runs?" | Isolation — deployment-selected isolation, single-tenant leases, egress proxied, scoped, and audited |
| "What if a prompt is manipulated?" | Guardrails — containment is structural |
| "Who saw this document?" | Audit resource-link and source-denial events |
| "What did this scheduled job do at 03:00?" | The run's occurrence record and task_run_event timeline |
| "Is third-party code sandboxed?" | Isolation — the package runner holds no secrets |
| "Where is our data?" | Data model & storage |
| "Is the cryptography FIPS validated?" | The cryptographic baseline above — validated provider in approved-only mode across every image, with the dependency-level caveat stated |
Operational evidence
Metrics use bounded status, trigger, result, and reason-category labels. They never label by owner, task, run, target, prompt, model output, or email — adding cardinality to make a dashboard identify a member is explicitly out of bounds.
Correlate aggregate metrics with owner-scoped audit records and safe run diagnostics rather than widening the metric.
See Observability.
Preparing for a review
- Capture effective configuration and the feature-flag state.
- Record the deployment version these pages describe.
- Export the audit range under review.
- Note the retention windows in force.
- Identify which connected systems are in scope — their permissions are theirs, and Kaizen reads as the member.
- State the out-of-band assumptions from the threat model: platform authentication, network policy, connected-system permissions, secret hygiene, and backup protection.