Service Credentials and Row Level Security Bypass Risk

The full executive answer

You've identified the real crown jewel, and I won't minimise it: the Supabase service-role key can read across tenants, which is why it gets a different defensive treatment than everything else. Containment first: that key exists only as a server-side environment variable in Vercel's encrypted configuration — it is never in the repository (gitleaks scans every commit to enforce that), never in client-side code (our convention splits public from server-only secrets by naming, so accidentally shipping it to a browser is structurally hard), and never logged (the logger masks secrets and personal data by design).

Second, we constrain what the key can do even in legitimate use. Every code path using the service client must scope its queries to a single organisation, and that isn't a guideline — the cross-tenant-gate CI test fails the build if any new service-role query on a tenant table lacks organisation scoping, with the handful of reviewed parent-scoped exceptions pinned in a ratchet list that can only shrink. So an attacker who compromised our codebase couldn't quietly add a cross-tenant query; the build itself would refuse. Third, the most sensitive stored fields have an additional envelope: AES-GCM field-level encryption with keys managed by AWS KMS, meaning database access alone doesn't yield those plaintexts — the attacker would also need our KMS permissions.

If it leaked anyway: the key is rotatable in minutes through Supabase with zero customer action, every access is in the append-only, hash-chained audit trail for forensics, and our incident process (with jurisdiction-aware notification deadlines built into the product's own incident module) governs disclosure. The honest residual risk: a fully compromised production environment with both the database key and KMS access is game over for confidentiality — true of every SaaS on earth — and the mitigations there are the small set of humans with production access, MFA on those accounts, and the audit trail that makes access non-deniable. Formal secret-rotation scheduling and privileged-access reviews are being codified in the SOC 2 readiness work, Q4 2026.