Security model overview
Kaizen is designed so that a capable assistant can never quietly do something it should not. This page states the whole claim in one place; each layer links to the page that proves it.
Trace how untrusted requests and content cross identity, query authorization, policy, and isolated execution boundaries.
The claim, in one sentence
An agent acting for you can only see and do what you could see and do yourself — and guardrails, isolation, and audit are layered on top of that, never around it.
Everything below is how that sentence stays true.
Layer 1 — Identity comes from one place
Kamiwaza authenticates. Kaizen consumes a validated forwarded identity envelope and maps it to a member: a platform user id, and the lowercased verified email that is the document-ACL principal.
Kaizen never accepts identity or roles from a request body, a query parameter, a chat tool argument, a queue message, or model output. An authenticated identity without an email cannot be mapped safely and is refused.
→ Identity & the platform envelope
Layer 2 — Permissions are enforced inside the query
Access predicates live inside the PostgreSQL retrieval query. Every lexical, semantic, exact, and fuzzy branch consumes the authorization relation before producing output.
Raw candidate IDs and text never reach application code for post-filtering, because post-filtering leaks through counts, facets, pagination, and errors even when rows are withheld.
→ Permissions & ACL enforcement
Layer 3 — Policy lives in the trusted service
The agent runtime is powerful and empty. Guardrails — budgets, citation discipline, redaction, loop control — are part of the api-backend, so they apply no matter how the conversational loop behaves.
A prompt injection changes what the runtime asks for. It cannot change what the backend allows.
Layer 4 — Proposing is not authorizing
Anything that writes to the outside world crosses the write guard and, where policy requires it, an approval gate. An agent can propose an action; it never approves one.
Task ownership is not approval. An interactive confirmation is not a standing consent. A remote agent's card is not a permission.
Layer 5 — Anything risky runs somewhere else
Member code runs in a hardened, disposable sandbox keyed to actor and conversation. The deployment uses its standard container runtime by default; an operator can attach gVisor for stronger syscall isolation. Third-party package code runs in a separate secretless process. Outbound network access is proxied and off by default.
Failure to prove isolation is terminal for that attempt — Kaizen never falls back to a shared workspace, an owner workspace, the host, or in-process execution.
Layer 6 — Everything consequential is recorded
Tool use, actions, approvals, membership changes, and denials go to an append-only audit trail with privacy-safe reason codes.
The audit trail deliberately excludes what would make it a second data breach: chat text, queries, answers, raw tool payloads, credentials, hidden reasoning, source snippets, and presence.
→ Audit trail · Audit event reference
The default: fail closed
When authority cannot be proven, Kaizen denies. It does not:
- fall back to a weaker check,
- substitute a workload identity,
- reuse a stored snapshot as if it were current,
- borrow an owner's authority for a collaborator's turn,
- retry a write whose effect it cannot prove did not happen.
Denials use bounded reason codes that reveal no unrelated existence. An unrelated chat, an expired invitation, and a revoked membership all produce the same not-found response as something that never existed.
What is deliberately not collected
Some absences are design decisions, not gaps:
- Presence is not monitoring. Heartbeats, tab counts, device details, IP addresses, typing text, and last-seen history are not retained in the journal or the audit trail.
- Reasoning is not projected. Private model reasoning never enters the conversation journal, the audit trail, or a task trace.
- Raw provider errors are never surfaced. They are normalized into safe categories first.
Known boundaries worth stating
Honest limits, so an evaluator does not have to discover them:
- Connector content is untrusted text. Kaizen's defense is structural — it cannot become authority — not a claim that injection is detected.
- HNSW is not described as authorization-prefiltered. The index can inspect rows before relational filters fully apply; each branch therefore joins the full authorization relation and exposes only survivors.
- A2A is a proof of concept. Its shared-secret control is not a substitute for network policy.
- IT-issued standing approval is not available. Task-owner decisions use durable one-shot approval waits; they do not satisfy a policy requiring a current IT approver.