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 every sign-in — after a password and after GitHub or Google alike — not merely displayed as a setting.

Creating an API key needs a protected sign-in: two-factor authentication on your account, or a sign-in through GitHub or Google. A password alone never creates a key — not even on an account that also has GitHub or Google connected, because what counts is how you signed in this time.

Every destructive act — deleting a project, redacting history, deleting the account, restoring a backup — asks again who you are: your password if you have one, and your two-factor code; without two-factor, a GitHub or Google sign-in from the last ten minutes. Exporting your data never needs it.

Sign in with GitHub or Google

Signing in through GitHub or Google uses the standard authorization-code flow with PKCE, tied to the browser that started it. We receive your email address, your name and your account ID at that service — nothing else. We keep no GitHub or Google access token, and we cannot read your repositories, mail or files. A GitHub or Google account joins an existing Brethof account only when that service has verified the email address and so have we, or when the account has no password yet.

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

Your memory is one container per customer — its own database, its own filesystem, its own Linux user, nothing shared. If you chose the local shape, that container runs on your machine: your memory is stored with you and we store none of it. What transits our hub — our secure-compute instance in Zurich, Switzerland — is the content being processed: each exchange, and the pieces of memory your container sends when a judgement is needed or a session brief is composed. Section 4 of the Privacy Policy lists them exactly. None of it is retained.

What the software on your machine is

The container holds your memory, the search over it, and the mechanics that keep both correct. It contains no prompt, no access to any AI model, and no setting that points it at one. There is nothing in it that can judge your memory, and nothing to configure that would let it try. Every judgement is requested from our hub over a connection your container opens outbound and authenticates — we never dial in.

That shape is what makes the traffic auditable, and you are meant to audit it: exchanges go up, the pieces above go up, commands and rows come back down. The client is source-available — read every line of it.

One thing stays entirely on your side: searching your own memory — the records, the whole history and its dated decision lines — runs as a plain read against your own tables, inside your own container. It works with our hub unreachable and sends nothing to be judged.

On the hosted shape, traffic is encrypted in transit with TLS, and at rest your container’s entire filesystem — every conversation, every record, the database itself — is encrypted under a key derived from a passphrase only you hold. We never see it and never store it: it transits when your session starts, unlocks your memory, and the memory locks itself again after you step away. A locked container is ciphertext to everyone, including us — a stolen disk, a leaked image or a decommissioned drive is noise, and so is our own root access while you are away.

Deletion is cryptographic

Erasing you is not a hopeful sweep through storage: your encrypted container is destroyed whole — and because deleting ciphertext needs no key, this works even if you have forgotten your passphrase. What backups remain are unreadable without it and are erased as the backup ladder cycles, within 30 days at the most. There is no copy for us to bring back.

What the encryption does not cover

Honest limits. Encryption at rest is exactly that — at rest: while your memory is unlocked for a session, the container necessarily works with your data in the clear to serve your searches, so “we never look at your data” is our policy and our access controls, not a mathematical impossibility — the mathematical guarantee is what you get whenever the container is locked. We would rather tell you where the line is than let you assume there isn’t one.

Backups of hosted containers are pulls of the encrypted filesystem itself — ciphertext before they leave the machine, unreadable without your passphrase — kept on a short rolling ladder of daily and weekly copies in Germany. When an account is deleted, its backups are deleted with it, and any remaining copies clear within 30 days.

Hosted memory is stored, indexed and searched entirely within the EU — our servers and backups are in Germany. Search embeddings are computed on our own machines and never leave them. Local memory never reaches any of this: it is on your disk, under whatever protection you give your disk.

The single exception is AI curation. Each passage being curated is processed on our secure-compute instance in Zurich, Switzerland — a country the EU recognises as offering an adequate level of data protection — and from there a single model pass is sent to Ollama, which hosts this model in the United States and Europe, 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 hello@brethof.ai. 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.