infoSnap.ai
Security

Your second brain, locked tight.

Trust isn't a marketing line — it's an architecture. Here's exactly how we protect your snaps, what we encrypt, and what's on the roadmap.

Last updated: June 10, 2026

Encrypted everywhere

TLS 1.3 from your device to our servers. AES-256 at rest in Supabase and Azure Blob Storage. Short-lived signed URLs (≤15 min) for every file you preview.

Row-level isolation

Every Supabase table enforces row-level security so a query for "your snaps" can only ever return your snaps — at the database layer, not just the app layer.

No passwords

Sign in with Google OAuth only. We never store, see, or transmit a password — so we can never leak one.

The boring details

How it actually works.

Transport security

All client traffic — browser, mobile app, Chrome extension — is HTTPS-only over TLS 1.3. HSTS preload, modern ciphers, no fallback. Our origin endpoints terminate at Cloudflare's edge with automatic certificate rotation.

Encryption at rest

Database (Supabase Postgres on AWS): AES-256 disk encryption. Object storage (Azure Blob): server-side AES-256 with Microsoft-managed keys. Backups and replicas inherit the same encryption.

Access boundaries

Every Postgres table that holds user data has Row Level Security enabled with owner-policies — meaning a query authenticated as you can only read or write rows where user_id = auth.uid(). Our backend uses a privileged service key today, so RLS acts as a defense-in-depth net. Phase 2 (below) flips this so RLS becomes the primary boundary.

File access

Original files (images, PDFs, audio) never get a public URL. When you open a snap, we mint a short-lived SAS URL — typically 15 minutes — scoped to that single blob. The URL expires on its own; we cache nothing client-side.

Secret management

All third-party API keys (LLM, embeddings, blob storage, Supabase service key) live in Cloudflare Worker Secrets — never in client code, never in git. Rotations are one-command. We periodically audit our git history for accidentally committed secrets.

Identity & sessions

Sign-in is Google OAuth via Supabase Auth. Sessions are short-lived JWTs (≤1h) with refresh tokens rotated on use. We do not operate a username/password system; there is no password database for an attacker to dump.

Roadmap

Where we're going.

We ship security work in phases so you see real improvements every few weeks instead of waiting for one giant rewrite.

Phase 1 · Shipped Stop the obvious leaks

Foundation

Row-level security enabled across every user-data table with owner-policies as a defense-in-depth net. Master key audit. Short-lived signed URLs verified. Public security & privacy disclosures.

Phase 2 · Next Defense in depth

Least privilege + audit

Move read-only endpoints off the master key onto user JWTs (RLS becomes the real boundary). CI check that fails the build if a new table ships without RLS. Append-only audit log. Data export & account deletion in Settings. Per-user rate limits + WAF.

Phase 3 · Premium Per-vault encryption

Your own encryption key

Every Premium user gets a unique encryption key stored in a master key-management service. Each snap is locked with your key before it touches the database. Even a full database compromise can't reveal anyone's snaps. Search, SnapBot, and Recap still work — the Worker briefly unlocks just-in-time.

Phase 4 · Pro Private Mode

Zero-knowledge snaps

Mark a snap as Private and it's encrypted on your device with a passphrase only you know — we receive only ciphertext. True zero-knowledge: subpoena-proof. AI features are local-only on Private snaps; the rest of your vault behaves normally.

Phase 5 · Later Compliance

Third-party assurance

SOC 2 Type II audit, annual third-party penetration test, public status page at status.infosnap.ai, and a bug-bounty program. Unlocked when paying B2B customers ask for it.

Found a bug?

Responsible disclosure.

If you've discovered a vulnerability, please email us at security@infosnap.ai instead of disclosing it publicly. Include reproduction steps and the impact you observed.

We will:

A machine-readable disclosure record is published at /.well-known/security.txt.