How to secure a single AI/BI dashboard for multiple viewers

Embedding a Databricks AI/BI dashboard into a customer-facing app is technically simple: enable embedding, mint a scoped token, and render. The harder question is authorization: how do you ensure each viewer—external partners or internal employees—sees only the rows and columns they're allowed to see? Copying dashboards per customer or scattering filters across queries creates maintenance and security problems.

This guidance describes a pattern that keeps one dataset, one view, and one published dashboard. Access rules live in a single entitlements table. Enforcement happens in two ways: when viewers access the dashboard through embedding, and when users run direct SQL in Databricks. The same entitlements table governs both paths.

• Entitlements table: the single source of truth. Each row maps a viewer scope (external partner ID or internal group) to markets/regions and a mask flag for sensitive columns.

• Unity Catalog protections: row filters and column masks enforced at the catalog level protect users attempting direct SQL access, providing defense in depth.

Concrete scenario used for illustration

A single "Open AR Tasks" table holds tasks across three regions (West, East, Central) with a contact email column. Five viewers share the dataset: three external partners (Acme Ops, Bolt Partners, Core Logistics), an internal Finance group, and a regional ops team.

The entitlements table contains entries like viewer_scope = partner_acme with market = West and mask_pii = true, and viewer_scope = finance_all with markets West, East, Central and mask_pii = false. The secured view filters rows by matching entitlements.viewer_scope to __aibi_external_value and applies masking when mask_pii is true.

1. 1The client uses the token to render the embedded dashboard. Dashboard SQL sees __aibi_external_value and returns only entitled rows with masking applied per the entitlements table.
2. 2Unity Catalog row filters and column masks protect data for anyone who tries to bypass the UI and query the underlying tables directly.

• Centralized rules: entitlements live in a queryable table that can be audited and modified without altering dashboards.
• Default-deny: the model refuses tokens for unentitled viewers and uses catalog-level controls for extra protection.
• Defense in depth: view-level joins, catalog row filters, and column masks together reduce risk of accidental exposure.

Use it when a single dashboard must serve multiple external and internal audiences with different row- and column-level permissions, when you want centralized, auditable entitlements, and when you must protect both embedded usage and direct SQL queries.