1Password Is Not an Agent Secret Store
1Password Is Not an Agent Secret Store
I kept seeing this dialog while working with Claude Code:
It is the right security boundary for a person. I want 1Password to ask before a terminal gets access to a vault.
It is the wrong recurring interface for an agent. A task may need several credentials, retry halfway through, or run when I am nowhere near the Touch ID prompt. In my setup, terminal approval expires after about ten minutes. One missed dialog stops the work.
A cache was the bridge
op-toolkit started as a way to authorize one vault read, cache it locally for my user session, then let Claude Code resolve later op:// references without triggering another prompt.
That makes an attended session tolerable. It is not a new security boundary: the cache is local plaintext JSON protected by filesystem permissions. A process that can read it can read its secrets.
That is why it was a bridge, not the final design.
Human secrets and machine secrets are different jobs
Runtime infrastructure secrets moved to OpenBao. 1Password stayed useful for recovery, break-glass access, and normal human autofill.
OpenBao is the source of truth for machine workloads. If it is mirrored into 1Password, the mirror is a recovery copy, not a second writable database. Fix the source and run the mirror.
One gotcha from the migration: OpenBao KV custom metadata did not reach the 1Password mirror. Descriptions a person needs during recovery must be regular data fields.
The agent should not have to infer this from a list of shell commands. Put it in the repository it works in.
| Workload | Identity | Secret path | Human approval | Source of truth |
|---|---|---|---|---|
| Recovery or normal human work | a person | 1Password | Touch ID / desktop approval | 1Password |
| Attended agent task | a person authorizing a local session | op-toolkit cache | once per cache warm | 1Password |
| Service or unattended automation | workload identity with narrow policy | OpenBao | no desktop prompt | OpenBao |
The agent interface is CLAUDE.md
## Secret workflow
- Follow the installed op-toolkit skill.- 1Password is for human recovery and autofill.- OpenBao owns runtime service secrets.- Never fetch or modify 1Password data through raw `op` commands.- Use this repository's approved OpenBao workflow for infrastructure secrets.- Never print, log, chat, commit, or copy secret values.Then prompts describe the outcome, not the command sequence:
Deploy this service using the approved secret path from this repository's policy. Use the credential only in the deploy command. Do not echo, log, or repeat it in chat.Add a description and consumer to myapp/db using the approved OpenBao metadata workflow. Do not change credential fields. Report changed keys, never values.That second prompt matters. A task such as “document this secret” should not grant permission to rotate, reveal, or overwrite it.
The useful question
The cache fixed a human interaction problem. OpenBao fixed a machine-access problem.
For agents, the next question is not: How do I give it the password?
It is: What narrowly scoped authority does it need for this operation, for how long, and how can I revoke or audit it afterward?
That is the direction: human approval for human decisions, machine access for machine workloads, and agents constrained by policy instead of handed reusable credentials.
Install op-toolkit from Claude Code:
> /plugin marketplace add tanguc/claude-marketplace> /plugin install op-toolkit@tanguc
> Deploy this service using the approved secret path from this repository's policy.The plugin source documents the implementation. The repository policy above tells an agent how to use it.