1Password

The 1password-cli provider resolves secrets from 1Password using the op CLI binary or a self-hosted 1Password Connect server. It supports three authentication modes suited to different deployment contexts.

The 1Password provider requires the op CLI binary to be available in PATH on the platform host for service-account and cli modes. The connect mode uses the REST API and does not require the op binary.

Prerequisites

A 1Password account with a vault containing your secrets.
For service-account mode: a 1Password Service Account token.
For connect mode: a self-hosted 1Password Connect server.
The op CLI version 2.x installed on the platform host (for service-account and cli modes).

Authentication modes

service-account (recommended for production)

The Service Account token is resolved through the credential registry (from a separate rensei-encrypted row - never inline in the 1Password config row). The op CLI is invoked headlessly with the token injected via the OP_SERVICE_ACCOUNT_TOKEN environment variable.

This mode is the only safe choice for multi-tenant production deployments where the platform runs in a container without a keychain session.

cli (developer machines)

No token is injected. The op CLI uses the developer's local keychain sign-in session via --account <profile>. This mode is not appropriate for production deployments - the daemon will not have a keychain session.

connect (enterprise on-prem)

Resolves secrets against a self-hosted 1Password Connect server via its REST API. No CLI binary required. The Connect API token is stored as a separate credentials row (resolved through rensei-encrypted) and sent as a Bearer token.

This mode makes three sequential GET requests: vault lookup by name, item lookup by title, then full item fetch to extract the field by label.

Connect servers commonly terminate TLS with an internal CA. Do NOT disable TLS verification - instead, add your internal CA bundle to Node.js via NODE_EXTRA_CA_CERTS=/path/to/ca.pem.

Configuration

Field	Type	Required	Description
`authMode`	string	Yes	`service-account`, `cli`, or `connect`
`serviceAccountTokenCredentialId`	string	If `service-account`	ID of the `credentials` row holding the SA token
`account`	string	If `cli`	1Password account profile name (`op account list` to find it)
`connectUrl`	URL	If `connect`	Base URL of your Connect server (e.g. `https://connect.example.com`)
`connectTokenCredentialId`	string	If `connect`	ID of the `credentials` row holding the Connect API token
`vault`	string	Yes	Vault name in 1Password
`refreshAfterSeconds`	number	No	Override `refreshAt` hint (default 3600)
`itemRefs`	object	No	Map of `kind → op://vault/item/field` references

Item reference format

Secrets are addressed using op:// URIs:

op://<vault>/<item-title>/<field-label>

The itemRefs map keys are credential kind strings. Example:

{
  "authMode": "service-account",
  "serviceAccountTokenCredentialId": "cred_...",
  "vault": "Production Secrets",
  "itemRefs": {
    "anthropic-api-key": "op://Production Secrets/Anthropic/api_key",
    "linear-oauth": "op://Production Secrets/Linear Bot/access_token"
  }
}

Setup

Store the Service Account token in Rensei first:

curl -X POST https://rensei.ai/api/org/credentials \
  -H "Authorization: Bearer rsk_live_..." \
  -d '{ "kind": "1password-service-account-token", "value": "ops_eyJ..." }'
# Copy the returned credential ID

Configure the 1Password provider backend:

curl -X POST https://rensei.ai/api/org/credential-backend \
  -H "Authorization: Bearer rsk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "providerType": "1password",
    "config": {
      "authMode": "service-account",
      "serviceAccountTokenCredentialId": "cred_...",
      "vault": "Production Secrets",
      "itemRefs": {
        "anthropic-api-key": "op://Production Secrets/Anthropic/api_key"
      }
    }
  }'

Test the connection from Settings → Security → Credential Backend → Test Connection.

Security notes

Never store the SA token in the 1Password config row itself. The serviceAccountTokenCredentialId must point to a separate credentials row backed by rensei-encrypted.
Vault-wide blast radius. A Service Account token grants access to every vault it is a member of. Provision one SA per environment (dev/staging/prod) with least-privilege vault scoping.
Spawn latency. op read costs ~1-2 seconds on a cold cache. The refreshAt hint (default: resolvedAt + 1h) signals the dispatch adapter to cache the value for the session duration.
Stderr redaction. Service-account tokens follow the ops_<base64> shape. The provider scrubs any matching patterns from op's stderr output before surfacing errors.
Binary discovery is lazy. The op binary is probed only on the first resolve() call, not at module load. A missing binary produces a clear error: op CLI not found in PATH - install 1password-cli to use this provider.

Refresh policy

refreshAt is set to resolvedAt + refreshAfterSeconds (default: resolvedAt + 3600). 1Password has no server-side TTL signal for op read - the refresh interval is a client-side hint to re-fetch periodically.

On this page