Security
The details matter when the stakes are this high.
This page is the long version. If you’re weighing whether to trust us with sensitive information, we owe you specifics — not slogans.
How we protect your data
Encrypted in the application layer
Every credential value — passwords, PINs, login answers — is encrypted with AES-256-GCM in our application before it ever hits the database. The key lives in a Vercel environment secret, separate from the database credentials. That means a database leak alone would not reveal your credentials.
Encrypted at rest
On top of application-layer encryption, Supabase encrypts the entire database at rest. Two independent layers between your data and a curious attacker.
Encrypted in transit
TLS everywhere: Cloudflare to Vercel is set to Full (Strict), not Flexible. Connections between services inside our stack are TLS-terminated at each hop.
Private documents, signed retrieval
Uploaded documents go into a private Supabase Storage bucket. They are never served by a public URL — each retrieval generates a short-lived, signed link scoped to the current user.
Row-level security
Access rules are enforced in the database itself, not just in the application. A bug in our code cannot accidentally expose one user’s data to another — the database would refuse the query.
Executors see nothing until unlock
Until an unlock request is initiated and approved, the person you name as executor cannot see any of your stored data. Their account exists, but the policies simply do not return rows.
About the AI companion
What the companion can and cannot see.
We built the companion to be genuinely helpful without ever needing to look at your sensitive data. Every request to the language model is stripped of anything that could identify a person, institution, or account.
What it sees
- Whether each of the four sections is complete.
- How many items exist in each section (counts only).
- When a section was last updated (timestamps).
- Whether your plan is live, and whether your executor has acknowledged.
- Your chosen handoff delay setting.
What it never sees
- Passwords, PINs, or any credential value — encrypted or decrypted.
- Names of banks, brokerages, email providers, or any institution.
- Names of your executor, witness, or anyone you’ve added.
- The contents of any document you’ve uploaded.
- Account numbers, even partial ones.
Access controls you own
You decide when, and how, anything opens.
Waiting window
Set anywhere from zero to seventy-two hours. Access only opens once the window passes without a denial from you.
One-click deny
The moment an unlock is requested, you receive an email with a deny link. Clicking it cancels the unlock and revokes the executor role immediately.
Witness override
Name a witness and time delays go away — access only unlocks when the witness confirms in-app. You retain a deny option until that confirmation happens.
Soft deletes, audit trail
We never hard-delete a person, document, or access record. Revocations and deletions are marked with a timestamp so the history is always recoverable.
Honest tradeoffs
What we’re not (yet).
We believe you should know where the edges are.
- Afterword is not zero-knowledge. Our servers can decrypt your credentials in order to show them to your executor after an approved unlock. Zero-knowledge was considered and rejected for this version because it would block the core feature — showing the executor the data on day one.
- We do not hold a SOC 2 report yet. We are operating above the controls that framework requires, but we have not completed a formal audit.
- We do not yet enforce MFA on every account. It is strongly encouraged on sign-up and will become mandatory as we move out of early access.
Found something concerning?
Email us directly. Responsible disclosure is welcome and appreciated.
Email the team