1Password Security Guide: Service Accounts and Audit

When a 1Password account starts serving secrets to pipelines, servers and AI agents, the tokens, vault grants and admin roles around those machine identities decide how much an attacker gets from one mistake. This guide explains how to run 1Password securely for machine and team use, with 1Password's own developer and support documentation as the source for every product detail. It covers the encryption model behind vaults, service accounts and their tokens, Connect servers, the SDKs and CLI, vault permissions, the audit log and Events API, a hardening baseline and what to do when a token leaks. It is written for platform engineers, security engineers and identity teams who run 1Password Business or Teams, or are inheriting an account that already holds production secrets. For the general discipline see the Secrets Management Guide.

Key takeaways

Encryption keys never leave the client. Account data is protected by keys derived from a password and a 128-bit Secret Key that 1Password documents as created on the device and never sent to its servers, and service account tokens are generated client side in the same way.
A service account token is a complete credential. It carries the key material needed to unlock the service account's keyset, so possession of the ops_ string is enough to read every vault it was granted.
Vault grants are fixed at creation. You cannot add vaults or change permissions on an existing service account or Connect token, which forces a deliberate, narrow scope and makes the grant list the exact blast radius.
Per-vault and per-account switches give fast containment. Revoke Token cuts one token at once, and turning off service account access on a vault removes it from every service account at the same moment.
Evidence is built in, but retention is not unlimited. Item Usage Reports show what each machine identity read, the Business audit log keeps 365 days and the Events API streams events to a SIEM for longer.

The security model behind the vaults

1Password's design rests on two-secret key derivation (2SKD). The service account security page explains that a password and a Secret Key are combined to derive two values: the Account Unlock Key (AUK), which encrypts the user's personal keyset, and a Secure Remote Password (SRP) verifier used to authenticate to the service without sending the password. The personal keyset is a public and private key pair, and it is what encrypts and decrypts the vault keys the identity has been given.

The Secret Key is what makes server-side data resistant to guessing. 1Password's support article describes it as 34 letters and numbers separated by dashes, generated on the user's device when the account is set up, carrying 128 bits of entropy, and never sent to 1Password, which states that it has no record of the key and cannot recover it. The account password protects data on the user's devices; the Secret Key protects data held away from them, so an attacker who obtained 1Password's stored data could not brute-force it from a weak password alone.

Two consequences matter for operators:

Recovery is a process, not a vendor service: because 1Password cannot recover a lost Secret Key, account recovery depends on owners and administrators with recovery permission, which is why the Business security practices page asks for at least two owners and a team recovery plan.
Vault design is the access model: every human and machine reaches secrets through vault grants, so the number, scope and permissions of vaults determine least privilege more than any other setting.

Service accounts and their tokens

Service accounts are 1Password's identity for automation: a CLI session, an SDK client or a CI job that needs secrets without a person signing in. The documentation lists properties that make them safer than sharing a human account:

No human credentials: a service account needs no email address or account password. 1Password generates both its Secret Key and its password, derives the AUK and SRP verifier, and then discards the password.
Client-side token: the token is a serialized SRPx object, Base64 URL encoded, which 1Password describes as a JWT holding the AUK, the SRP value and the personal keyset. It is generated on the client, nothing sensitive is sent to 1Password, and owners and administrators cannot view it after creation. Storing it safely is the customer's job.
Recognisable prefix: tokens begin with ops_ so that code scanners can detect accidental exposure.
Bounded powers: a service account reads only from vaults where it has READ, writes only where it has WRITE, cannot create other service accounts and cannot manage users. It can optionally be given permission to create and manage vaults.
No personal vaults: the SDK documentation states that service accounts cannot reach the built-in Personal, Private or Employee vaults.
Immutable scope: after creation you cannot add vaults or 1Password Environments, change vault permissions or change the ability to create vaults. Any change means a new service account.

Who can create them

By default only owners and administrators create service accounts. They can delegate creation to groups or named people, and each delegated creator manages only their own service accounts. A creator can grant access only to vaults they can access and manage (Manage Vault in Business, Allow Managing in Teams), and no one can grant a vault on which service account access has been turned off. Keep the creation permission with a small platform group so that service accounts are created with a reviewed scope, rather than by anyone who manages a vault.

Rate limits

Service account traffic is metered, and the limits are a useful anomaly signal as well as an engineering constraint. The figures below are from 1Password's rate limits page.

Limit	Applies to	1Password Business	1Password Teams	1Password and Families
Hourly read	Each service account token, 60-minute window from first request	10,000	1,000	1,000
Hourly write	Each service account token	1,000	100	100
Daily, read and write combined	The whole 1Password account, shared by all service accounts, 24-hour window	50,000	5,000	1,000

