Databricks can now narrow service-principal tokens—but old secrets stay broad

Databricks has added a practical least-privilege control for unattended integrations: administrators can now bind a service principal’s OAuth secret to selected API scopes such as sql, jobs, or unity-catalog. A token minted from that secret cannot exceed those scopes, even if the service principal itself has broader permissions. For teams embedding Genie, SQL execution, or other data tools into an agent, that creates a second boundary around what a leaked or misused credential can call. (Databricks documentation)

The migration does not happen automatically

The important caveat is backward compatibility. Databricks says a secret created without selected scopes—including every existing OAuth secret—retains all-apis access and behaves as before. Scopes are also fixed when the secret is created; changing them means issuing a replacement secret. Administrators can clone an existing credential’s lifetime and scope settings, but they still need to distribute the new secret and retire the old one themselves. (Databricks documentation)

That makes inventory the first deployment step. Find every service principal used by an analytics agent or automation, identify the API families it actually calls, create a narrowly scoped replacement, rotate the consuming application, and then revoke the broad credential. Restricting the token’s API surface does not replace object permissions: Databricks separately notes that the service principal still needs access to the relevant SQL warehouse, cluster, catalog, and data objects. (Databricks documentation)

One scope deserves special treatment

The authentication scope is deliberately powerful. Databricks warns that a secret carrying it can create new tokens with any scope, so it should be reserved for credentials that manage other credentials. Giving it to a query-only agent would undermine the point of selecting sql instead of all-apis. (Databricks documentation)

The same page also documents workspace-level role assumption. A service principal can request a token with an assume_group parameter; the selected role’s permissions replace the principal’s own permissions for that token, provided the principal has permission to assume the group-backed role. This is useful when one runtime must operate in mutually exclusive permission sets, but it is distinct from per-user delegation: the token still represents the service principal operating under a chosen role. (Databricks documentation)

For production data agents, the useful rule is simple: use object grants to decide which data is visible, a scoped secret to decide which API families are callable, and role assumption only where the workload genuinely needs separate operating modes. Then verify that no legacy all-apis secret remains active after the cutover.