Private by design
Isolation enforced in the database, field-level encryption with per-user keys, and an honest account of what the end-to-end layer does and does not give you.
This page is written to be checked. If you handle other people's legal, immigration or medical matters, the claims below are ones your client will eventually ask you to substantiate.
Two independent boundaries
Two independent guarantees over the same rows — neither depends on the other holding.
Isolation is enforced by the database, not by application code. Row-level security means a query
that forgets its filter returns nothing rather than someone else's rows. Application-level scoping is
one forgotten WHERE away from a data leak; this is a different class of guarantee, and it is why the
platform puts the boundary there.
Encryption is independent of it. Even with database access, conversation and document content is ciphertext.
The envelope
Encrypted fields are stored in a fixed layout:
Not to scale. The ciphertext dominates in practice; the header fields are a handful of bytes.
Two consequences fall out of that shape.
Keys can be rotated without a migration. The version travels with the ciphertext, so a user can hold several data-encryption keys at once: new writes use the active key, and reads select the key the ciphertext was written with. Rotation becomes a gradual re-encryption rather than a stop-the-world event — which matters, because a rotation scheme that requires downtime tends never to be exercised.
Ciphertext cannot be relocated. The AEAD's additional authenticated data binds each value to its
(tenant, user, space, field). Copying a ciphertext into another row, another field or another
tenant's record makes it fail to decrypt rather than silently reveal its contents — so a database-level
tampering attempt does not become a data leak.
Where the keys live
Each user's data-encryption key is wrapped by a key-encryption key, behind a key provider abstraction. The current implementation reads the KEK from application secrets. The seam exists so that a KMS, a vault, or per-tenant bring-your-own-key can be introduced by configuration — without changing the data model or any calling code.
Being precise about the present state: today the KEK is held by the application. That is appropriate for the current deployment and it is not the same thing as a customer-managed key.
The limit of any hosted agent, and what to do about it
Sensitive conversations can add an end-to-end layer: the client sends an ephemeral ECDH (P-256) public key, the server derives a session key via ECDH and HKDF, and each streamed chunk is encrypted with AES-GCM and decrypted in the browser. It reduces exposure at the streaming layer, on top of TLS.
It is not zero knowledge, and no hosted agent can be. This is worth stating plainly because it is a property of the problem, not of this implementation: to retrieve from your knowledge base the server must embed and compare your content, and to answer it must generate from the passages it retrieved. A system that could not read the material could not search it or answer from it. "Zero-knowledge knowledge base" is a contradiction, and any vendor offering both is describing one of them loosely.
So the honest framing is not whether the operator can read the content, but who the operator is.
On our cloud, we minimise what is exposed
- Content is encrypted at rest with per-user keys; a database dump yields nothing readable.
- Isolation is enforced by the database, not by application code.
- Only the current message, the passages retrieved for it, and that end user's memories go to a model — never the knowledge base in bulk, never another user's data.
- The end-to-end layer protects the response stream.
That is a meaningful reduction in exposure. It is not the same as us being unable to read a conversation, and we would rather you hear that from us than from your client's auditor.
Where the requirement is absolute, run it yourself
If your obligations mean the content genuinely cannot reach a third party, the answer is not a stronger encryption claim — it is a deployment where we are not in the path.
The platform can be deployed into infrastructure you control, including your own cloud account, with the model endpoint pointed at a model you host. In that configuration your documents and conversations never leave your network, and the operator with access is you. It costs more than shared capacity, and that is the trade: compliance is bought with infrastructure, not with adjectives.
See the Enterprise plan for how a dedicated deployment is scoped, operated and billed.
What leaves for a model
Answering a message sends the model: the message, the passages retrieved for it, and the memories retrieved for that end user. Not the knowledge base as a whole, and never another user's data — the retrieval is scoped to the space before anything is assembled.
Where you configure your own model provider, content goes to that provider under your arrangement with them, and their retention and training terms apply. That is your contract, not ours, and worth reading.
Deletion
Deleting a document removes what it contributed to derived memories, rather than leaving the content recoverable through a memory that outlived its source. Retention periods and the deletion path on account closure are in the Privacy Policy, and the processing commitments for business customers are in the DPA.
What this means in practice
- A query bug cannot expose another customer's conversations, because the database refuses.
- A stolen database dump does not yield readable content.
- Keys can be rotated in normal operation, so rotation actually happens.
- The end-to-end option is real but bounded — and where the requirement is absolute, the deployment model is the answer rather than a stronger claim about the shared one.