How the vault works, and where it stops.

Intrusive thoughts are the content people are most ashamed of. Harm, sexual, blasphemous. If you believe an operator can read the transcript, you withhold, and a tool you lie to is worthless.

So the encryption is not there for a compliance checklist. It exists so the honest sentence can be typed.

All of it is AES-256-GCM ciphertext, sealed in your browser before it is sent. The server never holds a key.

One test runs a whole conversation, then searches every collection in the database for a phrase that was in it. It fails if it finds one. It is the only test that checks the promise itself rather than a stand-in for it.

Signing in proves you own an email address. A link is sent, you click it, and no account password is held anywhere. Losing a session costs you a fresh link and nothing else.

Unlocking the vault is a separate step with separate secrets. A random data key is generated once in your browser, never derived from anything, and never changed. Each way of unlocking wraps that same key independently.

A passkey means Face ID, Touch ID or a security key, through the WebAuthn PRF extension: the authenticator computes 32 bytes from a secret it never hands over, and only after you have proved you are present. The passphrase and the recovery code are stretched with Argon2id before they become keys, and your browser refuses parameters below a compiled-in floor, so a server cannot hand back weak ones to make guessing cheap.

Because the data key never changes, changing a passphrase rewraps one small blob and touches no message. Two unlock methods is the minimum, and the server refuses a removal that would leave fewer, so a lost phone can never be the only way in. A trusted device never counts towards the two: it lives on one machine and dies with it.

Your vault is lost only if every method is lost at once. That is inherent to our holding no key, and it cannot be engineered away without our holding one. What you keep in that case is the account you pay for: a reset deletes the sealed records and every wrap, keeps your subscription and lesson progress, and starts a fresh vault.

In a key object the browser will not export, inside a dedicated Web Worker. Never in session storage, never in application state.

Be precise about what that buys: it prevents the key being stolen, and it does not prevent the key being used. A script injected into the page cannot read the key out, but it can ask the worker to decrypt while the tab is open. That turns a one-shot theft of a key that works forever into an oracle that works only while you are there, and only if the page’s policy lets it send anything out. It does not.

Some browser extensions patch workers and break them. When that happens the same code runs on the main thread instead, the key is still unexportable, and what is lost is the worker boundary that made a stray reference harder to reach. The worker path is always tried first.

Every ciphertext carries, bound into it, the version, your user id, the conversation, the message’s position, who said it, and which key version sealed it. Without that, a server could reorder, replay or graft messages between conversations and your browser would decrypt them happily.

The wraps use the same construction rather than the standard key-wrap mode, because the standard cannot carry that binding and so cannot stop a rollback to a superseded wrap.

Plaintext is padded to 256-byte buckets before sealing. The length of a message, next to its timestamp, is a meaningful signal about a mental-health transcript.

To write a reply, the model has to read your message. Your message and the recent conversation are sent to Anthropic unencrypted. Everything below narrows that window rather than pretending it is not there.

The model is Claude Sonnet 5, deliberately. It is the current model on which Anthropic offers zero data retention: inputs and outputs are not kept after the request and are not trained on, under our zero-data-retention arrangement. Anthropic retains prompts to its Fable and Mythos models for thirty days for safety work, so switching to one of those would be a privacy-policy change, and we would tell you first.

The chat route logs nothing and caches nothing. It reads metadata, the counts and timestamps and the ceilings you set, to enforce those ceilings before relaying, and it writes exactly one thing afterwards: the token counts the provider returned, added to the month’s total. Writing to the console is a lint error on that path, because the host captures standard output into logs.

The agent framework runs with its memory off and its telemetry off. It switches on remote export the moment it sees its own cloud keys in the environment, so production refuses to boot if they are present, and the deployment pipeline checks the environment for them before a deploy. A separate test runs the chat route under a stand-in model and fails if any request reaches a host outside Anthropic.

Timestamps are the strongest residual signal. Long sessions in the small hours, growing week on week, is clinically meaningful and readable without a word of plaintext. It cannot be removed while offering sync across your devices, so it is named here rather than hidden.

Some things are missing from the database on purpose, each of which looked like harmless metadata. There is no readable field for which register a conversation ran in. The usage ledgers carry no conversation id, because per-conversation traces rebuild a behavioural graph. The safety counters carry no user id at all. Email and network addresses are stored only as keyed hashes.

An administrator can look an account up by email and see the metadata above, resend a sign-in link, refund a subscription and sign an account out everywhere. Each of those is logged with who did it and when. An administrator cannot read a conversation, for the same reason nobody else can. The exact fields that screen may return are pinned by a test, so a new one has to be argued in.

There is no human escalation and no per-user crisis flag. That is a product decision with a clinical reason as well as a privacy one.

Harm-themed intrusive thoughts are among the most common shapes this loop takes. They are the opposite of what the person wants, they do not indicate risk, and practice deliberately brings them up. A classifier tuned for self-harm would fire on that practice constantly. Worse, showing a crisis card every time such a thought appears teaches that the thought is dangerous, which is the belief the practice exists to wear down.

Three layers stand instead, none of which reads anything. A Get help now control is on every screen, never conditional, rendered from data bundled into the page. The coach can offer the same numbers through a tool call that carries a category and no free text. A prefilter in the browser catches means-and-plan language when the model misses, and is never transmitted. What is counted is a global daily total with no user id.

The consequence, stated plainly: we cannot reach out to someone in crisis. Onboarding says so, and the safety page carries the lines that answer at any hour.

Encryption delivered by a website is trusted on every load. Each time the page opens, the server has a fresh chance to ship different code, and code that holds your passphrase for a moment could keep it. A native app is signed once and reviewed by a store. A web app is not.

Subresource integrity does not fix this. Whoever can change the JavaScript can change the HTML that carries the hashes, and here both come from the same origin. It defends against a compromised asset host while the page itself stays honest, which is a different threat.

What actually helps, and where each control stands today. Any service claiming that browser-based encryption makes access impossible is not being straight with you, and the point of this table is that we are not claiming it either.

The counters store a keyed hash of the subject and expire with the window they count, so they never become a record of when somebody used an OCD app. Every bucket fails open when the counter cannot be read: a limiter that is down must not become a locked front door on a mental-health app.

There is no server-side limit on unlocking a vault, and there cannot usefully be one. The wraps are fetched once and every attempt happens in your browser, so the server never learns that a guess failed. Anyone in a position to guess already has the wrap and is guessing offline, where the only defence is the cost of each Argon2id attempt. A count of failures the client chose to report would be a control in name only.