Security

One database per customer

Your memory is not a row in a shared table with a customer column on it. Each customer gets their own database. There are no shared tables and no cross-customer queries to get wrong, because the boundary is the database itself rather than a filter someone has to remember to write.

That boundary is tested from the outside on every release: two real accounts, and every door that returns data is checked to confirm neither can see the other. A release does not ship unless that passes.

Keys, and who can use them

We cannot show you your own key

API keys are shown to you exactly once, at creation. What we store is a SHA-256 hash — so a copy of our database does not yield anyone a working key, and neither we nor an attacker can read yours back out. Revoking a key takes effect on the service within about a minute, and immediately on the machine that serves your memory.

Keys can be narrowed

A key does not have to be all-powerful. Keys can be scoped per project — read and write, read-only, or invisible entirely — which is the right shape for a contractor, a CI job, or a single-purpose agent that has no business reading the rest of your work. A key with corrupted or unreadable scopes is denied everything rather than granted everything.

Two-factor authentication

Your account can require a second factor at login, and when you turn it on it is enforced at sign-in, not merely displayed as a setting. We recommend it and we do not force it: your memory is only as protected as the account that holds it, but making erasure of your own data conditional on enrolling a phone would be worse.

Protection from your own agents

This is the part most services do not think about. Your memory is operated on continuously by AI agents — and an agent can make a mistake, be handed a malicious instruction hidden inside content it was asked to read, or delete the wrong thing hours before a human notices.

So the raw conversation archive is deliberately beyond their reach. No agent can delete a single message. No agent can touch the last three months at all. Older history can only be removed in bulk, per project. Deleting an entire project — the one action that reaches the archive wholesale — is not available to agents at any tier; it happens in the account panel, where a human types the project name.

The reason this matters is simple: curated memory is derived, and the archive is the original. Anything a bad edit loses can be rebuilt from history. Nothing can rebuild history.

Encryption, backups and where your data lives

Traffic is encrypted in transit with TLS. At rest, your memory is encrypted twice: full-volume encryption underneath, and on top of it your database — every conversation, every record, and the write-ahead log — is encrypted under your own per-customer key, separate from every other customer’s. The key that unlocks the storage volume is not stored on the database server at all: a stolen disk, a leaked image or a decommissioned drive is noise.

Deletion is cryptographic

Because each customer has their own key, erasing you is not a hopeful sweep through storage: your key is destroyed and your database dropped, and what remains is unreadable by anyone, including us. The encrypted backups are deleted outright rather than left to expire, and any remaining copies are erased as our backup systems cycle, within 30 days at the most. There is no copy for us to bring back.

What per-customer encryption does not cover

Two honest limits. The database engine keeps internal query-planning statistics that sample column values; those samples live under the volume encryption, not your personal key. And encryption at rest is exactly that — at rest: the service necessarily decrypts your data to serve your searches and run curation, so “we never look at your data” is our policy and our access controls, not a mathematical impossibility. We would rather tell you where the line is than let you assume there isn’t one.

Backups run nightly, are encrypted before they leave our machines, and are stored off-site in the EU on a rolling schedule, kept for up to three months. When an account is deleted, its backups are deleted with it, and any remaining copies clear within 30 days.

Your memory is stored, indexed and searched entirely within the EU — our servers are in Frankfurt and our backups in Falkenstein, both in Germany. Search embeddings are computed on our own machines and never leave them.

The single exception is AI curation. The passage being curated is sent to Ollama, in the United States, processed, and returned. Ollama’s published terms state that inputs and outputs are processed transiently and are never used to train models — that is their commitment, in their own terms, and we state it as theirs rather than as a promise of ours. Nothing else leaves the EU. If you need curation never to leave the EU either, that is available on a dedicated deployment — ask. Every sub-processor, with purpose and location, is listed in the Privacy Policy.

How we operate

Least privilege, by default

The service runs as an unprivileged user inside its container, never as root. Its database role is not a superuser and cannot read files from the host. These are verified automatically before each release rather than assumed.

Internal endpoints are locked at the edge

The endpoints that provision accounts and validate keys are reachable only by our own control plane, authenticated at the network edge before a request ever arrives, and again by a shared secret behind it. Two locks, not one.

Fail closed

When something is missing or unreadable, the service denies rather than guesses. An unverifiable key is refused. Corrupt permissions grant nothing. A missing webhook signing secret rejects every event rather than trusting what arrives. This is a deliberate posture: the failure mode of a memory service should be “no answer”, never “the wrong customer’s answer”.

Every release is proven from outside

Before any release ships, an automated gate walks the whole product from a brand-new account through a real network connection: signing up, issuing and revoking keys, storing and recalling memory, isolation between two live accounts, data export, and full erasure. It either passes completely or the release does not happen.

Reporting a security problem

If you believe you have found a vulnerability, please tell us before you tell anyone else, and we will work with you. Contact details are published at /.well-known/security.txt or write to [email protected]. We do not threaten researchers who report in good faith.

Deeper requirements — a data processing agreement, a dedicated deployment in a region you choose, or keeping curation inside the EU — are things we handle directly. Ask.