In dbt, name any secret environment variable with the prefix DBT_ENV_SECRET_ and the tool scrubs it from logs and error messages and obfuscates it in the UI. The protection depends entirely on the prefix, so a secret named without it gets no special handling.
What the prefix does
The dbt documentation says variables with this prefix get extra protection. They are scrubbed from all logs and error messages, obfuscated in the UI so they do not appear in the UI or artifacts, and encrypted at rest in the hosted product. Decryption happens only in specific flows, such as when a job runs.
You reference the variable as you would any other, with the env_var function and the full prefixed name inside a Jinja expression. The prefix is part of the name.
A common use: private package tokens
Teams clone private packages over git using a token. The dbt documentation recommends a read only token, such as a machine account or service user personal access token with limited repository access, rather than a personal token with wide scope. That keeps a leaked token from becoming a leaked codebase.
Where the protection ends
Be honest about what a scrubber can and cannot do.
- It protects variables that follow the naming convention. A password in a plain environment variable called WAREHOUSE_PASSWORD is not covered by the rule.
- It does not govern values you copy elsewhere. If a macro writes a secret into a table, a log of your own, or a comment, the scrubbing cannot follow it.
- It does not limit who can run a job that uses the secret. Anyone who can edit a model may be able to write code that uses it.
So pair the prefix with permissions on who can change project code and with a credential that has minimal privileges.
A five minute test
- Set a dummy value in a variable named with the prefix.
- Trigger a run that fails on purpose and prints verbose output.
- Search the logs and artifacts for the dummy value.
- Repeat with a variable that does not use the prefix, to see the difference.
- Record the result in your team runbook.
If you see the dummy value anywhere, treat the setup as unprotected until you find out why.
Review for the rest of the project
Check profiles files, CI configuration and any shell scripts that wrap dbt runs for pasted credentials. Check that CI masks values in its own logs, since dbt only handles its own output.
Related reading
For the wider map of leak points, see where ETL pipeline secrets leak.
Where Safeguard fits
Safeguard scans repository dependencies, including the packages a dbt project pulls in, and its policies and gates can enforce your review rules on pull requests. Free scan: https://gold.safeguard.sh/scan.
Quick check
What happens to a secret that lacks the DBT_ENV_SECRET_ prefix?
It gets no special scrubbing, so it can appear in logs and error messages.
What kind of token does dbt recommend for cloning private packages?
A read only token, such as a machine account or service user token with limited repository access.
Sources
Last reviewed: 19 October 2026.
