Legal & Safety

Security & Encryption

Last updated: 1 September 2026

1. What is encrypted, and how

Message content and long-term memories are encrypted before they are written, and only the ciphertext is stored. The scheme, stated at the level a reader can check us against:

• A key per user, derived rather than stored. Each account’s key is derived with HKDF-SHA-256 from a master secret held in the platform secret store, salted with the account identifier. Keys are never written to the database and never leave the worker that derives them.
• AES-256-GCM, with the account bound into the ciphertext. The account identifier is authenticated as associated data, so a row copied from one account to another does not decrypt — it fails. Tampering with a stored row fails the same way rather than yielding altered text.
• A write that cannot be encrypted does not happen. If the key fails to resolve on a live deployment, the write is refused with an error rather than quietly falling back to storing readable text. That failure mode was chosen deliberately: a database silently filling with plaintext looks identical, from the outside, to one that is working.
• In transit, TLS 1.3 — including to the model providers, whose handling is covered in the Privacy Policy.

2. What a stolen database would actually contain

The instructive incident in this category is the Muah AI breach, in which a companion service’s user email addresses were exposed alongside their prompt history — one dataset joining who someone is to what they asked for. The lesson we took from it is not “have better security”, which everybody says. It is assume the breach and make the stolen dataset worth less.

• The database alone: ciphertext for message and memory content. No keys are in it, because keys are derived from a secret that is not in it.
• The secret alone: nothing. It decrypts no rows without the rows.
• A compromised application server: plaintext, for as long as the compromise lasts. This is the honest limit of encryption at rest, and section 4 is why it is unavoidable here rather than a corner we cut.

Two further reductions matter more than they sound. Long-term memory is stored as distilled summaries rather than raw transcripts, and raw turns expire — so the readable set at any moment is a window, not an archive. And the things we never hold cannot be taken: there is no image upload surface in the product at all, and voice notes are transcribed and the audio discarded in the same request rather than stored. Retention periods for everything else are listed in the Privacy Policy.

3. Generated media

Images and clips are held in private object storage under a path scoped to the account that made them. Nothing in that store is publicly addressable: every byte is served through an authenticated route that re-checks ownership on each request, and an asset is not served at all — not even to its owner — until it has cleared output classification. An asset later quarantined stops being served on the next request, with no separate un-publishing step. How that classification works is on the safety page.

4. Why end-to-end encryption is impossible here

End-to-end encryption means the keys exist only on the endpoints and the operator cannot read the content — not that the operator promises not to. That property is incompatible with moderating content, and this product moderates content. Three places in a companion service require the plaintext, and no arrangement of keys removes them:

• The safety classifiers. Every request is classified before it reaches a model, and generated output is classified before it can be served. A classifier that cannot read the text is not a classifier. The hard floors described on the safety page exist only because something in the request path can read what you wrote.
• The model that answers you. Her reply is generated from the conversation window. The window is submitted to a model provider as text. Encrypting it to a key we hold, or to one you hold, changes nothing about that step.
• The complaint and appeal path. A removal request, a law-enforcement production order, or an appeal against a refusal all require someone to look at the content in question. A service that genuinely could not read its own content could not answer a takedown, which is a legal obligation rather than an option.

So when a product in this category advertises end-to-end encryption, exactly one of three things is true: it is not moderating what it generates, or it is using “end-to-end” to mean the TLS every website has had for a decade, or the claim is simply false. We say this plainly because the claim is in circulation in this market — including inside machine-readable page metadata, where it propagates to readers who never see the page it came from and cannot see a caveat next to it.

What we can honestly offer instead is this page. Encryption at rest under per-account keys with the key material outside the database, a retention window that keeps the readable set small, categories of data we structurally do not hold, and a plain statement of the one attacker — a compromise of the running application — that this design does not defeat. Overclaiming encryption is a consumer-protection risk in its own right, and it is exactly the kind of claim consumer-protection regulators have said they scrutinise.

5. What we do not publish, and why

This page states properties, not parameters. We do not publish secret names, the key hierarchy, rotation cadence, infrastructure topology, or the internals of the classifiers — for the same reason the safety page does not publish its detection terms: those details help an attacker considerably more than they help you evaluate us. Everything on this page is written so that it can be checked by its consequences instead. If a claim here is false, it is falsifiable by testing the product, not by taking our word.

6. Reporting a vulnerability

Email abuse@flirtly.co. We will not pursue anyone who reports a vulnerability in good faith and does not exploit it, does not access or exfiltrate other people’s data, and gives us a reasonable window to fix it before publishing. Breach notification duties, and the timelines we are held to, are in the Privacy Policy.