A leaked Doppler token is a leak of every secret it could read, so revoking the token is only the first half of the response. Doppler issues seven token formats, from config-scoped service tokens to service account tokens with workplace roles and personal tokens that carry a person's full permissions, and each one needs a different revoke path and a different scope of secret rotation afterwards. This guide is the Doppler-specific runbook: identifying the token, working out which configs and secrets it reached, using access logs and activity logs to see what was read or changed, revoking, rotating downstream, and closing the gaps that let the token leak. It is for platform and security teams that run Doppler as their secrets manager. The Doppler, 1Password and Infisical Service Tokens Guide compares the products; this page goes deeper on Doppler incidents.
Key takeaways
- Every Doppler token announces its type.
dp.st.service,dp.sa.service account,dp.said.short-lived identity,dp.pt.personal,dp.ct.CLI,dp.scim.SCIM anddp.audit.audit tokens each map to a different owner and blast radius. - Personal and CLI tokens are the dangerous ones. Doppler warns they have write access with the creating account's permissions and should not be used in live environments.
- Revocation is immediate but not total. A revoked service token stops working at once, yet the Doppler CLI's encrypted fallback file can still serve the last secrets it fetched on that host.
- Access logs tell you which secrets to rotate. Doppler records, per secret, which actor read it and when, within your plan's history limit.
- Federation removes the static token. Service account identities exchange a CI or cloud OIDC token for a short-lived
dp.said.token, so there is nothing long-lived to leak.
How identity and access work in Doppler
Doppler organises secrets into a workplace, projects, environments and configs. People act through workplace and project roles; machines use tokens. Doppler's token formats reference lists a unique prefix for each type, followed by a 40 to 44 character body:
| Token | Prefix | What it reaches | Revoke where |
|---|---|---|---|
| Service token | dp.st., optionally with an environment segment such as dp.st.prd. | One config in one project; read-only by default, write if granted | Config Access tab, CLI doppler configs tokens revoke, or the API |
| Service account token | dp.sa. | Whatever the service account's workplace role and project access grant, across multiple projects | Service account page, token menu: roll or delete |
| Service account identity token | dp.said. | Same as its service account, issued after OIDC exchange | Expires quickly; can be revoked |
| Personal token | dp.pt. | Everything the user can do, including writes | The user's token settings, or remove the user |
| CLI token | dp.ct. | Everything the user can do, created by doppler login | The user's token settings, or the auth revoke API |
| SCIM token | dp.scim. | User and group provisioning for the workplace | Workplace SCIM settings (roll or revoke) |
| Audit token | dp.audit. | Read access to workplace audit data | Workplace settings (roll or revoke) |
The environment segment in a service token is a useful triage hint: dp.st.prd. found in a public repository is a production incident before you have even looked it up. Any token can also be revoked with a POST to https://api.doppler.com/v3/auth/revoke carrying the token value, which matters when you hold a leaked value but do not know which config it belongs to.
Admin roles and privileged access
- Workplace Admins: manage Trusted IPs on configs, service accounts and workplace settings. An Admin's personal or CLI token is effectively an administrator credential.
- Manage Service Accounts permission: lets non-admins create service accounts and their tokens; restrict it to the platform team.
- Project roles: grant access per project and environment to users, groups and service accounts. A service account starts with no workplace role and no project access.
- SCIM token holders: can create users and change group membership, which in turn grants project access. Treat a leaked SCIM token as an identity compromise, not a configuration one.
Most real Doppler leaks are personal or CLI tokens copied from a developer laptop into a script or container, because doppler login makes them easy to obtain. Those tokens inherit the developer's access across every project they belong to.
Integrations, API tokens and service accounts
| Use case | Preferred credential | Why |
|---|---|---|
| A single application reading one config | Service token, read-only, with an expiry | Narrowest scope; revoking breaks one consumer |
| A CI job | Service account identity via OIDC, or an ephemeral service token made with --max-age | No long-lived secret in CI variables |
| Kubernetes | Doppler Kubernetes Operator with OIDC identity where possible | Short-lived tokens, nothing in manifests |
| Automation across several projects | Service account token with the minimum workplace role | Actions tied to the service account, not a person |
| Local development | CLI token on the developer's machine only | Never copied into shared systems |
Integrations and config syncs push Doppler secrets into other platforms (cloud secret stores, hosting platforms, CI systems). A token that can write configs or change integrations can therefore change secrets in those platforms too, so integration changes belong in the investigation. For identity federation patterns generally, see the Workload Identity Federation Guide.
Logging and detection
Secret scanning coverage
GitHub's pattern data lists six Doppler types (service, service account, personal, CLI, SCIM and audit tokens), all in the partner programme for public repositories, with push protection and validity checks. The short-lived dp.said. type is not among them. Gitleaks' default doppler-api-token rule (checked 28 October 2026) matches only personal tokens, so add custom rules for the other prefixes, especially dp.st. and dp.sa., and scan container images and CI logs as well as repositories. See the Git Secret Scanning Guide.
Access logs
For each secret, Doppler's access log shows the actor (user, service token, personal token, CLI token, API, Terraform provider or Kubernetes operator), the access method, and the first and most recent read. An access is logged when a payload containing the secret is returned, even if the actor never used it; blank secrets are not tracked. History length depends on your plan, so export what you need early in an incident.
Activity log events
Activity logs record workplace and config changes and can be sent to destinations such as Splunk, Datadog, Sumo Logic, AWS SQS or a generic HTTPS endpoint. Events that matter for credential incidents:
| Concern | Activity log event |
|---|---|
| New or rolled tokens | team.seat.token.personal.create, team.seat.token.cli.create, team.service_account.token.create, team.service_account.token.roll, enclave.project.config.service_token.create |
| Token revocations | team.seat.token.personal.revoke, team.service_account.token.revoke, workplace.tokens.revoke.initiated |
| New service accounts or role changes | team.service_account.create, team.service_account.workplace_role.update, team.service_account.identity.create |
| Membership changes | team.seat.invite.create, team.seat.join, enclave.project.access.create |
| Secret changes and sharing | enclave.project.config.secrets.update, enclave.project.config.secrets.share |
| Integrations and syncs | workplace.integration.connect, enclave.project.integration.create |
The event's actor has a kind of user, serviceAccount, apiToken or bot. The schema does not document an IP address field, so network context has to come from your own egress logs and from Trusted IP enforcement.
Metrics that show it is working
- Personal and CLI tokens outside laptops: count found in CI, servers or images, target zero.
- Service tokens without expiry: share of
dp.st.tokens with no expiration. - Configs open to the internet: configs still allowing
0.0.0.0/0in Trusted IPs. - Federated workloads: share of CI and Kubernetes consumers on OIDC identities.
- Time to rotate: from token revocation to the last exposed secret rotated.
Leak response
Triage: how wide is this leak?
- Read-only service token for a development config: revoke, rotate that config's secrets, and fix the source within the working day.
- Service token for a production config, or one with write access: treat as urgent; a write-capable token can also change secrets that syncs push to other platforms.
- Service account token: list its workplace role and project access first, because the blast radius is every config those grant.
- Personal or CLI token: treat as a compromise of that person's Doppler access, including writes, across every project; check the device the token came from, since a stolen CLI token often means an infected laptop.
- SCIM token: an identity incident: review users and groups before anything else.
Response steps
- Classify the token from its prefix and any environment segment. Note where it was found and the earliest possible exposure time.
- Revoke immediately. For a service token use the config's Access tab or
doppler configs tokens revoke -p PROJECT -c CONFIG; for a service account token delete it (or roll it if a consumer must keep working, deploying the new value at once); for personal and CLI tokens revoke in the user's settings. If you only hold the value, POST it to the/v3/auth/revokeendpoint. Revocation is irreversible. - Clear fallback files on hosts that used the token, because the CLI's encrypted fallback can still serve the last fetched secrets after revocation.
- Scope the exposure: for a service token, the secrets in its config; for a service account, every config its roles reach; for a personal or CLI token, everything the user can read. Use access logs to confirm which secrets the token actually read and when.
- Rotate exposed secrets at their source (database passwords, cloud keys, API keys), update them in Doppler, and let syncs propagate. Prioritise secrets the token is shown to have read, then the rest of its scope. Doppler's rotated and dynamic secrets features shorten this step for supported backends.
- Check for changes: search activity logs for the token's actor across the window for secret updates, sharing, new tokens, new service accounts, role changes and integration changes. Config logs work like commits, so unwanted secret changes can be rolled back.
- SCIM or audit tokens: roll them in workplace settings; for SCIM, review users and groups created or changed during the window.
- Close out with the evidence fields in the Secrets Rotation Runbook Template and the process in the Leaked Credential Response Playbook.
If many tokens may be exposed at once (a compromised CI system or laptop fleet), Doppler's activity log schema includes events for a workplace-wide token revocation (workplace.tokens.revoke.initiated and .completed); confirm the option and its effect for your plan with Doppler before an incident, because it will break every consumer at once.
Hardening baseline
- Inventory tokens per config and service account, and ask each team to declare where personal or CLI tokens are used outside laptops.
- Replace personal and CLI tokens in automation with service tokens or service accounts, one consumer at a time: create the new credential, deploy, confirm reads succeed, then revoke the old one.
- Set expiry on service tokens and use
--max-ageephemeral tokens for jobs. - Move CI and Kubernetes to service account identities with exact-match audience and subject claims rather than wildcards.
- Restrict Trusted IPs on production configs by removing the default
0.0.0.0/0and adding your egress ranges; test on a staging config first, because an empty list blocks all access. - Stream activity logs to the SIEM and alert on new personal tokens, new service accounts, integration changes and secret sharing.
- Keep write access rare: service tokens are read-only unless you grant write; keep it that way.
Small teams on lower plans may lack service accounts, identities and Trusted IPs; the essentials are read-only service tokens with expiry, scanning and a rotation drill. Larger organisations should make OIDC identities the default, alert on every personal token created and review service account roles quarterly.
Framework mapping
| Control area | NIST SP 800-53 Rev 5 | NIST CSF 2.0 | ISO/IEC 27001:2022 Annex A | MITRE ATT&CK |
|---|---|---|---|---|
| Token inventory, expiry and ownership | IA-5, AC-2 | PR.AA-01 | A.5.17 Authentication information | T1078 Valid Accounts |
| No tokens in code, images and CI | IA-5(7) | PR.DS-01 | A.8.4 Access to source code | T1552.001 Credentials In Files |
| Roles, scopes and Trusted IPs | AC-6, SC-7 | PR.AA-05 | A.8.2 Privileged access rights | T1555.006 Cloud Secrets Management Stores |
| Access and activity log review | AU-6, SI-4 | DE.CM-09 | A.8.16 Monitoring activities | T1098.001 Additional Cloud Credentials |
| Revocation and downstream rotation | IR-4 | RS.MI-01 | A.5.26 Response to information security incidents | T1078.004 Cloud Accounts |
Common misconfigurations
- A developer's CLI token in a Dockerfile: write access to every project the developer can see, baked into an image layer.
- Revoking without rotating: the token is dead, but the database password it read last week is still valid.
- One service token shared by many apps: nobody revokes it because everything would break.
- Trusted IPs left at the default: every config accepts requests from the whole internet.
- Fallback files on decommissioned hosts: encrypted copies of secrets left behind after the token is gone.
- Scanner gaps: default rules catching personal tokens but not service or service account tokens.
Practitioner checklist
- Keep a prefix-to-revocation table for all seven Doppler token types in the on-call runbook.
- Scan for every
dp.prefix in repositories, images and CI logs. - Ban personal and CLI tokens outside developer machines.
- Give every service token an expiry and keep it read-only.
- Use OIDC service account identities for CI and Kubernetes.
- Restrict Trusted IPs on production configs.
- Stream activity logs and alert on token, service account and integration events.
- After revocation, rotate every secret the token could read, guided by access logs.
- Clear CLI fallback files when decommissioning hosts or after a leak.
Standards and references
- Doppler: Auth token formats
- Doppler: Service tokens
- Doppler: Service accounts
- Doppler: Service account identities (OIDC)
- Doppler: Secret access logs
- Doppler: Activity log event schema
- Doppler: Trusted IPs
- GitHub Docs: Supported secret scanning patterns
Related NHI Mgmt Group resources: Doppler, 1Password and Infisical Service Tokens Guide · Secrets Management Guide · HashiCorp credentials · Leaked Credential Response Playbook