Multi-Tenant Permission Isolation in AI/BI Dashboards: A Practical Guide

Introduction

In enterprise AI/BI applications, embedded dashboards have become a standard feature. Technically speaking, embedding a dashboard into an application isn't particularly difficult — the real challenge lies in ensuring that every viewer can only access the data they're authorized to see. This problem is especially pronounced in multi-tenant scenarios, where you need to serve external partners, support internal teams across different departments, and avoid maintaining separate dashboard copies for each customer or team.

This article explains how to use a single dashboard to securely serve all user groups through fine-grained permission controls. The core of this approach is decoupling access control logic from the data presentation layer, achieving true data isolation through multiple layers of security.

Core Architecture: Centralized Permission Management

The foundation of this approach is a Centralized Entitlements Table. Unlike the traditional approach of hardcoding permission rules at the application layer, this design stores all users' data access permissions in a structured format within the database. The benefits are clear: permission changes take effect immediately by simply updating the entitlements table — no code modifications or dashboard redeployments required.

The entitlements table typically contains fields such as user identifiers, accessible data scopes (e.g., specific customer IDs or department codes), and access levels. When a user requests to view a dashboard, the system first queries this table, dynamically constructs data filter conditions for that user, and ensures query results are strictly limited to the authorized scope.

External User Isolation: The __aibi_external_value Mechanism

For external partners or customers, this approach introduces a key technical feature: the __aibi_external_value parameter. This is a context variable dynamically injected at query execution time to identify the current viewer's identity or organization.

In practice, when external user A logs in and accesses the dashboard, the system sets __aibi_external_value to user A's customer ID. The underlying dashboard query automatically references this variable — for example: WHERE customer_id = __aibi_external_value. This way, even though all external users see the same dashboard interface, tenant isolation is automatically enforced at the data query level.

The advantages of this approach include:

• Single data source: All customer data is stored in the same database, simplifying data management
• Zero maintenance overhead: Adding new customers requires no new dashboards — just an entry in the entitlements table
• Dynamic scope control: The data range visible to each customer can be adjusted flexibly

Internal Team Access: Group-Based Permission Model

For internal users, this approach adopts a Group-based Access permission model, which aligns naturally with enterprise organizational structures — sales teams, finance departments, executives, and other roles each need to see data at different dimensions and levels of granularity.

Internal users inherit data access permissions through their assigned user groups. For example, the sales team group might be authorized to view sales data across all customers, while the finance group can only see finance-related metrics. By maintaining group-to-data-scope mappings in the entitlements table, the system automatically applies the appropriate filter rules when users log in.

This design also supports scenarios where a user belongs to multiple groups. The system merges the permissions from all groups, taking their union as the final access scope.

Defense in Depth: Row-Level Security and Column Masking

Beyond filtering at the query layer, this approach also implements database-level security measures:

Row-Level Security (RLS): Security policies are defined directly in the database. Even if someone bypasses the application layer and executes SQL queries directly, they are still subject to RLS policies. The database automatically appends WHERE conditions to every query, ensuring users can only read the data rows they're authorized to access.

Column Masking: For sensitive fields (such as personally identifiable information or financial details), the system can dynamically decide — based on user role — whether to display the original value, a masked value, or hide it entirely. For example, a frontline employee might see a customer's phone number as 138****5678, while an account manager sees the full number.

The Default-Deny Principle

The most critical principle in this security architecture is Default-Deny. The approach ensures:

• If a user is not explicitly authorized in the entitlements table, they see no data at all
• Newly added tables or fields are invisible to all users by default until access rules are explicitly configured
• Even in the event of a misconfiguration, the system errs on the side of over-protection rather than over-exposure

This design philosophy significantly reduces the risk of data leakage.

Preventing Direct SQL Connection Bypasses

An often-overlooked security vulnerability is the possibility of technically savvy users connecting directly to the database via a database client, bypassing all application-layer permission checks. This approach specifically addresses protection against such scenarios.

By enforcing RLS and view-layer security policies at the database level, even if a user possesses database connection credentials, their queries are subject to the same permission constraints as the dashboard. The database automatically identifies the current connection's user identity and applies the corresponding security policies, ensuring there are no permission gaps.

Practical Value and Use Cases

This approach is especially well-suited for the following scenarios:

1. SaaS platforms: Delivering independent data views to hundreds or thousands of customers without maintaining thousands of separate dashboards
2. Partner portals: Allowing channel partners and suppliers to view real-time business data relevant to their own operations
3. Enterprise internal analytics: Enabling employees across different departments and organizational levels to use the same BI tool while strictly enforcing data access boundaries

Compared to the traditional approach of duplicating dashboards for each tenant, a single-dashboard-plus-dynamic-permissions architecture significantly reduces maintenance costs, improves permission management flexibility, and maintains full data security.

Conclusion

In the AI/BI era, democratizing data insights and ensuring data security are not contradictory goals. Through the combined use of centralized permission management, dynamic context injection, multi-layer security controls, and the default-deny principle, organizations can securely serve all user groups from a single unified dashboard. This not only simplifies the technical architecture but also makes permission management more transparent and controllable. For teams building multi-tenant BI systems, this set of practices is well worth studying and adopting.