pass vs 1Password for agent workflows

When you automate credentials for AI agents, the store debate usually comes down to two very different answers: pass, the unix password manager built on GPG-encrypted files, and 1Password, the commercial vault with apps, sync, and a CLI. Both work with agents; they disagree about almost everything else, and the disagreement matters more for automation than for human use.

The core difference: where the secret lives

pass is local and static: GPG-encrypted files in ~/.password-store, decrypted on demand with your key. 1Password is a vault that syncs from a server, and the CLI (op) talks to the vault through the 1Password app or a service account token. That one architectural difference drives every other comparison.

For humans, 1Password is usually more convenient: browser integration, mobile apps, recovery when a laptop dies. For agents, the question is whether a non-interactive process can read the store.

Non-interactive access

Agents cannot type passwords or approve unlock prompts. This is the make-or-break requirement.

• pass reads non-interactively once your GPG key is unlocked by gpg-agent — one setup step, then every read is silent. No session to refresh, no token to rotate.
• 1Password requires either an unlocked desktop app (a human session, with its security posture) or a scoped service account token. The token path works for automation, but it is a second credential to store and rotate — an API key guarding your API keys.

For unattended runs on a machine you control, pass has less moving state. For a CI box or container where your GPG key cannot exist, a scoped service account token is the workable 1Password answer.

Injection and the context window

Storing a secret is not delivering it safely. Both CLIs return values to stdout — pass show <name> and op read — so an agent that can run either command can read every secret it can name. The safe pattern is a broker that injects values into subprocess environments and sanitizes stdout and stderr, so plaintext never lands in the context window or in logged tool output.

Both can sit behind that pattern, but the integration surface differs. pass is files and GPG — the path of least resistance for local tooling. 1Password’s CLI adds session management: unlock state or token handling, plus expired sessions, mis-scoped tokens, and interactive prompts that hang automation.

Other dimensions

• Sync and recovery. 1Password wins: built-in sync, recovery codes, and a documented path back from a dead machine. pass syncs only if you set it up, and losing the GPG key without a backup is fatal.
• Structure. 1Password entries have typed fields and attachments; pass entries are flat files, often with one value per line.
• Operational footprint. pass is a shell script plus GPG; 1Password is an app, a CLI, a daemon, and a cloud account.
• Team use. 1Password has sharing and access controls; pass sharing means shared git repos or GPG key distribution.

A workable default

If your agents run on your own machines and you want the least moving state, pass is the lower-friction choice. If you already live in 1Password, keep it and treat the CLI as the agent-facing front door — make session and token handling explicit and fail-closed, and prefer a scoped service account token over the unlocked app. trustless reads your existing pass store by default and handles the injection and sanitization layers; the store stays yours, whatever it is.

The store is a means to an end: the agent should get access, never the plaintext. Which side of that trade — local simplicity or managed sync — matters more in your setup?