Technical Security Details

When you connect an inbox — Gmail, Outlook, Yahoo, iCloud, or another provider — you're granting a read-only permission (for Gmail specifically, Google calls it gmail.readonly; other providers have their own equivalent). This isn't just a promise in our privacy policy — your provider's own permission system makes it technically impossible for BlindSpot to send, delete, label, archive, or edit anything in your mailbox. We only ever look at mail you've already sent, to spot commitments you've made.

The other three channels are all opt-in, one-time actions you take, not standing access we hold: a photo you snap or upload is read once for its text and discarded (see section 2), a text you forward arrives through Twilio to your dedicated BlindSpot number, and anything you type in is exactly what it looks like — text you wrote, submitted directly. None of these give BlindSpot any access beyond the specific thing you sent it.

We do not store your full emails, the photos you send, or full text-message threads.

When something — an email, a forwarded text, a photo, or a typed note — looks like a commitment, we save:

• A short title and summary (written by the classifier, not copied from your original message)
• A short reference excerpt of the original text
• Any reusable key info the classifier pulled out — a phone number, a payment link, an address — so it's on the card later without you having to re-read the original
• Who it involves, when it's due, and its status (open, done, dismissed, etc.)

A photo itself is never stored — it's processed in memory for its text and discarded immediately after. The rest of an email, or a text thread, that we didn't flag is never copied anywhere either. We only ever read what's needed to check for a commitment, in the moment we check it.

Two more limits on the stored excerpt/key-info text specifically: a best-effort filter strips obvious sensitive data (things that look like account numbers, IDs, or credentials) before it's ever saved — it catches common patterns, not everything, so it's one layer, not a guarantee. And once a commitment has been resolved for 90 days, the verbatim excerpt is cleared automatically — the title, summary, key info, and status stay (that's the actual point of the app), but the original source text doesn't sit around indefinitely.

• In transit: every connection this app makes — to your browser, to your email provider, and to every other service it talks to — runs over HTTPS/TLS.
• Everything at rest: our infrastructure providers encrypt the underlying disks by default, on encrypted cloud infrastructure. Row-level security also means the database itself physically refuses to return another account's rows (see section 4) — that isolation applies today, independent of encryption.
• An extra, application-level layer on top of the above, live today: mailbox connection credentials (OAuth tokens, or an app-specific password for IMAP providers) are encrypted with their own key (AES-256-GCM) before they're ever written to the database. Separately, the commitment text we store — the summary detail, the reference excerpt, and any extracted key info — is encrypted at the database layer itself via an insert/update trigger, so it's ciphertext at rest regardless of which part of the app wrote it. Both layers sit on top of, not instead of, the disk-level encryption above.

This isn't just an app-level check we could get wrong — it's enforced at the database itself via row-level security (RLS). Every account's commitments are tagged with that account's ID, and the database is configured to refuse to return rows that don't belong to whoever's logged in, so a bug in the application code alone can't leak your data to another account — the database is the thing saying no. That said, RLS is only as good as the policies configured on each table; we hold ourselves to enabling it correctly on every table that holds account-scoped data, and treat any gap found in that as a priority fix, not a footnote.

Every party that sees any of your data, and exactly what each one sees:

• Your email provider (Gmail, Outlook, Yahoo, iCloud, or whichever you connect) — to read the mail you've authorized, nothing more.
• OpenAI — receives the text of a flagged email momentarily, to classify it as a commitment. Not used to train any model, sold, or shared onward.
• Supabase — hosts BlindSpot's database and handles sign-in. It's where everything above actually lives.
• Twilio — has two distinct roles, not just one: it's the carrier behind your dedicated BlindSpot number, so a text you choose to forward passes through it on its way in; separately, it can deliver outbound SMS alerts. Neither role gives it access to your email — inbound, it only ever sees what you send it; outbound, only what's already been classified and stored (a title, a counterparty name, a risk level).
• OneSignal and Resend — deliver push notification and email alerts respectively, only when a commitment genuinely needs your attention. What they receive is limited to what's already been classified and stored — never the original email content.
• Zapier — runs a small number of scheduled checks (a daily mailbox-silence check, a weekly reliability recap, and two rare "you might be missing this" nudges) that read already-classified commitment data from our database to decide whether to trigger one of the alerts above. It does not see your raw email — the older setup that routed mail content directly through Zapier was retired 2026-08-05 in favor of the direct mailbox connections described in section 1.

No ad networks. No data brokers. Nothing is sold, ever.

One mailbox: Settings → the mailbox's own disconnect control. BlindSpot stops reading it immediately — the underlying OAuth connection (or, for IMAP, the stored app-password) is deleted server-side, not just hidden in the UI. Commitments already captured from it stay in your list; reconnecting later is a normal new connection, not a restore.

Everything: Settings → "Delete my account." Type DELETE to confirm, and in one step it removes every commitment, disconnects every mailbox, and deletes your login — no one on our side has to do it by hand.

Worth being direct about the account-deletion path: it's immediate and permanent. There's no grace period and no way to undo it once you've confirmed. If you're not certain, don't type DELETE yet — ask first.