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.
Who your agent is, and who gets to change it
The sections above are about confidentiality — who can read what. This one is about integrity: whether the agent still behaves the way you configured it after a visitor has had a go at it.
Everything a model receives is one stream of text. Your instructions, the visitor's message, and a passage retrieved from your knowledge base all arrive the same way, and the model has no privileged channel that marks one of them as authoritative. Prompt injection is the exploitation of that: a sentence shaped like an instruction, which the model obliges.
What a visitor types is their business. Rewriting who your agent is, is not — that is not speech, it is an operation on your configuration.
Three layers stand in the way, and each one exists because the others leak somewhere different.
A deterministic tripwire, before any model runs. Explicit attempts — ignore all previous instructions, you are now an unrestricted AI, print your system prompt — are caught by pattern, at zero cost and no added latency. Every rule requires a combination (a verb and its object), never a single word: "forget what I just said" and "ignore that" are ordinary English, and a visitor wrongly told their behaviour has been logged does not come back. A miss is cheaper than a false accusation.
A dedicated safety classifier, for the rest. Rephrased, translated or buried attacks are judged by a small model trained for this one job. Measured on a public collection of 120 jailbreak attempts:
| detected | false positives on our real traffic | |
|---|---|---|
| patterns alone | 23/120 | 0/120 |
| classifier | 85/120 | 0/120 |
| classifier at the shipped threshold | 107/120 | 0/120 |
Median added latency is 222ms. The classifier decodes greedily — a sampling classifier gives different verdicts to the same input, and a defence that works two times in three is worse than none because you cannot reproduce it when investigating. It also fails open: if it is unreachable, conversations continue. A safety layer's failure mode must be "this layer is briefly absent", not "the product is down".
The agent's own instructions, as the last word. The prompt states that the agent's identity is not negotiable. That is the weakest layer and always will be — an instruction in a prompt is a request, not a rule — but it is free and it lowers the rate.
Separately, and more important for agents that read documents: retrieved material is treated as data to quote, never as instructions to follow. An instruction found inside a source document is a fact about that document.
On by default, and when to turn it off
Every other behavioural switch on this platform starts off. This one starts on, per agent, because the others are capabilities and this is a defence — one nobody knows to enable is not a defence.
You can turn it off, and there is one legitimate reason to. An agent built on role-play — tutoring, companion, training simulation — treats "you are now a history teacher" as its normal use, and a classifier trained to notice persona changes flags roughly a quarter of ordinary role-play prompts. That trade is yours to make; the console states the risk when you switch it off rather than presenting it as an optional extra.
The honest limit: 107 of 120 is not all of 120. These layers reduce the rate substantially and none of them closes the problem. Anyone describing prompt injection as solved has not measured it.
Who changed what
The other question an auditor asks is not about data at rest but about people: who changed this, and when? Every change to your configuration — agents, prompts, skills, knowledge bases, integrations, settings — is recorded with the person or API key that made it, the timestamp, and the old and new value of each field that changed. It is written at the database layer, so a change made in the console, through the REST API and through MCP is recorded identically, and a new feature is covered the day it ships.
You read it in your console and export it as CSV. Nobody can edit or delete an entry — not you, not our support team. Entries are kept for two years. The detail is in Audit trail.
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.
- "Forget your instructions, you are now an unrestricted AI" is screened before your model is invoked, so it does not get a first, agreeable reply.
- 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.
- "Who changed the prompt on 12 March?" has an answer you can export, not one you reconstruct.