dbt Cloud holds standing credentials to your data warehouse and write access to your transformation code, so a leaked service token, a loose group mapping or a shared deployment user can change production data without anyone touching the warehouse console. dbt Labs now documents the product as the dbt platform (formerly dbt Cloud); this guide uses dbt Cloud because that is still how most teams search for it. It covers how identity works in the platform, the permission sets that matter, service account tokens versus personal access tokens, environment-level permissions, warehouse credentials, SSO and SCIM, IP restrictions, Git integration and the audit log. It is written for analytics engineering leads, data platform owners and security teams reviewing a dbt deployment. For warehouse-side controls, see the Snowflake Security Guide; for the pipeline view, the ETL and ELT Pipeline Security Guide.
This is an independent guide from NHI Mgmt Group, based on dbt Labs's public documentation as of November 2026. It is not sponsored or reviewed by dbt Labs. Product features change, so confirm settings against dbt Labs's current documentation.
Key takeaways
- Service tokens for systems, PATs for people. dbt Labs recommends service tokens for access on behalf of the account and for flows that need a service account, and personal access tokens only where user context is needed, so production workflows belong on service tokens.
- Account Admin tokens are the crown jewels. The documentation warns that Account Admin service tokens have full read and write access to the account; scope tokens to specific projects and permission sets instead.
- Check the Developer role's environment default. When Developer is added to a group, Environment write access defaults to All environments, which includes Production unless you restrict it.
- Production warehouse credentials belong to a dedicated service user. dbt Labs recommends a dedicated user or service principal, key pair authentication where the warehouse supports it, and DBT_ENV_SECRET_ variables for anything sensitive.
- Turn off admin password logins once SSO works. SSO enforcement leaves existing Account Admin and Security Admin passwords working by default; that is a bypass of your identity provider's MFA and offboarding.
How identity and access work in dbt Cloud
Access is split into account-level permission sets (administration: inviting users, configuring SSO, creating groups) and project-level permission sets (environments, the IDE, jobs). Users receive permission sets through groups, and on Enterprise plans groups are usually mapped from identity provider groups. Alongside people sit three kinds of non-human credential: service account tokens, personal access tokens used by scripts, and the warehouse and Git credentials that environments and jobs use at run time.
| Identity or credential | Belongs to | Permissions | Typical use | Main risk |
|---|---|---|---|---|
| Human user (SSO or password) | A person | Union of the permission sets of their groups | IDE, job management, administration | Group mappings that grant more than intended |
| Service account token | The account | Permission sets assigned to the token, for all projects or specific projects | Orchestrators, Terraform, partner integrations, CI | Over-scoped Account Admin tokens that never rotate |
| Personal access token (PAT) | A user, in one account | Inherits the creating user's permissions | dbt CLI, development scripts | Used in production, then breaks or persists when the user leaves |
| Development credentials | Each developer | Whatever the warehouse grants that user | IDE and CLI development | Shared logins; no warehouse-side attribution |
| Deployment credentials | An environment | Whatever the warehouse grants the deployment user | Scheduled and CI jobs | A human's credentials used for production runs |
| SCIM token | The account | Provisioning users and groups | Identity provider sync | Unrotated token with lifecycle control over every user |
The older user API keys have been deprecated and no longer work; dbt Labs directs users to account-scoped PATs, which are unique per account even when one email address belongs to several accounts. If an integration stopped working after that change, replace it with a service token rather than a new PAT. See the API Key Management Guide for the wider lifecycle.
Admin roles and privileged access
The permission sets that need the tightest control are the ones that can change who has access, where code comes from or which warehouse identity runs it.
| Permission set | Level | Why it is privileged | Recommendation |
|---|---|---|---|
| Account admin | Account | Unrestricted access to every feature; default for the creator of an account and for the Owner group | Keep to a small named group; dbt Labs recommends limiting it |
| Security admin | Account | Security settings and policies; included in the IT licence type | Assign to the security team, not data engineers |
| Project creator | Account | Only set other than Account admin that can create projects; can create and edit connections, invite users, create groups and assign licences | Treat as an administrator |
| Admin | Project | Unrestricted access to existing projects; can invite members and assign access; default for the Member group | Review what the Member group grants before inviting anyone |
| Database admin | Project | Manages configuration between dbt and the warehouses | Limit to platform owners |
| Git admin | Project | Manages repository integrations and cloning | Limit to platform owners |
| Job admin | Project | Access to all environments by default, including Production | Use for the production deployment persona only |
The default Member group carrying the project-level Admin set is an easy miss: on a new Enterprise account, check that group before mapping a broad identity provider group into it. For read-only needs there are narrower sets: Account Viewer (read-only access to the account), Job viewer, Job runner (run jobs and see results, nothing else) and Analyst (IDE access with read-only environment configuration).
Environment-level permissions
Each project has four environment types: Production and Development (one each), Staging (one) and General (no limit). Environment write access lets a group create, edit and delete jobs and runs in chosen environment types. It can be granted to Analyst, Database admin, Developer, Git admin and Team admin. The trap is documented by dbt Labs itself: when the Developer role is added to a group, Environment write access defaults to All environments, broader than the permission table implies. The recommended single-project pattern is:
- Developers: Developer role with write access to Development and General only.
- Testing and QA: Developer role with write access to Development, Staging and General.
- Production deployment: Developer with all environments, or Job admin, held by a small group or a service token.
- Analysts: no write access to any environment.
Limits to plan around: you select environment types, not individual environments, and access to an environment covers everything in it (jobs and runs cannot be separated).
Integrations, API tokens and service accounts
Service account tokens
Service tokens belong to the account, not a user, and can carry any number of permission sets, each granted to all projects or to specific projects. Creating one needs a Developer licence and account admin permissions; the token is shown once. Which permission sets a token can hold depends on the plan: Enterprise and Enterprise+ can assign any set, legacy Team plans a fixed list including Account Admin, Job Admin, Metadata and Read-only, and Developer and Starter plans the Semantic Layer set. Practical scoping:
- Orchestrator that triggers jobs: Job runner on the specific project, not Job admin.
- Metadata or catalogue integration: Metadata Only.
- Semantic Layer consumer: Semantic Layer Only.
- Production Terraform: a service token (dbt Labs' own example) with the narrowest sets that cover the resources it manages; Account Admin only if it truly manages account settings.
Rotate by creating the new token with identical permissions, swapping it into the consuming system, then deleting the old one. dbt Labs also notes that tokens created on or before 18 July 2023 use an older format and recommends rotating them, which is a good prompt to find long-lived tokens. Store tokens in a secrets manager, not in orchestrator variables or repository files; see the Secrets Management Guide.
Personal access tokens
A PAT inherits the permissions of the user who created it, so a PAT made by a project admin is a project admin credential. dbt Labs recommends regular rotation and using PATs only where user context is required, such as the dbt CLI and endpoints that create or update user credentials. A partner integration running on someone's PAT should move to a service token, which gives visibility and least-privilege scoping.
Warehouse credentials
Environments define three things: the dbt version, the warehouse connection and the code version. Development credentials are set per developer in their profile; deployment credentials are set per environment and used by jobs.
- Dedicated identity: dbt Labs recommends that deployment warehouse credentials be for a dedicated user or service principal. Give production, staging and CI separate warehouse users with grants limited to their schemas. See Service Accounts in Snowflake Guide for the warehouse side on Snowflake.
- Key pair over password: for Snowflake deployment credentials the options are Username and Password or Key Pair (private key with optional passphrase). Prefer Key Pair.
- Warehouse OAuth for developers: on Enterprise and Enterprise+ plans, Snowflake OAuth lets developers authorise development credentials through Snowflake SSO instead of giving dbt a password, which keeps warehouse MFA and attribution intact.
- Secrets in variables: environment variables must start with DBT_, DBT_ENV_SECRET_ or DBT_ENV_CUSTOM_ENV_. All are encrypted at rest, but only DBT_ENV_SECRET_ values are scrubbed from logs and error messages and obfuscated in the UI. dbt Labs recommends wrapping credentials in extended attributes in such variables, for example password: '{{ env_var(''DBT_ENV_SECRET_PASSWORD'') }}'.
Git integration
dbt connects to Git through native integrations (GitHub, GitLab, and Azure DevOps on Enterprise plans), a managed repository, or a Git URL clone with deploy keys. The GitHub app requests read access to metadata and read and write access to checks, commit statuses, contents, pull requests, webhooks and workflows, so limit the app to the repositories dbt needs (configured in GitHub by an organisation owner). Enterprise developers must each link a personal GitHub profile, because the IDE verifies each developer's repository access. If private packages are cloned with a token held in an environment variable, dbt Labs recommends a read-only token from a machine account with limited repository access.
SSO, SCIM and IP restrictions
- SSO (Enterprise and Enterprise+): supports just-in-time provisioning and IdP-initiated login, and prompts re-authentication every 24 hours. Group membership and licence type are mapped from identity provider groups; groups with Assign by Default are given to every SSO user, so keep that option off groups with write access.
- Admin password bypass: enforcement covers non-admin users only. Turn off Allow password logins for account administrators in SSO and SCIM settings once break-glass is planned; dbt Labs keeps admin passwords for identity provider outages and warns that an offboarded admin who is not deleted can still log in with a password.
- SCIM (Enterprise and Enterprise+, Okta or Entra ID): provisions and deprovisions users and groups in near real time. With SCIM on, users are not added to default groups and manual changes are disabled; dbt Labs recommends keeping Allow manual updates off. Rotate the SCIM token by replacing it in the identity provider before deleting the old one.
- IP restrictions (Enterprise+): allowlist and blocklist rules in CIDR notation, enabled with Enable IP restrictions. Once on, they block the UI, PAT-based API calls and all service tokens from disallowed addresses. Add your Git provider's and identity provider's ranges first, or webhooks and SCIM will fail. dbt refuses to enable restrictions if your own address is on the blocklist, which prevents self-lockout.
Logging and detection
The audit log (Enterprise plans; Account Admin or Account Viewer to view) records who did what, when, from which IP and whether through the UI or API. Events from the last 90 days can be filtered and exported to CSV; Export All emails a full history, and retention is at least 12 months. Export regularly into your SIEM so retention and alerting do not depend on the console.
| Event type | What it shows | Alert when |
|---|---|---|
| service_token.created, service_token.revoked | Token lifecycle | Any creation outside a change window, or by an unexpected actor |
| login.password.succeeded | Password login | Any occurrence after SSO enforcement with admin passwords disabled |
| login.sso.failed | Failed SSO logins | Bursts from one actor or IP |
| auth_provider.changed | SSO configuration changed | Always |
| permission.added, group.changed, license_map.changed | Access changes | Grants of Account admin, Security admin or Production write access |
| credentials.changed, connection.changed | Warehouse identity or connection changed | Changes to Production environments |
| environment.changed, job_definition.changed | Environment or job settings changed | Production jobs edited by non-deployment actors |
| repository.changed | Repository settings changed | Always for production projects |
Use the actor_type and source fields to separate API activity by service tokens from user activity, and correlate with warehouse query history for the deployment user. Environment settings also keep 90 days of change history per environment.
Metrics worth tracking:
- Number of service tokens holding Account Admin (target: zero or a documented one).
- Percentage of service tokens rotated within your policy period.
- Number of groups with Production environment write access, and members in them.
- Password logins per month after SSO enforcement (target zero outside break-glass).
- Production deployment credentials that are a named person's warehouse user (target zero).
Hardening baseline
- Inventory: export service tokens with their permission sets and project scope, groups with their permission sets and environment access, and each environment's deployment credential owner.
- Fix the warehouse side first: create dedicated deployment users per environment, switch to key pair or OAuth, and grant only the schemas each environment builds. Test a production job run before removing old credentials.
- Re-scope tokens: replace Account Admin and Job Admin tokens with the narrowest permission sets on specific projects, swap them into consuming systems, then delete the old tokens.
- Restrict environments: set Environment write access explicitly on every group that includes Developer, and reserve Production for the deployment persona.
- Move secrets into DBT_ENV_SECRET_ variables and rotate any value that was previously visible in a plain variable or text box.
- Enforce identity: SSO with group mappings, SCIM with manual updates off, then disable admin password logins with a documented break-glass account.
- Restrict network access on Enterprise+ with an allowlist that includes Git and identity provider ranges; pilot it with a monitoring period before enabling.
- Wire up monitoring: scheduled audit log export, alerts from the table above and a quarterly access review.
Rollback: keep old tokens and credentials valid until the new ones have run successfully in each consuming system; IP restrictions can be switched off by an admin, and dbt support can help if a change on your side causes lockout.
Small teams versus large estates: on Starter and Developer plans many of these controls (SSO, SCIM, audit log, IP restrictions, most service token permission sets) are not available, so the essentials are a dedicated deployment user, DBT_ENV_SECRET_ variables, minimal admins and PAT hygiene. Enterprise estates with many projects should manage tokens, groups and environments through Terraform run on a service token, so access changes are reviewed as code.
Common misconfigurations
- One Account Admin service token for everything: an orchestrator, Terraform and a partner tool share a token that can change SSO, users and every project.
- Developer groups with All environments: the default write access lets every developer edit production jobs.
- A person's warehouse login as the deployment credential: production stops when they leave, and warehouse audit trails point at a human. Give the deployment identity key pair authentication and network policy.
- Passwords in extended attributes: visible to anyone who can read environment settings and potentially in logs, instead of a DBT_ENV_SECRET_ variable.
- Admin password logins left on: SSO enforcement looks complete, but admins bypass MFA and survive offboarding unless deleted.
- Assign by Default on a privileged group: every new SSO user receives its permissions on first login.
Framework mapping
| Control area | NIST SP 800-53 Rev 5 | NIST CSF 2.0 |
|---|---|---|
| Permission sets, environment write access, token scoping | AC-6, AC-3 | PR.AA-05 |
| SSO, SCIM, account lifecycle | AC-2, IA-2 | PR.AA-01 |
| Service tokens, PATs, warehouse credentials, secret variables | IA-5 | PR.AA-01 |
| IP restrictions | SC-7 | PR.PS-01 |
| Production job and environment change control | CM-5 | PR.PS-01 |
| Audit log export and alerting | AU-2, AU-6 | DE.CM-09 |
In ATT&CK terms, the main threat is misuse of valid cloud credentials (T1078.004 Cloud Accounts) and credentials left in configuration (T1552.001 Credentials In Files).
Practitioner checklist
- No service token holds Account Admin without a written reason; all are scoped to specific projects.
- Every integration and production workflow uses a service token, not a PAT.
- Groups containing the Developer role have explicit Environment write access that excludes Production.
- Each deployment environment uses a dedicated warehouse service user with key pair or OAuth authentication.
- All credentials in environment variables use the DBT_ENV_SECRET_ prefix.
- SSO enforced, SCIM enabled with manual updates off, admin password logins disabled except a break-glass account.
- No group with write access has Assign by Default enabled; the Member group's Admin set reviewed.
- The dbt GitHub app is limited to the repositories dbt uses.
- IP restrictions enabled (Enterprise+) with Git and identity provider ranges allowlisted.
- Audit log exported to the SIEM on a schedule, with alerts on token, SSO and production credential events.
Standards and references
- dbt Labs: Service account tokens
- dbt Labs: Account-scoped personal access tokens
- dbt Labs: Enterprise permissions
- dbt Labs: About environment-level permissions
- dbt Labs: Single sign-on (SSO) overview
- dbt Labs: Configuring public IP restrictions
- dbt Labs: The audit log for dbt Enterprise
- dbt Labs: Environment variables
Related NHI Mgmt Group resources: Snowflake Security Guide · ETL and ELT Pipeline Security Guide · API Key Management Guide · Secrets Management Guide