Exceeding a limit returns HTTP 429 Too Many Requests, with a retry hint of about 59 minutes for hourly limits and about 24 hours for daily limits. op service-account ratelimit <name or ID> shows the limit, used, remaining and reset time for each limit type. Because the daily limit is shared across the account, one runaway or misused token can starve every other automation, so treat a sudden climb toward the limit as something to investigate, not only to raise.

Connect servers, SDKs and the CLI

1Password offers three ways for software to reach secrets, and each has a different credential and exposure profile.

Access path	Credential the workload holds	Where secrets are decrypted	Security characteristics from 1Password docs
CLI with a service account (`op run`, secret references)	Service account token, usually in `OP_SERVICE_ACCOUNT_TOKEN`	On the host running the CLI	`op run` loads secrets into a subprocess's environment only for its duration; supports secret references and 1Password Environments
SDKs (Go, JavaScript, Python)	Service account token, or the local desktop app integration	In the application process	Docs recommend passing the token as an environment variable, not hardcoding it; desktop app integration adds user-specific auditing and human-in-the-loop approval but can reach the user's full account
Connect server	Connect access token (bearer, ES256 signed); the server holds `1password-credentials.json`	In the Connect server inside your infrastructure	Private REST API; caches data locally so secrets can be re-requested without limit; tokens valid only for the server they were issued for; supports secret references only, not Environments

Connect server controls

The Connect security page sets out how access is enforced. Every request must carry an Authorization header with a token or it is rejected. Tokens are signed with ES256 using the key of the 1Password account the server uses, are valid only for the Connect server they were created for, cannot create other tokens and cannot be edited. Each token can be limited to a subset of the server's vaults, with READ and WRITE applied per vault as for service accounts.

Token scope: created under Developer, Connect servers, New Token. A token can be granted at most 100 vaults, and cannot be granted the built-in Personal, Private or Employee vaults or the default Shared vault.
Token expiry: Expires After can be set to 30, 90 or 180 days, after which 1Password revokes the token. Set it on every token.
The credentials file: 1password-credentials.json contains verifier (an additional check on bearer tokens), encCredentials (the encrypted credentials of the associated service account), uniqueKey (identifying the server between its client-facing and synchronisation processes), version and deviceUuid. Treat it as a secret in its own right and never store it beside the tokens.
Permissions to manage Connect: granted globally or per environment under Developer, Permissions, Secrets Automation, and can be managed through SCIM provisioning. Granular per-environment permissions need Business or Teams.
Usage reporting: Connect servers report item usage each time an item is accessed, but the report always shows Display as the action and the server's name rather than the token, data can take a few hours to appear, and usage is not reported while the server has no working connection to 1Password. Issue one token per application so that you can still attribute access.

Choosing between them

Short-lived jobs that need a few secrets: a dedicated service account per pipeline with the CLI or an SDK keeps the setup simple and makes the token the only credential to protect.
High-volume or latency-sensitive services, or Kubernetes: a Connect server inside your network caches data locally, is subject to rate limits only when it first fetches secrets, and confines each token to that server, so a stolen token is only useful to someone who can reach it.
Developer laptops and local tools: the desktop app integration keeps access tied to the signed-in person, with approval prompts and user-level audit, instead of a long-lived token on disk.

Whichever path you choose, the workload still needs its first credential from somewhere. The Secrets Zero Problem Guide covers how to deliver that token through the CI platform's secret store or an orchestrator secret rather than through code. The CLI documentation also warns that processes run by the same user can read each other's environment, so op run narrows exposure in time but does not isolate a secret from other code running as that user.

Vault permissions and least privilege

People, groups, service accounts and Connect tokens all receive access per vault, so the vault map is the access model. 1Password's Business security practices page recommends focused vaults rather than broad general-purpose ones, and notes that when a person receives permissions from several groups, the highest permission takes effect. Practical rules that follow:

One vault per application and environment: production and non-production secrets in separate vaults mean a development token never reaches production.
Machine-only vaults: keep secrets consumed by automation in vaults that only the owning service account, Connect token and a small admin group can reach.
Remove item mobility: take Copy and Share Items, Move Items and Export Items out of group grants unless a group needs them.
Restrict sensitive vaults by app: 1Password allows vault access to be limited to certain apps, for example only 1Password for Web.
Turn service account access off by default: on vaults that machines should never read, switch off service account access so nobody can grant it later by mistake.
Use custom groups for administration: limit membership of Owners and Administrators, give specific admin permissions through custom groups, and remove Create Vaults from the Team Members group.

