Doppler, 1Password and Infisical Service Tokens Guide: Securing the Keys to Your Secrets Manager

A secrets manager protects every other credential, but the token an application uses to reach it is itself a secret, and when that token leaks the attacker gets the whole vault it can read. Doppler service tokens, 1Password service account tokens and Infisical machine identity credentials are the "secret zero" of many modern stacks: they sit in CI variables, Kubernetes secrets, .env files and container environments, often with no expiry and broad read access. This guide explains how each product models machine access, which token types exist and what they can reach, the options for scoping, expiry and network restriction, how leaked tokens are detected, and a hardening baseline. It is for platform, DevOps and security engineers who run these tools. For the wider discipline see the Secrets Management Guide and the Secrets Zero Problem Guide.

Key takeaways

• Use the machine identity type, not a person's token. Doppler personal and CLI tokens carry their creator's permissions and write access; use service tokens or service accounts. Infisical has deprecated service tokens in favour of machine identities.
• Scope is decided at creation. A 1Password service account's vaults and permissions cannot be extended after creation, and a Doppler service token is bound to one config; design narrow tokens per workload and environment.
• Defaults are permissive. Infisical Universal Auth client secrets never expire and accept any source IP by default; 1Password and Doppler tokens have no expiry unless you set one.
• Federate where you can. Doppler service account identities and Infisical's cloud and OIDC auth methods swap a stored secret for a short-lived token proved by the platform's own identity.
• Detection is uneven. Doppler tokens have distinct prefixes and GitHub partner coverage with validity checks; 1Password service account tokens are detected by GitHub only in private repositories with Advanced Security; Infisical has no GitHub pattern at all.

How identity and access work in Doppler, 1Password and Infisical

The 1Password design point deserves emphasis: because the service account token contains key material, possession of the token is enough to decrypt the vaults it was granted. 1Password generates it on the creating device and never sends it to its servers, so storage and protection are entirely the customer's responsibility.

Admin roles and privileged access

• Doppler: creating service accounts needs the Admin role or the Manage Service Accounts permission, and service accounts require a Team or Enterprise plan. New service accounts start with no workplace role; grant project access per project and environment from the project's Members tab. Treat Admin and Manage Service Accounts as privileged roles and review them.
• 1Password: an administrator must give a user permission to create and manage service accounts. The creator can only grant access to vaults they can access themselves, and a vault can be configured to refuse service accounts entirely; switching this off removes access for existing service accounts. Service accounts cannot reach Personal, Private, Employee or the default Shared vault, cannot create other service accounts and cannot manage users.
• Infisical: organisation identities are created centrally and added to projects; project identities live in one project. Whoever can create identities or attach auth methods can mint credentials, so restrict the organisation admin role and use custom roles for machine identities.
• Human tokens are privileged too: Doppler personal (dp.pt.) and CLI (dp.ct.) tokens act with the full permissions of the person who created them. Doppler's own documentation advises against using them in live environments.

Keep a vault or project dedicated to production machine secrets, so a token for a staging workload cannot read production. See the OWASP NHI Top 10 NHI8 Environment Isolation Guide.

Integrations, API tokens and service accounts

Choosing the right credential

Scoping and lifetime settings

• Doppler service tokens: one per config and consumer; set an expiry; for jobs, create ephemeral tokens with --max-age so they delete themselves. Revoking is immediate, but Doppler warns that the CLI's encrypted fallback file on disk can still expose the last fetched secrets, so clear fallback files on decommissioned hosts.
• Doppler service account identities: require audience and subject claims, add claims such as GitLab's environment, and avoid wildcards. The short-lived token returned by https://api.doppler.com/v3/auth/oidc should not be persisted.
• 1Password service accounts: plan vault grants carefully because they cannot be added later; create a new service account rather than widening an old one. Set --expires-in and expose the token only as OP_SERVICE_ACCOUNT_TOKEN in the process that needs it. Rate limits apply per token (on Business, 10,000 reads and 1,000 writes per hour) and per account per day (50,000 requests on Business), which also limits how fast a stolen token can be used for bulk export.
• Infisical Universal Auth: change the defaults. Set a client secret TTL and a maximum number of uses, set an access token TTL and max TTL suited to the workload (the docs list a 30 day max TTL default), and set trusted IPs for both client secret and access token instead of 0.0.0.0/0. Migrate any remaining service tokens, which Infisical says will be removed in a future release.

Every product here can answer the secret zero problem the same way: let the workload prove who it is with an identity it already has (an OIDC token from the CI platform, a Kubernetes service account, a cloud role) instead of a stored secret. See the Workload Identity Federation Guide.

Logging and detection

Leak detection coverage

