A multi-tenant platform must guarantee that one customer can never see another's data. Where should that check live, and what makes the guarantee credible?

Where the check must live

As close to the data as possible, and enforced by something other than the code that intends to be correct.

Application-level filtering — every query including a tenant clause — is necessary and insufficient. It depends on every developer remembering, on every code path, forever. The one query that forgets is a cross-tenant data breach, and code review does not reliably catch it.

The layers that make it credible

• Row-level security in the database, enforced by the engine rather than by the query. A missing tenant clause returns nothing instead of returning everything, which converts the most dangerous possible bug into a visible one.
• A tenant context established at the edge and propagated through the request, including into asynchronous work. Background jobs are where tenant context is most often lost, and background jobs frequently have broad data access.
• Separate credentials or connections per tenant where the architecture permits, so the database connection itself cannot see other tenants.
• Physical separation for the largest tenants, which converts the guarantee from a logical one to a deployment one — and is frequently what enterprise customers are actually asking for.
• Automated tests that attempt cross-tenant access on every build, treating isolation as a fitness function rather than as a practice.

What makes the guarantee credible to a customer

Not the architecture description. Evidence: penetration test results, the automated isolation tests, audit logs showing access attempts and their outcomes, and — for the largest customers — a deployment model where the isolation is physical and therefore verifiable.

The failure mode that recurs

Aggregate and administrative paths. The per-tenant read path is usually well protected because it was designed with tenancy in mind. The internal dashboard, the support tool, the analytics job and the data export are written by people solving a different problem, and they routinely have unrestricted access.

Those paths need the same enforcement plus their own audit trail, because they are also the paths an insider threat uses — and an access model that is rigorous for customers and permissive for staff is protecting against the wrong adversary.