How Voltx enforces tenant isolation at the database layer

Multi-tenancy bugs are rarely dramatic. They're a missing `WHERE organizationId = ?` clause in one query, out of the hundreds a real application accumulates, that quietly returns one customer's data to another. Code review catches most of them. It doesn't catch all of them, and in a multi-tenant SaaS product, 'most' isn't the bar.

Voltx's approach is to treat tenant scoping as an ORM-level guarantee rather than a per-query discipline. Every request that reaches the API resolves a tenant context — organization, user, and request ID — into an async-local-storage-backed context service before any route handler runs. That context is then read by a Prisma Client Extension that intercepts every query against tenant-scoped models and injects the organization scope automatically.

The result is defense in depth: even if a service method forgets to filter by organization explicitly, the extension still narrows the query at the ORM layer. It's not a replacement for careful application code — it's a second, independent enforcement point that fails closed rather than open.

This same tenant context also powers our guard composition for protected routes: a JWT auth guard validates the bearer token, a user-context guard resolves membership and RBAC permissions, and a tenant guard cross-checks that the resolved organization actually matches what the token claims. Three checks, each independently simple to verify, composed into something much harder to get wrong than one guard trying to do all three jobs at once.

We wrote more about the specific isolation guarantees this gives enterprise customers on our Enterprise page, including how it interacts with SCIM provisioning and audit logging.