Security.

Nothing sensitive to breach#

Your logs, chats, memory and photos are stored only on your device. There is no central database of readable user health data to breach, because it does not exist. An attacker who reached our servers would find accounts, aggregate counters and ciphertext, not anyone's diary.

Namespaced per account#

On a shared device, each account's data is isolated under its own namespace in local storage, so signing in as someone else never exposes your entries.

In transit#

Every connection is encrypted with TLS. Your messages to Kata and the context needed to answer them travel encrypted and are used to generate the reply: Kata's servers keep no copy, and our AI provider deletes them within 30 days and does not train on them. Connection tokens (such as WHOOP) are kept on your device, sealed in the iPhone app and in an httpOnly cookie in a browser, and never in a server database.

Sealed under your own key#

The one copy of your data that leaves your device, the restore snapshot of the web app and the Android app, is encrypted there first with AES-256-GCM under a random 256-bit key generated on your device and kept there, on Android also in Google Block Store with your Google account. The key is never sent to us in any form, and the sealed row holds no key, no key identifier, no hash and no check value, so there is nothing on our side against which a guess could be tested. Your recovery key is the copy of that key that you hold. See Backup and restore.

Accounts#

Authentication is handled by Supabase with the project hosted in Switzerland, Zurich region, and it stores no health data: only your email, sign-in method and timestamps. Sign in with a password, Google, Apple or a magic link; with Sign in with Apple you can hide your email behind Apple's relay.