How to limit the AI/BI dashboard sharing people-picker to workspace members

[charl-p-botha]

Dear community,

We follow the environment-isolation guidance in [1], relying on between-workspace and within-workspace separation (Unity Catalog, catalog-workspace bindings, ACLs). In our case we have different groups of users each assigned to their own isolated workspace. For data and compute this works exactly as advertised.

We have, however, hit a confidentiality problem with AI/BI dashboard sharing. When a user in one of these isolated workspaces opens the Share dialog and types into the "add people" box, the frontend calls the graphql/listPrincipals endpoint, which returns all users across the entire account, regardless of workspace membership. In other words, a user in Workspace A can enumerate, by display name and email address, every other user in the account, including users belonging to entirely unrelated workspaces and customers.

Because dashboards are account-level shareable assets, this picker appears to be account-scoped by design (see [2], [3]): "account users can be assigned as recipients for dashboards ... across any workspace in the account." The unfortunate consequence is that the between-workspace identity isolation implied by the guidance in [1] is quietly undone at the sharing dialog.

After an in-depth exploration of all documentation and also the latest databricks cli, I have not been able to find any way to scope this picker to a workspace:

- Disabling Automatic Identity Management [4] narrows the search from the entire Entra tenant down to the registered account users, but it remains account-wide.
- None of the workspace settings / workspace-conf keys, nor any of the AI/BI admin controls (embedding, email subscriptions, results download, ownership transfer), gate who appears in the picker.
- On Azure the account is 1:1 with the Entra tenant, so isolating into separate accounts would mean separate tenants, and would in any case break the central Unity Catalog metastore that [1] encourages us to rely on.

Please suggest a way whereby the dashboard sharing people-picker / listPrincipals, and more importantly sharing in general, can be limited to users assigned to the current workspace? A user in an isolated workspace should not be able to enumerate are share with the users of other isolated workspaces.

Please help.

Kind regards,
Charl Botha, Stone Three

[1] https://community.databricks.com/t5/technical-blog/isolation-of-environments-on-the-databricks-data-...
[2] https://learn.microsoft.com/en-us/azure/databricks/dashboards/share/share
[3] https://learn.microsoft.com/en-us/azure/databricks/dashboards/admin/
[4] https://learn.microsoft.com/en-us/azure/databricks/admin/users-groups/automatic-identity-management/

[Ashwin_DSA]

Hi @charl-p-botha,

Your concern is understandable, and based on the current public documentation, what you are seeing is consistent with how AI/BI dashboard sharing works today.

Published AI/BI Dashboards are documented as shareable with users and groups in the Databricks account, not only with members of the current workspace. The public docs state that you can share dashboards with users and groups in your account, that account users do not need workspace membership to be recipients, and that account users can be assigned as recipients across workspaces in the account. The relevant references are Share a dashboard and the AI/BI administration guide.

The same account-scoped model is also reflected in Databricks public AI/BI sharing blog, which explains that dashboards can be shared with users in other workspaces in the same organisation and with account-level view-only users, and that individual users or groups appear in the sharing dialog search results. See How to share AI/BI Dashboards with everyone in your organization.

Because of that, I'm not aware of a documented admin setting today that restricts the dashboard-sharing people picker to only members of the current workspace. So the behaviour you observed appears to be a current product limitation for customers that rely on strict workspace-level identity isolation, rather than a simple misconfiguration.

If your goal is strict data-plane isolation, the main controls described in the public docs are to publish with Individual data permissions instead of shared data permissions and to rely on workspace-bound securables where appropriate. The docs note that account users without workspace membership cannot access data from workspace-bound securables. See Share a dashboard and the AI/BI administration guide.

That said, those controls do not solve the specific concern you raised about recipient discovery in the people picker. If the requirement is that users in Workspace A should not be able to discover or target identities that are only relevant to Workspace B, then this is best treated as a feature request for workspace-scoped recipient search and workspace-scoped sharing controls.

As a partner, the best way to push this forward is to ask your Databricks contact team to file product feedback for something like: "Limit AI/BI dashboard recipient search and sharing to principals assigned to the current workspace, or provide an admin control to disable account-scoped recipient discovery."

I would recommend including the following in that request:

• Whether you need the restriction only in the people picker, or also enforced at the API / permission layer
• Whether Automatic Identity Management is enabled
• Your cloud and identity provider
• Whether the requirement is driven by customer isolation, regulated workloads, or partner multi-tenant delivery
• Whether a workspace-only mode would be sufficient, or whether you need an account-level allowlist model

That should allow the product team to see if this feature can be added in the future.

If this answer resolves your question, could you mark it as “Accept as Solution”? That helps other users quickly find the correct fix.

[charl-p-botha]

Thank you very much @Ashwin_DSA for confirming my findings that there's currently no way to limit the picker to current workspace users.

For the record:

We have requested via our Azure support channels that our request for such a feature be escalated, FWIW.

I'm not sure at this point if we should try to put in the request via Databricks partner contacts as well, us much as we as recently-started partner have access to them. What do you think?

For the record:

• On the short term, having it restricted in the people picker would already help a great deal, but indeed API / permission layer would be ideal.
• We had AIM briefly enabled (around 1 day), until we saw this identity directory leakage at which point we promptly disabled it.
• We are using Azure Entra ID with Azure Databricks.
• Our requirement is driven by customer isolation. We don't want customer X browsing customer Y's users.
• Workspace-only mode would be fantastic, as we are already relying on workspace isolation for all of our other customer-driven requirements.

[Ashwin_DSA]

Hi @charl-p-botha,

Azure support channels will typically help you with any blockers or issues you encounter. Since this current behavior is expected for the product, I recommend that you reach out to your account team or the partner channel. This way, your concerns can be treated as a feature request or product feedback for the relevant teams to consider adding to their backlog.

[iyashk-DB]

Today there's no admin setting today that scopes the "add people" search to just your workspace, it's an account-wide search by design since AI/BI dashboards are shareable with any account user regardless of workspace membership.

One thing that can help in the meantime: instead of searching for individuals in the people picker, share the dashboard with the built-in "All workspace users" system group. It's automatically maintained by Databricks and only contains members of that specific workspace, so you skip the free-text search entirely and don't expose the account-wide directory to whoever is sharing. You'll find it listed right alongside your other groups in the sharing dialog, no sync or setup needed.

If you need more granular access than "everyone in the workspace," the more scalable route is to have your admin sync a workspace-specific group from your IdP (Entra ID, Okta, etc.) via SCIM and share with that group instead of individuals. Same effect: your users only ever pick a group name they already know, never search through the account's full user list.

Neither of these closes the underlying gap Ashwin flagged; the people picker itself is still account-scoped when you do search for a person, so if someone needs to add a specific individual by name, that exposure is still there. For that part, filing it as product feedback for workspace-scoped recipient search is the right call since it sounds like a genuine gap for anyone relying on strict workspace isolation.

[charl-p-botha]

Thank you @iyashk-DB for the advice.

Indeed we are grateful for and rely on the "all workspace users" sharing group!

However, it does not matter how many convenient groups we create for sharing, our customer user X sees accounts from our customer Y when they search in the dashboard sharing dialog, which we can't have.

We administrate and control very precisely which users and user groups have access to which catalogs and which workspaces. It would be ideal if we could limit sharing from a workspace to other users of that workspace.