Role or permission	What it allows for machine identities	Least-privilege setting
Owners	Full account control, recovery, all service accounts	At least two, used rarely; two-person rule for high-security accounts
Administrators	Create, view and delete service accounts, manage per-vault service account access, view audit log	Small group; responders need this role to revoke tokens they did not create
Service account creation permission	Create and manage own service accounts	Platform engineering group only
Manage Vault (Business) / Allow Managing (Teams)	Grant a service account access to that vault	Vault owners for machine vaults only
Secrets Automation permissions	Manage Connect servers and tokens globally or per environment	Per environment, through SCIM-managed groups where possible
View Administrative Sidebar	View the audit log	Read-only security staff

Audit log, usage reports and the Events API

1Password gives three layers of evidence. Use all three, because each answers a different question.

Item Usage Report (what did this identity read?): open a service account and select View Item Usage Report to see the vaults and items it can reach, where it has accessed items, when, and the action taken.
Audit log (who changed what?): available on 1Password Business, viewable by owners, administrators and members of groups with View Administrative Sidebar. It keeps 365 days of events, filters by date, actor and event type, and exports CSV with Date, Actor UUID, Actor, Action, Object Type, Object UUID, Aux Info, Aux UUID and IP Address. Vault export events are captured only from devices on 1Password 8.4.0 or later.
Events API (stream it out): an Events Reporting integration token can be scoped to sign-in attempts, item usages and audit events (all three are selected by default). Tokens are saved as API Credential items, can expire after 30, 90 or 180 days or never (the default), and can be checked with GET /api/v2/auth/introspect, which returns the token's UUID, issue date and scoped features, or 401 if invalid.

The Business security practices page adds that sign-in attempts are kept for 60 days, so Events Reporting is how you keep them longer, and recommends usage reports for high-privilege people and high-value vaults, plus regular runs of the developer secrets discovery report.

Detection	Source	Why it matters
Service account reads items its workload never uses	Item Usage Report, item usage events	Classic sign of a token being used outside its job
Token registered, rotated or revoked outside a change window	Audit events	Unplanned changes to machine identities need an owner and a ticket
Vault access or service account toggle changed on a production vault	Audit events	Widening a grant is how quiet escalation starts
HTTP 429 or a sharp rise in read counts for one token	CLI or SDK errors, `op service-account ratelimit`	A token doing far more than its workload suggests bulk reading
Failed or unusual sign-in attempts on owner and admin accounts	Sign-in attempt events	Admin accounts control every machine identity
Vault exports	Audit events	Bulk removal of secrets from the platform

Metrics that show the programme is working:

Share of service accounts used by exactly one workload (target: all).
Connect and Events API tokens with no expiry (target: zero, or documented exceptions).
Items each service account has accessed compared with items it can access, trending toward parity.
Median time from a secret scanning alert for ops_ to Revoke Token or Rotate Token.
Production vaults with service account access switched off unless a named workload needs it.
Days of audit and item usage history available in the SIEM, compared with your retention requirement.

Responding to a leaked token

Detection usually comes from secret scanning: the Gitleaks default rules include 1password-service-account-token (keyword ops_) and 1password-secret-key (keyword a3-), and the Git Secret Scanning Guide explains how to run them on push. Connect tokens, 1password-credentials.json and Events API tokens need custom rules matching your file and variable names. Then work through the steps below; the Leaked Credential Response Playbook covers the general pattern.

Classify: ops_ is a service account token; a bearer token used against your Connect host, or the credentials file, belongs to a Connect server; a token in an Events Reporting integration is an Events API token; an A3- value is a person's Secret Key.
Contain a service account token: if there is any sign of use by someone else, or the token was public, select Revoke Token on the service account; access stops immediately. If the exposure was internal and nothing suggests use, select Rotate Token, which issues a new token with the same permissions, and set the old token to expire now, in 1 hour, in 3 days or at a chosen time, as short as redeployment allows.
Contain when the token is unknown: turn off service account access on the affected vaults. That removes access for every service account on those vaults at once; re-enable it per vault after rotation.
Contain a Connect token: create a new token, update every reference, then revoke the old one, as 1Password recommends. If the credentials file leaked too, treat the server's associated service account credentials as exposed and replace the Connect server.
Contain an Events API token: issue a replacement and update the SIEM first, then revoke the old token, because revoking first stops ingestion.
Scope: the token's vault grants are the full exposure. Use the Item Usage Report and item usage events to list items actually accessed since the exposure began; usage from a Connect server may lag by hours.
Rotate downstream: rotate every accessed item at its issuer first, then the rest of the vault by priority. Record the work in the Secrets Rotation Runbook Template.
Fix the cause: move the token into the CI platform's secret store or an orchestrator secret, mask it in logs, and if the service account served several workloads, split it so the next revoke breaks only one.
Verify: confirm the old token no longer authenticates and that consumers recovered, and keep the audit export with the incident record.

