A leaked 1Password machine credential is a leak of every secret in the vaults it can read, because a service account token carries the key material needed to decrypt those vaults on its own. Teams adopt 1Password service accounts and Connect servers precisely to get secrets out of code, and then the token that unlocks them ends up in a CI variable, a Kubernetes manifest or a developer's shell history. This guide covers the 1Password credentials that matter in a leak (service account tokens, Connect server access tokens and credentials files, Events API tokens and a person's Secret Key), how to recognise each one, what it reaches, where 1Password records its use, and how to revoke, rotate and contain the exposure from 1Password's own documentation. It is written for platform, DevOps and security teams that run 1Password Teams or Business. For the design of service accounts alongside Doppler and Infisical, read the Doppler, 1Password and Infisical Service Tokens Guide first; this page goes deeper on response.
Key takeaways
- Tokens are self-contained. A service account token (prefix
ops_) embeds the account unlock key material and Secret Key for the service account, so possession is enough to read its vaults; 1Password generates it on the client and never stores it. - Revoke is instant, rotate has a grace period. Revoke Token cuts access at once; Rotate Token issues a new token with the same permissions and lets you choose when the old one expires, such as now, in one hour or in three days.
- The vault list is the blast radius. Service account and Connect token vaults cannot be changed after creation, so the vaults granted at creation are exactly what is exposed.
- Usage reports tell you what was read. Each service account's Item Usage Report shows which vaults and items it accessed and when, which turns a vague exposure into a precise rotation list.
- Rotate the secrets, not just the token. If a token was used by someone else, every item it accessed must be rotated at its issuer.
How identity and access work in 1Password
People unlock 1Password with their account password combined with a Secret Key; machines use service accounts, Connect servers or Events API integrations. The credentials behave very differently:
| Credential | How to recognise it | What it reaches | Lifetime | Managed at |
|---|---|---|---|---|
| Service account token | Begins ops_ followed by a long Base64 URL-encoded JWT; commonly in OP_SERVICE_ACCOUNT_TOKEN | The vaults granted to the service account, with READ and, where granted, WRITE | Until revoked; an expiry is set when rotating | Developer, Service accounts on 1Password.com |
| Connect server access token | Bearer token signed with ES256, valid only for its own Connect server | Up to 100 vaults chosen at creation, through that Connect server | 30, 90 or 180 days if Expires After is set | Developer, Connect servers |
| Connect credentials file | 1password-credentials.json with verifier, encCredentials, uniqueKey, version, deviceUuid | The Connect server's encrypted credentials for its associated service account | Life of the Connect server | Created with the Connect server |
| Events API token | JWT bearer token, saved as an API Credential item | Sign-in attempts, item usage and audit events, as scoped (signinattempts, itemusages, auditevents) | 30, 90 or 180 days, or Never (the default) | Integrations, the Events Reporting integration |
| Secret Key (a person's) | 34 letters and numbers separated by dashes, beginning with a version such as A3- | Nothing alone; with the account password it derives the key that protects the user's data | Until regenerated | The user's account |
The Secret Key adds 128 bits of entropy so that data held on 1Password's servers cannot be brute-forced from a password alone. Its exposure is therefore serious only together with the account password, as in the LastPass breach, where a keylogger on a DevOps engineer's home computer captured a master password and opened a corporate vault holding cloud keys. See the Password Manager Vault Breach Response Playbook for the human-account path; the rest of this page focuses on machine credentials.
Admin roles and privileged access
| Who | Credential powers | Note |
|---|---|---|
| Owners and administrators | Create and manage all service accounts; turn service account access on or off per vault; view the audit log | Responders need one of these roles to revoke tokens they did not create |
| Members granted service account permission | Create service accounts (granted by group or person at Developer, Permissions, Service Account) and manage only their own | Grants should go to a small platform group, not everyone |
| Vault managers | Grant a service account access to a vault they manage (Allow Managing in Teams, Manage Vault in Business) | A creator can only grant vaults they can already manage |
| Members with View Administrative Sidebar | View the audit log | Useful for read-only security staff |
The per-vault switch for service account access is a strong containment tool: turning it off removes access for every existing service account on that vault at once, which is useful when you cannot yet tell which token leaked. Connect servers cannot be granted the Personal, Private, Employee or default Shared vault. The Privileged Access Management Guide covers how to govern the owner and administrator tier.
Integrations, API tokens and service accounts
Which credential for which job
| Use case | Prefer | Leak consideration |
|---|---|---|
| CI job or script fetching a few secrets | Service account per pipeline, with only its vaults, read-only where possible | The token alone decrypts the vaults, so keep it in the CI secret store and mask it in logs |
| Kubernetes or a service with many readers | Connect server inside your network, token per application with an expiry | An exposed token works only against its own Connect server, so network placement limits who can use it |
| SIEM ingestion | Events API token with only the scopes the SIEM needs and an expiry | Exposes activity data, not secrets, but reveals who accessed what |
| Multiple environments | Separate service accounts and vaults for production and non-production | A development token leak then never reaches production secrets |
Because vault grants are fixed at creation, teams sometimes reuse an old, broad service account rather than create a narrow one. That reuse is what turns a single leak into a full rotation. Create a new service account for each workload. The Credential Vaulting for AI Agents Guide applies the same idea to agents that call 1Password.
Logging and detection
Recognising 1Password secrets
| Detector | Rule or type | Coverage |
|---|---|---|
| GitHub secret scanning | 1password_service_account_token | Private repositories with GitHub Advanced Security, push protection; no validity check and not a public partner pattern |
| Gitleaks default rules | 1password-service-account-token (keyword ops_) | Service account tokens |
| Gitleaks default rules | 1password-secret-key (keyword a3-) | Personal Secret Keys |
| Custom rule needed | Connect tokens, 1password-credentials.json, Events API tokens | Match the file name and your variable names |
No public repository partner coverage exists for 1Password tokens, so a token pushed to a public repository will not be revoked for you. The ops_ prefix exists, in 1Password's words, so code analysers can detect accidental exposure: make sure your scanners use it. See the Git Secret Scanning Guide.
Where misuse shows
- Item Usage Report: on a service account's overview page, View Item Usage Report lists the vaults where it accessed items, the items, when they were last accessed and the action performed. Access to items the workload never uses is the clearest signal.
- Connect usage: Connect servers report item usage, which can take a few hours to appear; the Used by field shows the server name, not the token, so keep one token per application to stay attributable.
- Audit log (Business): records adding service accounts, registering, updating and revoking tokens, and vault access changes, with actor and IP address, for 365 days. Owners and administrators view it and can export CSV.
- Events API: stream audit events and item usage into the SIEM for longer retention and alerting.
- Rate limit errors: a token that suddenly hits limits is doing far more than its workload needs.
Metrics
- Service accounts with more than one consuming workload, trending to zero.
- Connect and Events API tokens without expiry.
- Items accessed by each service account versus items its workload needs.
- Mean time from a secret alert to Revoke Token.
- Share of production vaults with service account access switched off unless required.
Leak response: revoke and rotate
- Classify the secret:
ops_is a service account token; a1password-credentials.jsonfile or a Connect bearer token belongs to a Connect server; an Events API token sits in an Integrations item; anA3-value is a person's Secret Key. - Service account token, likely used by an attacker: go to Developer, Service accounts, open the account and select Revoke Token. Access stops immediately. Then create a new service account if the vault scope should change.
- Service account token, exposed but not obviously used: select Rotate Token, set Expire existing token to the shortest window your deployment allows, save the new token and redeploy. Rotation keeps the same permissions.
- Unknown which token: turn off service account access on the affected vaults to cut every service account at once, then re-enable per vault after rotation.
- Connect server: create a new token, update all references and revoke the old one from its menu, as 1Password recommends. If the credentials file also leaked, treat the Connect server's service account as exposed and replace the server.
- Events API token: add a replacement token first, update the SIEM, then revoke the old one; revoking first stops ingestion.
- Secret Key with password exposure: handle it as an account compromise: change the account password, regenerate the Secret Key and review the user's devices, following the password manager playbook.
- Rotate exposed secrets: use the Item Usage Report to list items accessed since exposure and rotate each at its issuer, then the rest of the vault by priority. Record the work in the Secrets Rotation Runbook Template.
Revoke or rotate: deciding quickly
Choose revoke when the Item Usage Report or audit log shows access you cannot explain, when the token was posted publicly, or when the workload can tolerate a short outage. Choose rotate with a short grace window when the exposure was internal (a private repository, a CI log seen only by staff) and nothing suggests use, because it keeps production running while the new token rolls out. In either case the decision about the secrets inside the vaults is separate: unexplained item access means those items are rotated whatever you did with the token, and a public exposure of a token with WRITE access also means checking items for unexpected changes.
Hardening baseline
- Inventory: list service accounts, Connect servers and tokens, and Events API integrations; record owner, workload, vaults and expiry.
- Split shared service accounts: create one per workload with only its vaults, migrate, verify, then revoke the old token.
- Set expiries: use 30 to 90 days for Connect and Events API tokens; rotate service account tokens on a schedule with a short grace window.
- Restrict creators: keep the service account permission to a platform group.
- Switch off service account access on vaults that should never be read by machines.
- Stream events: connect Events Reporting to the SIEM and alert on token registration and revocation outside change windows.
- Rehearse: run a rotation with a three-day grace in staging, then with "now" to learn what breaks.
Small teams can stop at one service account per workload, secret scanning for ops_ and regular Item Usage Report reviews. Larger organisations should run Connect servers for high-volume services, use the audit log and Events API, and review service account permissions quarterly.
Common misconfigurations
- One service account for many pipelines: nobody can revoke it without breaking everything.
- Tokens printed in CI logs: the token alone decrypts its vaults.
- Connect credentials file stored next to the token: one repository or backup leak then exposes both.
- Events API tokens set to Never: the default, and rarely revisited.
- Revoking without checking usage: the Item Usage Report is the evidence that drives secret rotation.
- Production and development secrets in one vault: the blast radius of any token is then production.
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 revocation | IA-5, AC-2 | PR.AA-01 | A.5.17 Authentication information | T1078.004 Cloud Accounts |
| No tokens in code, manifests or logs | IA-5(7) | PR.AA-01 | A.8.4 Access to source code | T1552.001 Credentials In Files |
| Vault scoping per workload | AC-6 | PR.AA-05 | A.8.2 Privileged access rights | T1555 Credentials from Password Stores |
| Usage reports, audit log and SIEM | AU-6, SI-4 | DE.CM-09 | A.8.16 Monitoring activities | T1528 Steal Application Access Token |
Practitioner checklist
- Inventory every service account, Connect token and Events API token with owner and vaults.
- Give each workload its own service account and vaults.
- Scan for
ops_,A3-and1password-credentials.jsonin code, images and backups. - Set expiries on Connect and Events API tokens.
- Know the Revoke Token and Rotate Token paths, and when to use each.
- Know how to switch off service account access per vault in an emergency.
- Review Item Usage Reports after any exposure and rotate the items accessed.
- Send audit events to the SIEM to keep more than 365 days.
Standards and references
- 1Password Developer: Manage service accounts
- 1Password Developer: Service account security
- 1Password Developer: Manage Connect servers
- 1Password Developer: Connect server security
- 1Password Developer: Events API authorization
- 1Password Support: About your Secret Key
- 1Password Support: Audit log
- GitHub Docs: Supported secret scanning patterns
Related NHI Mgmt Group resources: Doppler, 1Password and Infisical Service Tokens Guide · Leaked Credential Response Playbook · Password Manager Vault Breach Response Playbook · Secrets Management Guide