A Databricks personal access token authenticates REST API calls, the command line and connectors as the user who created it, inside one workspace. The holder can run notebooks and jobs, start clusters, read tables the user can read and query SQL warehouses. Clusters often run with cloud credentials attached, so a token can lead to your cloud storage as well as your data. Revoke it first, then look at what ran.
Check your GitHub account for leaked secrets — free
- Provider
- Databricks
- Severity
- Critical
- Impact
- Cloud infrastructure access
- Checked live by LeakWatch
- No
What a Databricks API token looks like
A Databricks personal access token starts with dapi, followed by 32 lowercase hexadecimal characters. Some workspaces add a dash and a single digit at the end:
dapi…XXXX Databricks personal access token (masked, 32 hex characters after the prefix)
dapi…XXXX-2 same format with an optional numeric suffix (masked)
The prefix makes it simple to attribute. The token works only against the workspace that issued it, so the host name next to it (a *.cloud.databricks.com or *.azuredatabricks.net address, in a DATABRICKS_HOST variable or a .databrickscfg file) tells you which workspace to open. Do not confuse it with an OAuth client secret or a service principal secret, which have other formats.
How Databricks API tokens get leaked
- Profile files. A
.databrickscfgfile withtoken = …committed with a project or a dotfiles repository. - Notebooks. A token pasted into a notebook cell, then exported or synced to a Git repository with its outputs.
- Pipeline configuration.
DATABRICKS_TOKENwritten in plain text in a CI workflow or a bundle configuration. - Connector settings. A BI tool or an application connection string that carries the token as the password.
- Support requests. A token pasted while asking why a job fails with a permission error.
What to do in the first hour
- Find the token. In the workspace, open your user settings and the developer section where access tokens are listed. The list shows the comment, the creation date and the expiry date. Workspace administrators can also list the tokens of all users from the admin settings.
- Create a replacement. For automation, prefer a service principal with a narrow set of permissions over a token tied to a person.
- Deploy the new credential where the old one was used and run one job to confirm.
- Revoke the exposed token from the same list. Requests using it are then refused.
- Review the audit trail. Look for jobs, notebooks or clusters you did not start, new libraries installed on clusters, new users or tokens, and queries on tables the integration normally never reads.
- Check what the user could read. List the catalogs, schemas, tables and secret scopes the user had access to. If sensitive data could have been read, follow your incident procedure for data exposure.
- Rotate secrets reachable from the workspace. Cloud keys, database passwords and secrets stored in notebooks or secret scopes should be treated as exposed. See I accidentally pushed an API key to GitHub.
Not sure what else leaked from the same repository? Run a free scan.
Revoke it at Databricks
Databricks personal access tokens are revoked inside the workspace that issued them. Sign in to that workspace, open your user settings, go to the developer section and the access tokens list, and revoke the exposed one. An administrator can do it for any user from the workspace admin settings. There is no single global page: the address depends on the workspace host, so a leaked token must be revoked in the workspace named in the nearby configuration. Databricks documents token management and token lifetimes. Menu names can change, so look for the section that lists access tokens.
How LeakWatch detects it
The rule is called Databricks API Token. It matches dapi followed by exactly 32 lowercase hex characters and an optional dash and digit, bounded as a whole word. Uppercase or shorter strings are ignored on purpose, to avoid unrelated identifiers that begin with the same letters. The severity is critical, because a token can reach data and compute. This type is not checked live: LeakWatch does not call your workspace with the value, so a finding means the string was seen, not that the token is active. Open the token list to check whether it still exists.
LeakWatch detects this format but does not check it live: it can tell you the key is exposed, not whether it still works. Assume it does until you have revoked it.
FAQ
Which workspace does my leaked token belong to?
The token alone does not say. Look at the host name or configuration file next to it, or search your workspaces’ token lists for the creation date and comment.
Can the token read data outside the workspace?
It can reach whatever the user can reach from there, including cloud storage mounted or accessed through the cluster’s credentials. Review those credentials too.
The token had an expiry date. Do I still need to revoke it?
Yes if it has not expired yet. An expiry limits the window but does not close it; revoking ends it immediately.