Databricks’ embedded AI/BI pattern needs two authorization paths, not one

Databricks has published a concrete authorization pattern for teams embedding one AI/BI dashboard across customers and internal groups. The important lesson is not the embed API. It is that an embedded viewer and a workspace user reach the same data through different identities, so one security check cannot safely cover both paths.

The embed token is not the data policy

In Databricks’ reference design, an application backend authenticates as a service principal and mints a short-lived dashboard token. The token carries external_viewer_id for audit and external_value for authorization scope. Dashboard SQL can read the signed scope through __aibi_external_value; the browser cannot rewrite it.

That allows one secured view to join business rows against a shared entitlements table. A partner scope can receive one region with sensitive columns masked, while an internal finance scope can receive all regions. An unknown scope matches nothing, providing a useful default-deny behavior.

But the embedded query runs as the configured publishing identity—not as the human looking at the dashboard. That means a function such as is_account_group_member() would evaluate the wrong identity on the embed path. Databricks therefore puts group resolution in the trusted backend, before token issuance, and recommends refusing to mint a token when no valid entitlement exists.

Direct SQL is a separate route

The same person may also reach the base data through a Databricks workspace. That request has a real Databricks user identity, so the signed embed scope is absent and the secured dashboard view is not enough.

Databricks’ pattern adds a Unity Catalog row filter to the direct-query path and can pair it with a column mask. On this route, account-level group membership can be evaluated against the caller. The embed filter and the direct SQL filter are separate enforcement points, but both read the same entitlements table. That shared rulebook limits policy drift without pretending the two identity paths are equivalent.

The operational checks matter

The guide names constraints teams should test before calling the design production-ready. Embed tokens expire after one hour. external_viewer_id and external_value must remain under 1 KB combined. External embedding is limited to 20 dashboard loads per second per workspace. Downloads are enabled by default unless an administrator disables them, so exported results need the same tenant-isolation test as the rendered dashboard.

There is also a boundary for natural-language querying: Databricks’ external-embedding documentation says Ask Genie is not available in externally embedded dashboards. Teams that want to expose Genie to outside users must integrate the separate Genie Conversation API, which means its authorization path needs its own review rather than inheriting the dashboard’s assumptions.

The signed token carries only one external_value. If a viewer belongs to several groups with different entitlements, the backend needs deterministic precedence, a canonical combined scope, or a different direct-query design. Falling back to a broader identity when group resolution fails would defeat the default-deny model.

For practitioners, the deployment test is simple: trace each access route to the identity that actually executes the query. Then verify that every route fails closed, uses the same entitlement source, masks sensitive fields consistently, and produces an auditable decision. Embedding a dashboard is a presentation choice; tenant isolation is a data-access architecture.