MSSP Scale: Multi-Tenant Isolation Without the Glue
Why multi-tenant isolation must be enforced at the database layer, not the application layer — and what that means for MSSP economics.
The application-filter trap
Many platforms implement multi-tenancy as 'every query has a WHERE org_id = $session.org_id'. It works until a developer forgets. Once a single endpoint forgets, a cross-tenant data leak is one HTTP request away.
Audit-defensible isolation requires that the database itself enforces the scope, not the application code on top of it.
What database-layer scoping looks like
In Threatstealth, every query against telemetry tables is scoped at the data layer. The application cannot accidentally bypass it because the scope is part of the query plan, not the query string.
- Per-org row-level enforcement
- Cross-tenant queries explicitly require an operator role
- All cross-tenant accesses are written to the immutable audit log
- Per-tenant audit trails are retrievable in one click
Why this matters for MSSP economics
If a single client's audit team can't get a clean per-tenant view of their data, your MSSP delivery cycle balloons. If two clients' data ever appears in one report, your delivery model is over.
Per-tenant isolation is not a nice-to-have for MSSPs — it's the product.