Where your data actually goes

Most apps bury this. We publish it: every system KEEEP uses, what it sees, what it can never see, and — honestly — where the risks live. Current as at 5 July 2026; we’ll update this page before any provider changes.

“Military-grade” — what that actually means here

People use that phrase loosely, so here are the checkable facts instead. Your structured data is encrypted at rest with AES-256 — the cipher approved by the US NSA for protecting TOP SECRET information. Every connection uses TLS 1.3 encryption in transit. The Vault and your private wishes can be locked with FIDO2/WebAuthn passkeys — the phishing-resistant login standard governments are mandating for their own agencies. And it runs on AWS Sydney infrastructure assessed for Australian government workloads. Same building blocks; the difference is that we show you exactly where each one is used.

Supabase (database & sign-in) — Sydney, Australia

Holds KEEEP's structured records: people, bills, assets, policies, the audit trail.

What it sees: Your household's structured data, encrypted at rest (AES-256) on AWS in Sydney.
What it can never see: Your documents (those stay in your Drive), your passwords (none exist anywhere in KEEEP).
Why we chose it: Australian data residency, database-level security (every table is walled per household — a bug in our screens still can't cross households), daily backups.
Straight answer on risk: Honest risk: any database can be breached if its keys are stolen. Mitigations: keys are rotated, the powerful service key is never in the app your browser runs, every sensitive action is permanently audit-logged, and the most private layer (your Green Box) is readable by your login only.

Google (sign-in & your own Drive)

You sign in with Google; your documents live in a KEEEP folder inside your own Google Drive.

What it sees: Google already knows you — KEEEP adds only the files it creates in its own folder. We use the narrowest Drive permission Google offers (drive.file): KEEEP can touch only files KEEEP created.
What it can never see: KEEEP cannot browse the rest of your Drive, your Gmail, or your photos. Structurally impossible with the permission we request.
Why we chose it: Custody. Your documents belong to your Google account, not to us — cancel KEEEP and every file is still yours, in your Drive.
Straight answer on risk: Honest risk: your Google account is the front door — protect it with Google's own 2-step verification. If Google had an outage you couldn't open documents until it passed (records in KEEEP still work).

Anthropic (the AI — reading, chatting, web lookups)

Powers the assistant: reads documents you snap, chats with you, and can run small web searches.

What it sees: Only when you use those features: the text of a snapped document, what you type or say to the assistant, a compact summary of your records so it can answer questions, and — when you use a predictive address field — the address fragment you’re typing.
What it can never see: Anything when you're not using AI features. Never your passwords (none exist). Under Anthropic's commercial terms your data is not used to train AI models.
Why we chose it: You approve everything — AI only ever drafts into a review inbox; it cannot write a record by itself. Processing occurs in the United States, disclosed in the privacy notice.
Straight answer on risk: Honest risk: any AI provider could in theory be breached while processing text. That's why AI reading is opt-in per use, why identity document images stay in your Drive, and why web lookups send only your search question — never your household summary.

Vercel (hosting)

Runs the KEEEP application and serves every page over encrypted connections (TLS 1.3).

What it sees: Requests passing through, briefly, in memory — the same as any host.
What it can never see: It keeps no database of your content.
Why we chose it: Enterprise-grade edge hosting with deploy isolation; we can ship security fixes to every user in under a minute.
Straight answer on risk: Honest risk: hosting compromise is the classic web risk — mitigated by encrypted transport, secrets kept in a sealed environment (never in code), and no long-term data stored at this layer.

Documenso (e-signatures, beta agreements)

Sends the beta participation agreement for signing.

What it sees: The agreement PDF and the signer's name and email.
What it can never see: Any household record — it's connected to nothing else.
Why we chose it: Open-source e-sign; the narrowest possible job.
Straight answer on risk: Honest risk: minimal by design — the only data at this provider is a document you intended to sign.

Resend (email notifications)

Sends KEEEP's notification emails — starting with alerts to the KEEEP team when a support question needs a human.

What it sees: The recipient's email address and the notice text — which we keep deliberately content-free ("a support question needs you" plus a link; never the question itself, never household data).
What it can never see: Any household record. It's a one-way outbox connected to nothing else.
Why we chose it: Beta support should be fast — an unseen question is a bad week for a tester. One provider, added once, will later carry invitations and Green Box verification notices under the same content-minimal rule.
Straight answer on risk: Honest risk: any email provider can see what passes through it — which is exactly why our notices carry no substance. The details stay behind your login.

Your device (voice, Face ID / fingerprint)

Voice chat and the passkey locks on the Vault, intentions and exports.

What it sees: Everything — it's your device. Voice is transcribed BY the device or its operating system; audio is never uploaded to KEEEP. Your face and fingerprint are checked by the device itself.
What it can never see: — KEEEP receives only the transcribed text of what you said, and a cryptographic yes/no from a passkey check. No recording, no biometric ever reaches our servers. Nothing biometric exists for us to leak.
Why we chose it: Passkeys (FIDO2/WebAuthn) are the phishing-resistant sign-in standard governments are mandating for their own agencies — a stolen recording or photo cannot pass one.
Straight answer on risk: Honest risk: a device someone else can unlock is a device that can open your KEEEP. Use a device passcode, and remove a lost device's passkey from Settings.

Referral partners (only when you ask)

If you ask KEEEP for an introduction to a professional (a broker, lawyer, accountant), the named partner you approve receives a one-off pack.

What it sees: Only the sections you tick, once, after you've seen their name, their business and — in plain words — whether KEEEP is paid for the introduction.
What it can never see: Anything you don't tick. There is no standing feed, no list-selling, and a partner never gains login access. Introductions never happen unprompted — the assistant may offer once when you say you need someone, and that's it.
Why we chose it: Your fact-find shouldn't need retyping at every professional's desk. This is the same one-way export you already control, pointed at a vetted, named human.
Straight answer on risk: Honest risk: once any professional holds your pack, it's governed by their obligations, not KEEEP's systems — true of any document you hand anyone. Every introduction is recorded permanently in your audit trail, including exactly what was shared.

KEEEP itself

The application, and the people who run it.

What it sees: Operationally: aggregate counts and system health (households, pending queues) — the operator console is built so household content never appears in it. With your explicit, revocable consent during beta support, a named operator can be granted temporary access you can see and end.
What it can never see: Your Green Box and intentions (readable by your login alone — enforced by the database, not by promise). Your Drive beyond KEEEP's own folder. Any password, PIN or seed phrase — KEEEP refuses to store them, so they cannot leak from us.
Why we chose it: The audit trail is append-only and immutable — nobody, including us, can edit or erase the record of what was done.
Straight answer on risk: Honest risk: every company says 'trust us'; we'd rather show the design. This page publishes the whole map — the security doesn't depend on secrecy (in cryptography that's called Kerckhoffs's principle). What protects you is encryption, database walls, passkeys and audit — all of which stay true even with the blueprint public.

This page is a plain-English summary, not the legal privacy notice — the full notice at keepwiz.com/privacy prevails, and all legal text is draft pending professional legal review while KEEEP is in beta. Found a hole in our thinking? Tell us — that’s what beta is for: aarongreffenius@gmail.com.