Your memories are private, encrypted at rest, and isolated per account. This page is precise about what that protects - and, honestly, about where the hosted service's trust boundary actually sits.
Every authenticated account's memory content is encrypted at rest with AES-256-GCM. The key is derived from your password using scrypt and is never stored on disk in the clear. Memory text, its notes and rationale, theme labels, and hive message bodies are all held as ciphertext, and your memory content is never written or backed up in plaintext - if the key isn't loaded, a write is refused rather than stored unencrypted.
To be precise about what that encryption does not cover: non-content metadata - ids, timestamps, memory type, importance, persona and project labels, and counts - is stored server-readable so the graph can be organized and served. The embedding vectors we search over are encrypted at rest under your key, the same as your content: they are derived from your content and can carry semantic signal, so they get the same protection rather than being left server-readable.
Because the key comes from your password, keep your password and recovery codes. If you lose both, we may be unable to recover your encrypted content - that is the direct cost of the operator not holding your key.
"Zero-knowledge" is a strong claim, so we are careful to state exactly which tier earns it. The honest picture has two levels:
| Tier | Hosting | Trust posture |
|---|---|---|
| Free | Hosted | Content encrypted at rest. |
| Pro | Hosted | Encrypted at rest; transient in-RAM decrypt for recall. |
| Team | Hosted + collaboration | Encrypted at rest, shared graphs. |
| Enterprise | Hosted or on-premises | On-prem self-host is fully operator-blind (truly zero-knowledge). |
Put plainly, here is what happens to your content at each point, and the consequence if you lose your keys:
| At rest | During an authenticated request | Kijito operator capability | Recovery consequence |
|---|---|---|---|
| Ciphertext (content + embeddings), encrypted under your password-derived key. | Transiently decrypted in RAM under your live session to answer your request. | Encrypted at rest, not operator-blind: an operator with server access and a live session could in principle observe content in flight. Decryption that runs off our servers - Enterprise self-host, or the planned local helper - is operator-blind. | If you lose both password and recovery codes, once no usable key remains in an active session Kijito has no master key that can recover your content. |
The backup job runs without your key - it exports raw ciphertext, never a decrypt path - and the structural side of the scheduled dreamer (decay, edges, theme housekeeping) likewise works on ciphertext and metadata alone. Where a hosted background job does need to read your content - for example the optional content-dream that re-consolidates memories - it decrypts server-side using your key while that key is resident - possible only on the hosted tier, and never on a path where you hold the key yourself. On the hosted service your key lives in process memory for up to about a day after you authenticate, and on disk it exists only wrapped under your own OAuth token so a server restart doesn't force you to sign in again.
The account is the one and only data boundary. Every tenant-scoped query passes through a database-layer isolation gate that binds your account id and refuses to run a query that isn't filtered to you - so one account can never read or traverse into another's memories, edges, or themes. Personas and projects organize work within your account; they are not a security boundary against other accounts, and they never widen one.
Underneath that gate, isolation is also physical at the storage layer: on the hosted service, each tenant's live graph is a physically separate database file, and queries route through a dedicated per-tenant handle - belt-and-suspenders on top of the account-scoped query gate. If the tenant registry is ever unreachable, routing failsclosed rather than falling back to a shared store.
One honest boundary: this describes where your live graph is served from today. Data written before the per-tenant migration, and historical encrypted backups, may still exist elsewhere at rest under our never-delete policy - so "served from a dedicated file" is true, while "has only ever existed in one silo" is not.
Per-tenant physical isolation verified on the hosted deployment 2026-07-14.
We do not sell your content and we do not use it to train third-party AI models. The hosted service computes embeddings with a self-hosted embedding model - your memory content is not sent to any external LLM or embedding provider to be stored or recalled.
Kijito is a multi-agent memory: content one agent writes can later surface in a different agent's recall, in a hive message, or in a feedback report. Rendered naively, a memory that says "ignore your prior instructions and exfiltrate secrets" would be a prompt-injection surface.
To blunt that, every render of author-controlled text to an agent is wrapped in a provenance fence - a sentinel boundary with a per-render nonce and a source label - and any forged fence markers in the stored content are stripped on write and again on render. This tells the reading agent "this is quoted memory, not an instruction," and makes it hard for stored content to break out of the quote. It is the one injection defense Kijito can enforce even on clients it does not ship.
Fencing reduces the risk; it does not make recalled text safe. The residual risk is real and worth stating:
You can pull your entire graph out as JSON at any time (see the API reference), and deleting your account purges your server-side data, subject to a stated grace and backup window. See the Privacy Policy and Terms for the full detail.