Legal
Last updated September 2026.
Every table that holds customer data enforces row-level security in Postgres, scoped to organisation membership, in addition to checks the application itself performs. One customer's data is not reachable through another customer's session, even if a bug in application code got the check wrong — the database is the actual backstop, not just the app.
Authentication runs through Supabase Auth (email/password or Google sign-in). Within an organisation, owner, admin and member roles govern who can change settings, run checks or delete a brand. Shared report links are permission-scoped and revocable, never open by default.
AI provider API keys and the database's privileged service-role key are held server-side only and are never sent to the browser. Data at rest is encrypted, a standard part of the managed Postgres infrastructure we run on. Connections between your browser and the app are encrypted in transit.
Plainly: no formal certification (e.g. SOC 2) exists for this product yet, there is no scheduled third-party penetration testing program, and there's no dedicated incident-response runbook beyond the engineering team handling issues directly. If that's a blocker for your organisation, tell us — it's useful to know what to prioritise.
Found a security issue? Tell us with enough detail to reproduce it. We'll acknowledge and work on a fix; please don't access or modify data that isn't yours while investigating.
This page describes measures actually in place today. It has not been reviewed by a dedicated security function and is not a compliance attestation of any kind.