Security Guide for AI/BI Dashboard Embedding: Multi-Tenant Data Isolation and Access Control in Practice

Introduction: The Security Challenge Beyond Embedding

Embedding Databricks AI/BI dashboards into customer-facing applications isn't technically complex in itself. Databricks AI/BI Dashboards are native business intelligence visualization tools built on the Databricks Lakehouse platform, supporting no-code/low-code creation of interactive reports and data dashboards. Unlike traditional BI tools (such as Tableau or Power BI), they run directly on top of the Lakehouse architecture, with queries hitting data in Delta Lake directly — no additional data migration or replica creation required. The embedding feature allows developers to integrate dashboards into third-party web applications via iframes or SDKs, enabling end users to view data visualizations without logging into Databricks. With just a few steps, developers can present feature-rich data visualization interfaces to end users. However, the real challenge isn't "how to embed" but rather "how to ensure each viewer can only see the data they're authorized to access."

In multi-tenant SaaS scenarios, thousands of customers may share the same underlying data platform. Multi-tenancy is a cornerstone pattern of modern SaaS architecture, where multiple customers (tenants) share the same software instance and underlying infrastructure while their data and configurations remain logically isolated from one another. This architecture dramatically reduces operational costs and resource consumption, but it also shifts the responsibility for data isolation from the physical layer to the logical layer. With the implementation of data protection regulations like GDPR and CCPA in recent years, unauthorized data access in multi-tenant environments is no longer merely a technical issue — it can trigger massive fines and legal action. If security boundaries are poorly designed, one customer could potentially peek at another customer's sensitive business data — this isn't just a technical failure but a serious compliance and trust crisis. This article takes a deep dive into how to build a per-viewer security framework for AI/BI dashboard embedding scenarios.

Core Challenge: From "Can Embed" to "Securely Embed"

Embedding Is Easy — Data Isolation Is What Matters

Embedding a Databricks AI/BI dashboard is "relatively straightforward," but when an application needs to serve a large number of users with different permissions, security concerns quickly emerge.

Consider a typical scenario: a data analytics SaaS provider offers business insight dashboards to hundreds of enterprise clients. Each client should only see their own sales, operations, and financial data. If you rely solely on front-end UI hiding or simple application-layer filtering, attackers can easily bypass these restrictions by tampering with request parameters or directly accessing APIs to retrieve data they shouldn't see.

Therefore, the core security objective is to achieve fine-grained isolation at the row and column level, pushing isolation mechanisms down to the data platform layer rather than leaving them at the application surface.

Three Permission Isolation Models in Multi-Tenant Environments

In multi-tenant architectures, access control typically follows one of these patterns:

• Separate Database/Schema Isolation: Each tenant has its own dedicated data storage space. This provides the strongest isolation but comes with higher operational costs. This model is common in industries with extremely strict compliance requirements (such as finance and healthcare), but as the number of tenants grows, the management overhead and resource costs of database instances scale linearly or even super-linearly.
• Shared Tables + Tenant ID Filtering: All tenant data resides in the same tables, distinguished by fields like tenant_id. This is cost-effective but places extremely high demands on filtering logic. If a filter condition is missed in any query path, cross-tenant data leakage occurs.
• Row-Level Security (RLS): Access policies are defined at the data platform level, automatically filtering visible rows based on the current user's identity. The core idea behind RLS is automatically injecting filter conditions into the query execution engine so that each user can only see the data rows they're authorized to access. Compared to application-layer filtering, RLS takes effect at the SQL execution plan level — meaning even if a user bypasses application logic and executes SQL queries directly, they cannot break through the row-level filtering constraints. In Databricks, RLS is typically implemented through Row Filter functions — administrators bind a filter function to a table that receives the current user's session context and returns a boolean value, and the database engine automatically applies this filter on every query. This mechanism is completely transparent to upper-layer applications and requires no modifications to any query statements.

For AI/BI dashboard embedding scenarios, row-level security is often the optimal choice, balancing cost efficiency with security strength.

Solution: Building an End-to-End Embedding Security Chain

Identity Propagation and Embedding Token Management

The first step in achieving per-viewer data isolation is to reliably propagate the end user's identity to the data platform. The common approach is for the application backend to include verified user identity information or tenant identifiers when generating embedding tokens.

An embedding token is a short-lived credential generated on the server side, typically based on JWT (JSON Web Token) or similar standards. The core principle works as follows: when a user initiates a dashboard viewing request, the application backend sends a token issuance request to the Databricks API, encoding the user's identity identifier, tenant ID, permission scope, and other claims into the token with a short expiration time (typically ranging from a few minutes to tens of minutes). The frontend uses the received token to initialize the embedding component, and the Databricks platform parses the identity information in the token upon receiving requests and performs permission validation accordingly. This mechanism ensures that identity assertions are made by a trusted server side, and the frontend cannot forge or tamper with permission claims.