A Secret Key on its own does not unlock an account, because it must be combined with the account password. If both may be exposed, handle it as an account compromise. 1Password's Business guidance for a compromised device is to suspend the account, reset the email password, then reactivate and fully recover the account, noting that a password change alone is not enough.

Hardening baseline and rollout

Inventory: list every service account, Connect server and token, and Events Reporting integration with its owner, workload, vaults, permissions and expiry. Flag shared service accounts and tokens with no expiry.
Secure the people layer first: keep two or more owners, require two-factor authentication (authenticator app or hardware security key), set the account password and auto-lock policies, keep recovery permission away from email administrators, and turn on the local disk scanning policy to find plaintext developer secrets.
Restructure vaults: split broad vaults into per-application, per-environment vaults; remove Copy and Share, Move and Export Items from groups that do not need them; switch off service account access on vaults machines should never read.
Pilot narrow service accounts: for one pipeline, create a new service account with only its vaults, read-only where possible, run it alongside the old credential and check the Item Usage Report until only the new account is used.
Migrate and retire: move workloads one at a time, then revoke the shared token. Rolling back means re-deploying the previous token, so keep it valid but monitored until consumers confirm, using Rotate Token's delayed expiry as the safety net.
Set expiries: 30 to 90 days on Connect and Events API tokens, and a scheduled Rotate Token for service accounts.
Stream events: connect Events Reporting to the SIEM with scoped tokens and build the detections in the table above.
Rehearse: rotate a staging token with a three-day grace, then with immediate expiry, to learn what breaks before an incident forces it.

Small and large organisations: a small team gains most from one service account per workload, ops_ scanning in CI and a monthly look at Item Usage Reports. A large organisation should run Connect servers for high-volume services, manage Secrets Automation permissions per environment through SCIM-provisioned groups, keep the audit log and item usage in the SIEM beyond the 365-day window and review service account scopes every quarter.

The Akeyless, Doppler and 1Password Machine Access Guide sets 1Password's service accounts beside the equivalent machine access models, and each platform has its own security guide: the Akeyless Security Guide and the Doppler Security Guide.

Framework mapping

1Password control	NIST SP 800-53 Rev 5	NIST CSF 2.0	ISO/IEC 27001:2022 Annex A	MITRE ATT&CK (threat addressed)
Service account inventory, expiry, rotate and revoke	AC-2, IA-5	PR.AA-01	A.5.17 Authentication information	T1078.004 Cloud Accounts
Tokens kept out of code, images and logs; `ops_` scanning	IA-5	PR.AA-01	A.8.4 Access to source code	T1552.001 Credentials In Files
Per-workload vaults, READ only grants, per-vault toggle	AC-6	PR.AA-05	A.8.2 Privileged access rights	T1555 Credentials from Password Stores
Item Usage Reports, audit log, Events API to SIEM	AU-6, SI-4	DE.CM-09	A.8.16 Monitoring activities	T1528 Steal Application Access Token

Common failure patterns

One service account for many pipelines: because scope cannot be changed later, teams reuse an old broad account, and then nobody can revoke it without breaking everything.
Tokens printed in CI output: the token alone unlocks its vaults, so a debug line or an unmasked variable is a full exposure.
The Connect credentials file beside the tokens: one repository or backup leak then exposes both halves of the Connect deployment.
Events API tokens left on Never: it is the default and is rarely revisited.
Everyone can create service accounts: delegation to broad groups produces accounts nobody owns, created against whichever vaults the creator happened to manage.
Relying on the 365-day audit log alone: without Events Reporting to a SIEM, older evidence and sign-in attempts beyond 60 days are gone when an investigation needs them.

Practitioner checklist

Inventory every service account, Connect token and Events API token with owner, workload, vaults and expiry.
Restrict service account creation to a platform group and keep Owners and Administrators small.
Give each workload its own service account and vaults, read-only wherever writing is not needed.
Switch off service account access on vaults that machines should never read.
Set Expires After on every Connect token and an expiry on every Events API token.
Store tokens in the CI or orchestrator secret store, mask them, and scan for ops_, A3- and 1password-credentials.json.
Know the Revoke Token, Rotate Token and per-vault switch paths, and rehearse them.
Review Item Usage Reports monthly and after any exposure.
Stream audit, item usage and sign-in events to the SIEM through Events Reporting.
Require two-factor authentication and keep at least two owners with a tested recovery plan.

1Password Security Guide: Service Accounts, Connect, Vaults and Audit