Tenant isolation for customer-facing analytics
Customer-facing analytics is only trustworthy when every chart, saved view, and generated query is scoped to the right tenant. Tenant isolation cannot depend on a dashboard filter the customer can misunderstand or a frontend value the server never verifies.
Must protect
All customer-specific rows, metrics, saved dashboards, and AI-generated SQL.
Weak pattern
Frontend-only filters or user-editable dashboard parameters.
Stronger pattern
Server-side identity, tenant context, scoped generation, and validation.
Principle
Tenant isolation starts before the SQL runs
Safe analytics begins with verified identity and tenant context. Query generation, saved chart execution, and dashboard rendering should all receive the same tenant boundary.
- JWT claims should be verified server-side.
- Generated SQL should include tenant context by design.
- Admin previews should make tenant scope visible before publishing.
Failure modes
Common ways analytics leaks happen
Leaks often come from treating analytics like a display feature instead of an authorization surface. Filters can be omitted, saved charts can drift, and AI-generated SQL can target a broader slice unless the system is designed around tenancy.
QueryPanel approach
Tenant-aware generation plus review
QueryPanel carries tenant context into the generation path and keeps customer-facing rationale client-safe by default. Teams can still use admin review workflows and debug mode when they need engineering-level visibility.
FAQ
What is tenant isolation in analytics?
Tenant isolation means each customer can only query, view, and save analytics based on data they are authorized to access.
Are dashboard filters enough for tenant isolation?
No. Dashboard filters can help UX, but tenant authorization should be enforced through server-side identity, scoped query generation, database permissions, or another trusted backend control.