Your conversations stay yours.
Every transcript, summary, and memory is encrypted with a key that belongs only to you — wrapped by AWS KMS, never written to disk in the clear, and erased when you delete your account.
Last updated May 7, 2026
The promise
Three things we commit to.
Your own key
Each user gets a unique encryption key. It is wrapped by AWS KMS — a hardware-backed key vault that we cannot extract from.
Encrypted at rest
Transcripts, summaries, memories, and topic links are stored as ciphertext (AES-256-GCM). A leaked database backup is unreadable without your key.
Erased on delete
When you delete your account, your key is destroyed. Your ciphertext becomes permanently undecryptable — even by us.
How it works
Envelope encryption, in plain English.
We use a pattern called envelope encryption. The plain version: every user has a personal key (a DEK — Data Encryption Key). That personal key is itself locked inside a master key that lives in AWS KMS hardware. To read your data, the server has to ask AWS to unlock your key — and every request is logged.
You sign up
A unique encryption key is generated for you and immediately wrapped (locked) by an AWS KMS master key. The wrapped key is stored on your profile. The unwrapped key never touches our database.
You start a session
Our agent asks AWS KMS to unwrap your key — just for this session, in memory only. The unwrapped key is never logged, never written to disk, never sent to a third party.
We encrypt before storing
Every transcript, summary, memory, and emotional note is encrypted with AES-256-GCM and bound to your user ID with authenticated metadata. The ciphertext is what hits the database.
We re-derive on read
Your past sessions are decrypted on demand for you. Each decrypt event is auditable through AWS CloudTrail — including which user, which row, and when.
Coverage
What we encrypt.
The encryption envelope wraps the content you would actually want private. Operational metadata (timestamps, durations, error codes) stays in the clear because it is what keeps the service running.
Encrypted
- Full session transcripts
- Session summaries & insights
- Long-term memories & topics
- People mentioned (HMAC-blinded)
- Emotional snapshots
- Activity content (journals, reframes)
Operational metadata (in the clear)
- • Your account email & ID
- • Session start/end timestamps
- • Session duration & turn count
- • Error codes & uptime metrics
- • Authentication tokens (signed by Supabase)
This is what we need to bill, debug, and keep the lights on. It does not contain conversational content.
Honest scope
What we can and cannot see.
Marketing pages love to say "we can't see your data." The truth is more nuanced — and we'd rather you know exactly where the line is.
What stays sealed
- A leaked database backup is unreadable without AWS KMS.
- Supabase support staff see only ciphertext and wrapped keys.
- A stolen service-role key cannot decrypt rows on its own.
- After account deletion, even we cannot recover your past sessions.
What we're honest about
- During a session, the unwrapped key sits in our agent's memory — that is how voice works in real time.
- Voice processors (LiveKit, Deepgram, Cartesia) handle audio in transit. They are listed in our subprocessor index.
- Vector search (Pinecone) sees embeddings and an opaque ciphertext sidecar — not raw transcripts.
- Operational logs include timestamps and user IDs (not content).
The full threat model — what envelope encryption does and does not defend against — lives in our Trust Center threat model.
Deletion
When you delete your account.
Deletion is the strongest privacy guarantee we offer. It is not a soft archive. It is a one-way operation that mathematically destroys our ability to read your past sessions.
At T+0 (immediately)
Your encryption key is set to NULL in the live database. Encrypted rows are tombstoned. Pinecone vectors are deleted via API. Your in-process key cache is evicted.
After the backup window closes
A background sweep permanently deletes the tombstoned rows from the database. After this, even a Postgres point-in-time restore cannot recover your content — the key needed to decrypt it no longer exists in any backup.
This pattern is called crypto-shredding. By destroying the key first, the ciphertext becomes permanently inert — much faster than waiting for every backup tape to roll over.
For the exact backup window currently in effect, see §6 of the Trust Center (it is read live from our backend configuration).
How we differ
Ophie vs the industry default.
We're not naming names — these are the patterns we see across consumer AI chat apps and most general-purpose assistants. The one row where we lose is the one we won't fudge: external audit. We're committed to it; it hasn't happened yet.
Capability
Per-user encryption key
Industry default
Shared app key, or none
Ophie
Unique DEK per user, wrapped by AWS KMS
Capability
Master key storage
Industry default
App-managed, often a config secret
Ophie
AWS KMS HSM (non-exportable hardware)
Capability
Internal staff access to transcripts
Industry default
Admin viewer or support tooling
Ophie
No internal endpoint; CloudTrail audits every decrypt
Capability
Training AI models on your data
Industry default
Default opt-in, opt-out hidden
Ophie
Never. No training pipeline touches your data
Capability
Account deletion
Industry default
Soft flag, 30–90 day hold
Ophie
Crypto-shred (key destroyed) + hard delete after backup window
Capability
Subprocessor disclosure
Industry default
Buried in legal copy
Ophie
Public subprocessor index at /privacy/subprocessors
Capability
Threat model published
Industry default
Rare; usually NDA-only
Ophie
Open at /trust including disclosed leakage
Capability
External security audit
Industry default
Often present (paid SOC2/ISO)
Ophie
Not yet — committed to roadmap. Self-review log on every encryption PR meanwhile
Spot something we're wrong about? team@ophie.app — we update this table when we're corrected.
FAQ
Common questions.
Is this end-to-end encryption?+
No, and we don't claim it is. End-to-end encryption means the server never holds the unwrapped key. For Ophie to do real-time voice — speech-to-text, an LLM that reasons about your transcript, text-to-speech — the server needs the key in memory during your session.
What we offer instead is per-user envelope encryption with a hardware-backed master key, audited decryption, and crypto-shredding on deletion. It defends against the threats that actually matter for a hosted AI service: leaked backups, vendor-side access, and stolen credentials.
What encryption algorithm do you use?+
AES-256-GCM with Additional Authenticated Data (AAD). The AAD binds each ciphertext to its user ID, table, and column, preventing an attacker from copy-pasting one user's ciphertext onto another's row.
The master key is an AWS KMS Customer-Managed Key with annual automatic rotation enabled.
Can Ophie staff read my sessions?+
Not without leaving an audit trail. Decrypting your data requires asking AWS KMS to unwrap your key, which is logged to AWS CloudTrail with the user ID and operation. The application path that loads your key only runs during your active sessions. There is no internal "read user transcript" endpoint or admin viewer.
What happens if AWS KMS goes down?+
You temporarily cannot start new sessions or read past ones. We chose this trade-off deliberately: no fallback path means no shortcut a future attacker could exploit. AWS KMS has very high availability; if it ever has an outage, the worst case is that Ophie is unavailable until it recovers.
What about the audio itself?+
Audio is transported through LiveKit (DTLS-SRTP) and transcribed by Deepgram. The transcript is what gets encrypted in our database. Audio is not retained by Ophie after the session ends.
Each voice subprocessor operates under its own retention policy, listed in our subprocessor index.
Has this been audited?+
Not yet by an external party. Every encryption-touching pull request goes through a self-review log committed to the repo, and the architecture is documented openly in the Trust Center. External audit is on the roadmap; we will publish results when it happens.
Can I export my data before deleting?+
Yes. Settings → Privacy → Export Data gives you a portable copy of your transcripts and summaries. Run the export before deleting if you want to keep a personal archive — after deletion, recovery is mathematically impossible.
Privacy you can verify, not just trust.
Read the engineering details, audit our architecture, or open an issue if you spot something we should fix.