The tenant-isolation test: five queries that prove your boundaries
Tenant isolation is provable in minutes, not asserted in meetings. This article gives developers five concrete probes — runnable against their own project with their own keys — where every expected result is stated in advance, so passing or failing is never a matter of interpretation.
It is easy to believe your tenants are isolated because no customer has complained. That belief costs nothing until it's wrong, and when it's wrong it's expensive in the worst currency: someone else's data. The alternative is cheap enough to be embarrassing not to do — five requests, sent by you, against your own project, each with an unambiguous correct outcome. Run them once and you know your boundaries hold today. Wire them into CI and you know they held on every deploy since.
Everything here uses only resources you own: your project URL, your public anon key, and two test accounts you created yourself. Nothing below requires or produces privileged access to anyone else's system — it is the same evidence-gathering the RowShield free scan automates from outside, done by hand.
Why black-box probes at all, when you could read the policies? Because reading verifies intent while probing verifies outcome, and the distance between those is where every incident in this site's catalog lives. Policies are code written by humans and migrations under pressure; requests are truth. A policy review that says "only owners" and a probe that returns Bob's rows are not in disagreement — one of them is wrong, and it has never been the probe. The five tests below are also deliberately cheap: no test framework, no fixtures beyond two accounts, nothing to maintain except attention. Cheap enough that "we should really check that" stops being a reason to skip it.
