You host every customer's board-level secrets in one database. Prove to me that tenant A cannot read tenant B's data. Has anyone actually tried to break that boundary?

The full executive answer

On every request, isolation is enforced by our application filtering each query to the organisation identified in your cryptographically verified login token — and it does not rest on anyone remembering to: an automated cross-tenant test fails the build if a tenant-table read ships without that filter. Every table that holds customer data carries the owning organisation's ID, and Postgres Row Level Security — a database-engine feature, think of it as a second lock built into the storage layer — is enabled on every one of those tables, so anything that reaches the database directly rather than through our application cannot read another organisation's rows. The organisation ID is derived server-side from the verified Clerk session token — it is never read from the request a user sends, so it cannot be spoofed by editing a URL or an API call.

Now the part most vendors can't say: we made "forgetting isolation" a build failure. A static test in our CI pipeline scans every database migration and fails the entire build if any tenant table is created without Row Level Security enabled. A second gate covers the privileged service path — the admin credential that bypasses RLS — by failing the build if any new query on a tenant table isn't explicitly scoped to one organisation. And the authorization policy layer re-checks the tenant boundary as an explicit deny rule before roles are even evaluated. So there are three independent layers, and two of them are enforced by machines on every single commit, forever.

Has anyone tried to break it? Honestly: our own automated adversarial tests try on every build, and file storage is isolated the same way (per-organisation path prefixes set by application code, with storage row-level security as a second line, download links that expire in 30 minutes) — but no independent third party has attempted it yet, because we have not commissioned an external penetration test. That is a named gap on our security roadmap: we plan to commission a penetration test from a CREST-accredited firm alongside our first enterprise pilot, targeted Q4 2026, and we would welcome your security team performing their own testing against a dedicated tenant as part of evaluation. I'd rather show you the CI gates today and the pen-test report in two quarters than pretend the report already exists.