There's an ironclad rule here: identity propagation must occur on the trusted server side — never let the frontend or user-controllable parameters determine data access scope. Any filtering logic exposed on the client side should be considered untrusted.

Leveraging Databricks Unity Catalog for Platform-Level Security

Modern data platforms like Databricks provide data governance tools such as Unity Catalog, supporting fine-grained access policy definitions at the data asset level. Unity Catalog, officially launched by Databricks in 2022, is a unified data governance layer that provides centralized metadata management, access control, and auditing capabilities for all data assets in the Lakehouse (tables, views, models, files, etc.). It adopts a three-level namespace structure (Catalog → Schema → Table) and supports an ANSI SQL-standard GRANT/REVOKE permission model.

For row-level security, Unity Catalog supports implementation through Dynamic Views or row-level filter functions — developers can define a SQL function that dynamically determines which rows are visible to the current user based on identity information from current_user() or session variables. Column-level security is achieved through Column Masking, which can desensitize or hide sensitive fields. All access behaviors are recorded in audit logs for compliance review and security traceability.

Once security policies are bound to user identities, the underlying platform automatically enforces consistent permission validation regardless of how users access data. This approach of "pushing security forward to the data governance layer" offers stronger consistency and defense depth compared to building layer after layer of defenses at the application level. Even if vulnerabilities appear at the application layer, the data platform remains the last robust line of defense.

Architecture Design: Security Should Be Built In, Not Bolted On

A Three-Layer Defense-in-Depth Protection System

A robust embedded dashboard security system should follow the Defense in Depth principle, establishing multiple layers of protection from the outside in. Defense in Depth is an information security theory originating from military strategy, promoted for cybersecurity applications by the U.S. National Security Agency (NSA). Its core concept is: never rely on any single security mechanism, but instead deploy multiple independent protective measures at different system layers so that even if an attacker breaches one layer, they still face barriers at subsequent layers. This principle also aligns closely with the Zero Trust security model — never trust by default, always verify.

Applied specifically to embedded dashboard scenarios, the three-layer protection system works as follows:

1. Application Layer: Validates user login status and session validity to ensure request legitimacy. This layer typically relies on standard authentication protocols like OAuth 2.0 and OpenID Connect, combined with CSRF protection and request origin validation, to prevent unauthorized access requests from entering the system.
2. Token Layer: Generates short-lived embedding tokens bound to user identity on the backend, preventing token theft or misuse. The short lifecycle design ensures that even if a token is intercepted, the attack window is extremely limited; meanwhile, identity claims encoded in the token are signed by the server to guarantee they cannot be tampered with.
3. Data Layer: Enforces data isolation through Row-Level Security (RLS) and column-level security policies, eliminating unauthorized access at the source. This is the most critical link in the entire security chain because it takes effect at the data engine level, applying uniformly to all access paths (API, SQL, dashboards, AI queries).

The three layers are independently functioning yet complementary — the failure of any single layer won't directly lead to data leakage.

Security Scalability for AI Feature Expansion

As AI/BI capabilities continue to evolve, dashboards will increasingly integrate natural language querying, intelligent insight recommendations, and other features. This means security boundaries must cover not only static visualizations but also dynamically generated query requests.

When AI/BI dashboards integrate natural language querying (Text-to-SQL) and similar capabilities, security boundaries face entirely new challenges. In traditional dashboards, queries are predefined and security auditing is relatively controllable. But in natural language interaction mode, user questions may be transformed by Large Language Models (LLMs) into arbitrary SQL statements, introducing new attack vectors such as Prompt Injection and indirect data leakage. For example, an attacker might craft a natural language question to induce the model into generating cross-tenant queries — a question like "Show total revenue for all customers" could lead the LLM to generate a SQL statement without a tenant_id filter condition if no data-level security constraints exist.

Unifying security policies at the data governance layer enables natural language queries and other AI features to naturally inherit existing permission constraints, preventing new security vulnerabilities from being introduced through feature expansion. Regardless of what SQL the LLM generates, Unity Catalog's row-level and column-level security policies are enforced at the execution level, fundamentally blocking unauthorized data access. This design philosophy of "decoupling security from query generation" is a key architectural safeguard for keeping pace with the rapid evolution of AI-driven BI capabilities.

Conclusion

Embedding an AI/BI dashboard is just the starting point. Providing each viewer with a secure, isolated, and compliant data view is the true test of enterprise-grade applications. Security should not be an afterthought — it should be incorporated as a core consideration from the very beginning of architecture design.

By organically combining reliable identity propagation mechanisms, platform-native governance capabilities like Databricks Unity Catalog, and defense-in-depth strategies, developers can enjoy the convenience of embedding while safeguarding data security in multi-tenant environments. In an era where AI capabilities are continuously permeating BI tools, this architectural mindset of anchoring security at the data governance layer is not only applicable to current embedding scenarios but also lays a solid security foundation for unforeseeable future feature expansions.