Secret scopes keep credentials out of notebook code, and Databricks redacts retrieved values when they are displayed. That redaction covers literal values only, and anyone with access to a scope can still read its contents, so scope design and permissions matter more than the redaction display.
What a secret scope is
According to the Databricks documentation, a scope is a named collection of secrets, and each secret is a key value pair stored in an encrypted database that Databricks manages. In a notebook you retrieve a value with dbutils.secrets.get, passing the scope and key name, and you can list the keys in a scope with dbutils.secrets.list.
Using a scope means the token does not appear in the notebook source, which is the file most likely to be shared, exported or committed.
Scope design
Databricks recommends aligning each scope with a role or application rather than an individual user. That advice holds up in practice:
- One scope per pipeline or application keeps blast radius small.
- Permissions such as MANAGE should go to the few people who maintain the secrets, not to every user of the notebook.
- Avoid a single shared scope named after the team that holds every credential. Anyone with read access gets all of them.
What redaction does and does not do
When a value retrieved with dbutils.secrets.get, or used in a Spark configuration property, is displayed, it appears as REDACTED. That prevents the obvious accident of printing a password in a cell.
The documentation is clear about the limit: it applies only to literal values, so transformed secrets are not covered. If code splits a token into characters, encodes it, or writes it to a file, the display protection no longer applies. In SQL, redaction applies to most query commands, and validation blocks DML statements that would store unencrypted secrets in tables, which is a useful guard but not a complete one.
Most important, users with access can still read secret contents. Redaction is a guard against accidents. It is not access control.
Practical rules
- Never assign a secret to a variable that you then transform or print.
- Review notebooks for code that writes secrets to storage or logs.
- Review who has read access to each scope every quarter and remove stale users and groups.
- Prefer credentials scoped to the minimum privileges the job needs, such as a read only database user.
- Rotate secrets when a person with access to the scope leaves the team.
- Clear notebook outputs before sharing or exporting.
Related checks
Notebook output saved in a file can contain data as well as secrets. See our guide on cleaning notebook outputs before you commit.
Where Safeguard fits
Safeguard covers code and dependency scanning, policies and gates, and evidence automation for the review records above. Start with the free scan at https://gold.safeguard.sh/scan.
Quick check
Does redaction protect a secret that my code has transformed?
No. Databricks documents that redaction applies only to literal values, so transformed secrets are not covered.
Should one scope hold every team credential?
No. Align scopes with a role or application so that read access to one does not expose unrelated credentials.
Sources
Last reviewed: 19 October 2026.