Coverage was checked on 27 October 2026 against GitHub's pattern data, the Gitleaks default configuration and TruffleHog's detectors. Two practical consequences follow. First, a Doppler service token (dp.st.) committed to a repository scanned only by default Gitleaks will not be flagged; add a custom rule for all the documented prefixes. Second, Infisical Universal Auth client secrets have no distinctive format in these tools, so protect them with short TTLs, use limits and IP restrictions rather than relying on scanning. The 230 Million AWS Cloud Environments Campaign 2024 shows where these tokens leak in practice: publicly reachable .env files holding long-lived keys and API tokens.

What to monitor

• Token creation and deletion events in each product's activity or audit log, especially new tokens on production configs or vaults.
• Use from unexpected networks: source IPs outside your CI and runtime ranges.
• Volume anomalies: a read token suddenly listing every secret, or 1Password rate limit errors from a token that normally makes a few calls.
• Human tokens in automation: personal or CLI token use from servers.
• Stale credentials: tokens unused for 90 days.

Metrics

• Share of machine access using federated or short-lived credentials.
• Long-lived tokens with no expiry (target: trending to zero).
• Tokens with access to more than one environment.
• Mean time to revoke after a leak alert.
• Infisical identities still on default trusted IPs.

Hardening baseline

1. Inventory: list every service token, service account and machine identity, with owner, workload, scope, expiry, creation date and last use. See the Service Account Inventory Template.
2. Remove human tokens from automation: replace Doppler personal and CLI tokens on servers and CI with service tokens or service accounts.
3. Federate CI first: pilot OIDC for one GitHub or GitLab pipeline (Doppler service account identities, or an equivalent Infisical auth method), confirm builds still fetch secrets, then delete the stored token. Keep the old token, with a short expiry, until the pipeline has run successfully for a release cycle.
4. Narrow the rest: one credential per workload and environment, read-only unless writes are required, with expiry set.
5. Restrict networks: use Infisical trusted IPs and, for all three, keep the secrets manager reachable only from the networks that need it where your deployment allows.
6. Protect the token where it lives: CI secret stores with masking, Kubernetes secrets with RBAC limited to the consuming service account, no tokens in images, repositories or .env files served by web servers.
7. Detect: enable push protection and add custom rules for dp.st., dp.sa. and ops_ where your scanner lacks them.
8. Rotate on a schedule and on events: roll Doppler service account tokens, rotate 1Password tokens and Infisical client secrets, and rehearse revocation so you know which workloads break.

A small team can complete steps 1, 2, 4 and 7 in a day. Larger organisations should standardise one pattern per platform (for example, OIDC for CI, Kubernetes auth for clusters) and block creation of non-expiring tokens through policy and review.

Framework mapping

Reuse is the quiet failure here: when one Doppler service token or 1Password service account serves several applications, nobody can revoke it without breaking all of them, so it never gets revoked. See the OWASP NHI Top 10 NHI9 NHI Reuse Guide. The matching ATT&CK techniques are T1552.001 Credentials In Files, T1552.007 Container API and T1078 Valid Accounts.

Common misconfigurations

• A personal token in production: it works, so it stays, and when its owner leaves or is phished the attacker inherits their write access.
• One token for every environment: a staging leak exposes production secrets.
• Infisical defaults left on: client secrets that never expire, unlimited uses and 0.0.0.0/0 trusted IPs.
• Widening by sharing: because 1Password service account vault access cannot be extended, teams reuse an older broad service account instead of creating a narrow new one.
• Scanner gaps assumed away: relying on default Gitleaks rules that do not match Doppler service tokens or any Infisical credential.
• Revocation without cleanup: revoking a Doppler token but leaving the CLI fallback file, or leaving the old token in CI variables, images and backups.

Practitioner checklist

• Inventory every Doppler, 1Password and Infisical machine credential with owner, scope, expiry and last use.
• Replace personal and CLI tokens in automation with service tokens, service accounts or machine identities.
• Move CI and cloud workloads to OIDC or platform auth methods and delete the stored tokens.
• Issue one credential per workload and environment, read-only by default, always with an expiry.
• Change Infisical Universal Auth defaults: client secret TTL, use limits, token TTLs and trusted IPs.
• Keep production secrets in vaults or configs that non-production credentials cannot reach.
• Add scanner rules for dp.st., dp.sa. and ops_ and enable push protection.
• Alert on token creation, use from unknown networks and unusual read volume.
• Rehearse revocation, including fallback files and copies in CI, images and backups.

Standards and references

• Doppler Docs: Service Tokens
• Doppler Docs: Auth Token Formats
• Doppler Docs: Service Account Identities
• 1Password Developer: Service account security
• 1Password Developer: Service account rate limits
• Infisical Docs: Machine Identities
• Infisical Docs: Universal Auth
• GitHub Docs: Supported secret scanning patterns

Related NHI Mgmt Group resources: Secrets Management Guide · Secrets Zero Problem Guide · HashiCorp Vault Guide · Cloud Secrets Managers Guide · Kubernetes Secrets Security Guide