How to prevent direct workspace changes in Databricks by vendors / external users?

[koti521]

Hi Team,

I’m looking for guidance on workspace governance and change control in Databricks, specifically related to vendor access.

We recently observed that workspace-level changes seem to be applied directly, and we want to understand how this is happening and how to better control it.

Is it possible for the Databricks (service provider) internal team to apply direct changes to a customer workspace (such as policies, configurations, or settings), and if so, how can organizations enforce controls to ensure all workspace changes are applied only through approved mechanisms with full auditability?

can you find out from Databricks how workspace changes are applied directly from vendor?

[Brahmareddy]

Hi  ,

How are you doing today? as per my understanding, we can first validate whether Databricks personnel access is enabled for your workspace. If it is enabled, we should confirm whether any recent workspace-level changes were performed as part of an approved support case, vendor activity, or internal admin action.

To get better clarity, we can review the workspace audit logs and check details such as who made the change, when it was made, what was changed, and whether it was linked to an approved change request or support ticket.

Going forward, you may want to keep vendor access disabled by default and enable it only when required for a specific support case, with a clear approval, defined time window, and audit tracking. Any workspace-level changes such as policies, configurations, permissions, or settings should ideally go through our standard change control process.

Hope this helps ensure better visibility, accountability, and full auditability for all Databricks workspace changes.

Let me know for any additional questions.

Regards,

Brahma

[koti521]

@Brahmareddy 

In our current Databricks workspace, the Personal Access Tokens (PAT) option is disabled, and we are reviewing additional controls to strengthen governance around workspace-level changes.

I have also seen the setting “Workspace access for Azure Databricks personnel,” which appears to allow Databricks engineers to access the workspace for troubleshooting purposes. However, this option seems limited to support scenarios and does not fully address our broader governance requirement. this also disabled right now.

With that context, I would like to understand:

• How are workspace-level changes (such as configurations, policies, or new platform features/enhancements) applied from the Databricks platform side?
• Is it possible for such changes to be applied directly to customer workspaces outside of customer-controlled processes?
• Are there any workspace settings, controls, or design approaches available to restrict or manage how such changes are applied, so they can be reviewed, validated, and aligned with internal change management processes?

Our goal is to ensure that no changes are applied directly to the workspace without visibility, control, and proper approval, particularly in production environments.

[Brahmareddy]

Thanks for adding more details.

Since PAT and Databricks personnel workspace access are already disabled, I would suggest first reviewing audit logs to identify whether the change was made by a workspace admin, account admin, service principal, Terraform, CLI, API, or vendor user.

Customer-controlled changes should generally be traceable through audit logs. For Databricks platform-side updates, new feature rollouts, or backend service changes, Databricks Support would be the right team to confirm what can be controlled, deferred, monitored, or audited.

For stronger governance, you can consider limiting workspace admin access, managing changes through IaC/CI-CD, disabling previews in production, separating dev/test/prod workspaces, and setting alerts for workspace setting or policy changes.

Hope this helps.