A flat tenant_id forces the three workarounds that ship cross-tenant leaks

Three of the decisions the post spells out share a deadline of day one: what a tenant is, how deep the hierarchy goes, and where tenant identity comes from ^[4][5][8]. Isolation enforcement is the one with a later date, the first paying customer ^[15]. That deferral is priced. Moving later means "auditing every query you have ever written, and you will not find them all", the post's author wrote ^[15]. The hierarchy works the same way: adding a level later means rewriting every query you have, so the advice is to pick organisation -> workspace -> user and use one level of it for a year ^[5].

The identity decision is the one the post calls the most productive source of real vulnerabilities ^[6]. Tenant scope can come from a subdomain, a signed JWT claim, a session lookup, or an org_id in the request body that the caller supplies ^[6]. "An isolation layer that cannot omit tenant scope is worth nothing if the scope it cannot omit was chosen by the attacker," the author wrote. The same goes for row-level security keyed on a claim the API populates from user input, the author added ^[7]. So the storage tier does not rescue you here. The rule offered is that identity comes from exactly one place, server-derived, with no request field able to override it. The follow-up advice is to grep for the places that do it differently, because there will be some ^[8]. In my view this is the cheapest item to act on this week, because it is greppable and the answer is binary.

The isolation options have different costs. The application-level WHERE clause is fast to build and fails the first time one developer on one endpoint forgets, silently, returning 200 with too many rows ^[10]. Database enforcement is stronger because forgetting stops being possible. Each form costs the operator work: RLS is its own skill and can be subtly wrong, schema-per-tenant turns migrations into an operational project, and database-per-tenant makes cross-tenant analytics and connection pooling hard at a few hundred tenants ^[11]. The shared middleware producer writes the scope once instead of at forty call sites. That removes the per-endpoint mistake, the post says, but it does not make the boundary unforgettable the way a database refusing a query does ^[13].

Then the author applies the leak test to Supero and reports it does not pass cleanly. Admin roles have documented exemptions. A user left in the platform's default-tenant gets project-wide read, and a request arriving with no session context returns allow, a branch the post says is unreachable today only because authentication runs first ^[17]. The score given is "a developer cannot leak by forgetting, and can leak by being provisioned wrong" ^[18]. The post also tells readers to ask any vendor selling this design, "us included", whether the producer has bypass branches and what stops a new call site from skipping it entirely ^[14].

This is one practitioner's checklist with a vendor disclosure attached ^[19]. It cites no incident data for the claim that the fake-account, application-join and session-hack workarounds are how leaks actually ship ^[3]. What transfers regardless of stack is the test, and it costs an afternoon. Ask a developer to write an endpoint that leaks across tenants. If nothing stops them but their own care, their care is your isolation model ^[16]. Note also that the post refuses to treat database-per-tenant as a separate decision at all, calling it the physical tier of the same isolation choice ^[12].