Beyond embedding: How to secure AI/BI Dashboards for every viewer

Beyond embedding: How to secure AI/BI Dashboards for every viewer | Databricks Blog Skip to main content

Summary

One dashboard serves every viewer. A single entitlements table and the signed embed token's __aibi_external_value determine which rows each viewer can access, without creating a dashboard for every customer or repeating filters across queries.

Access is granted through identity-provider groups, not manually maintained user lists. The application resolves an internal viewer's groups with an on-behalf-of token before minting the embed token.

Default-deny and defense in depth. The pattern masks sensitive columns, refuses tokens for unentitled viewers, and uses Unity Catalog row filters to protect direct SQL access.

The challenge Embedding a Databricks AI/BI Dashboard in a customer-facing application is relatively straightforward: enable embedding, mint a scoped token in the backend, and render the dashboard with the client SDK. The foundational guide, How to embed Databricks AI/BI Dashboards in customer-facing applications walks through that process end to end. The harder question is authorization: once a dashboard is embedded, which rows should each viewer see? A partner should see only its own data, while an internal team may see only its region. This guide shows how to enforce those rules. This reference pattern combines several Databricks capabilities: __aibi_external_value, Unity Catalog row filters and column masks, and groups synchronized from an identity provider (IdP). It is a design pattern, not a single feature to enable. One rulebook, two enforcement paths The same entitlements table governs two paths: embedded dashboards accessed through the application, and direct SQL queries run by Databricks users. A concrete scenario Consider a company that uses a shared "Open Accounts Receivable (AR) Tasks" dashboard for data across three regions: West, East, and Central. The dashboard serves two audiences. External operating partners, such as Acme Ops, Bolt Partners, and Core Logistics, have no Databricks login and access the dashboard through a white-label portal. Each partner should see only its own region, with contact emails masked. Internal teams are the company's employees, who sign in to Databricks. Finance needs access to every region, while a regional operations team sees only its own. Their access comes from identity-provider groups such as Okta or Entra ID, not from manually maintained user lists.

Five viewers share one dataset, each seeing a different slice: Acme Ops, Bolt Partners, Core Logistics, Finance, and a regional operations team. The examples below focus on Acme and Finance; the identifiers partner_acme, finance_all, and West represent those examples. Acme sees West with emails masked, while Finance sees all three regions in full, both from the same published dashboard. One table, one view, one dashboard Access rules live in one place rather than being scattered across dashboards or queries. A dashboard per customer creates copies that can drift out of sync, while repeating filters in every query creates opportunities for mistakes. The model consists of three objects: Base table open_ar_tasks holds one row per AR task, tagged with a region and a contact email.

task_id market operating_partner amount_open contact_email T-1001 West Acme Ops $12,400 jane@acme.com T-1002 East Bolt Partners $8,900 raj@bolt.com T-1003 Central Core Logistics $15,200 mia@core.com

The entitlements table is the single source of truth for access. Each row identifies the region a scope can access and whether sensitive values should be masked. The viewer_scope column stores both external partner IDs, such as partner_acme, and internal group names, such as finance_all.

viewer_scope market mask_pii partner_acme West true finance_all West false finance_all East false finance_all Central false ops_west West false

Secured view joins the base table to entitlements, so a viewer sees only entitled regions, with emails masked when the flag is set.

In most deployments, an upstream entitlement system or an application-owned group-to-region mapping populates this table; it is not edited by hand for each viewer.

This avoids per-customer dashboards and filters repeated across queries. The rules live in a table that can be queried, audited, and changed without modifying the dashboard. Applied per viewer, the secured view returns only what that viewer is entitled to: Acme (external_value = partner_acme): West only, contact email masked. task_id market operating_partner amount_open contact_email T-1001 West Acme Ops $12,400 ****@acme.com

Finance (external_value = finance_all): all three regions, contact email in full. task_id market operating_partner amount_open contact_email T-1001 West Acme Ops $12,400 jane@acme.com T-1002 East Bolt Partners $8,900 raj@bolt.com T-1003 Central Core Logistics $15,200 mia@core.com

Where __aibi_external_value comes from The backend sets this value when it mints the embed token. It authenticates as a service principal and requests a scoped token from Databricks with two values: external_viewer_id, which identifies the viewer for auditing, and external_value, which represents the viewer's scope. Databricks signs the token, and the viewer cannot modify the embedded value, which is exposed to the dashboard SQL as __aibi_external_value. Because it holds the service principal's credentials, this backend is a trusted server-side component, never the browser, with those credentials kept in a secrets manager rather than in source control. The key detail is whose identity runs the query. Embedded queries execute under the configured publishing identity, not the viewer's Databricks identity. For external embedding, Databricks recommends individual data permissions and granting the service principal its own data access, so queries run as the service principal. (Publishing with shared data permissions instead runs queries as the publisher's credentials.) The view then narrows that access for each viewer through __aibi_external_value. Because the query runs as the service principal, is_account_group_member() cannot identify the actual person viewing the dashboard on the embed path. The important detail is that external_value is not limited to a partner id. It can be any scope the backend signs into the token, for example partner_acme for an external partner or finance_all for an internal group (their group name). Because the...