Multi-Tenant Security and Data Isolation

Multi-tenant security is the requirement that separates embedded analytics vendors who are built for ISVs from those who added ISV support as an afterthought. It's also the requirement that's hardest to evaluate from a demo — because everything looks secure until it isn't.

This chapter covers what multi-tenant data isolation actually means technically, how to verify it in a trial, and the specific failure modes to watch for. For a deeper technical breakdown of the underlying architectures, see Chapter 4 of the Build vs. Buy guide — that chapter covers shared DB, per-tenant DB, and hybrid architectures in detail.

Enforced Isolation vs. Assumed Isolation

The most important distinction in multi-tenant security is whether isolation is enforced by the platform or assumed to be handled by your application.

Assumed isolation means the platform trusts your application to filter data correctly before it gets to the analytics layer. You pass in a filtered dataset; the platform displays it. If your application passes the wrong data — a misconfigured query, a session token edge case, a cached result from the wrong tenant — the platform has no way to catch it. The security model depends entirely on your application never making a mistake. That's not a security model; it's a hope.

Enforced isolation means the platform itself knows which tenant is making a request and enforces data boundaries at the query level — independent of what your application passes. Even if your application layer has a bug, the platform won't serve Tenant A's data to Tenant B. The security guarantee comes from the platform, not from the correctness of your code.

When evaluating platforms, ask directly: "Where is tenant isolation enforced — in the platform or in my application?" If the answer is "your application is responsible for filtering data before it reaches us," that's assumed isolation. It's not acceptable for a production multi-tenant ISV deployment.

Row-Level Security — UI Filter vs. Query Filter

Row-level security (RLS) means users see only the rows of data they're entitled to. The question is where that filter is applied.

A UI-level filter hides rows from the display but doesn't prevent the underlying query from fetching them. If a user can access the raw data via an export, an API call, or a cached report, they may see rows they shouldn't. UI filtering is not security — it's cosmetic.

A query-level filter applies the restriction in the WHERE clause of the SQL query itself. Only the permitted rows are ever fetched from the database. Export, API, cached result — all of them are filtered at the source. This is what "enforced at the platform layer" means in practice.

Test this during your trial. Build a report with RLS applied to a test user. Then try to access the underlying data via export or direct API call. If rows outside the user's permission appear anywhere, the RLS implementation is UI-level only.

Column-Level Security

Column-level security restricts which fields appear for a given user or role. Finance users see revenue; operations users don't. This needs to work consistently across all report types — including ad-hoc reports that users or tenant admins build themselves, not just pre-built reports your team created.

In a platform with a proper semantic layer, column-level security is configured once in the data model and enforced across every report type. Without a semantic layer, it has to be enforced report-by-report — which means a single misconfigured report exposes data it shouldn't, and there's no systematic way to audit the gap.

Dynamic Data Source Routing

If each of your customers has their own database instance — the cleanest architecture for multi-tenant data isolation — the analytics platform needs to route each query to the correct database at runtime based on the identity of the authenticated user.

This is called dynamic data source routing, and it's not universally supported. Some platforms require you to configure a static list of connection strings at deployment time — one per tenant, manually added. This works at 10 tenants. It becomes an operational burden at 50 and breaks down as an architecture at 200. Customer onboarding requires a manual step in the analytics admin. Offboarding requires cleanup. It doesn't scale.

Dynamic routing means the connection string is resolved at query time from the authenticated user's tenant context — no manual configuration per customer required. New tenant onboarding can be automated via API. The analytics layer never has a static list of tenants that needs to be maintained.

What to Test in Your Trial

Multi-tenant security claims are easy to make and harder to verify. During your trial, run these tests before you consider the evaluation complete:

Cross-tenant data access test. Set up two test tenants with different data. Log in as a user from Tenant A and attempt to access Tenant B's reports or data — directly, via URL manipulation, via the API. The platform should return no data for Tenant B and should not expose that Tenant B exists.

RLS bypass test. Apply row-level security to a test user that restricts them to a subset of records. Then export a report as that user and examine the exported file. If restricted rows appear in the export, RLS is UI-level only.

Dynamic routing test. If your architecture uses per-tenant databases, test that switching tenant context in the authentication token correctly switches the database being queried — without requiring any manual reconfiguration.

Admin escalation test. Confirm that a tenant-level admin cannot access data from other tenants, even using admin API calls. Tenant admin and platform admin should be distinct permission levels.

A vendor confident in their security implementation will encourage you to run these tests. One that redirects to a security whitepaper or suggests these tests aren't necessary is telling you something.