October 11, 2026

How My Agents Use My Passwords

Eight Claude Code sessions run on a laptop in my house. They build features, merge pull requests, stage releases, verify deploys against production, publish help pages, and post status on GitHub. To do that they need real credentials: GitHub, the cloud account, the hosting provider's CLI, error tracking, the blog, an App Store key. For about a month now they have had all of them, and I have not typed a secret into a session once. This is how it works, and where it stops.

What I wanted

I wanted to stop doing data entry for my own agents. Every time a script needed a token, I was the one fetching it from 1Password and pasting it somewhere, usually into a chat window, which is the worst place a secret can go. A chat transcript is a file. It is stored. It gets summarized. Anything pasted into it is in it forever.

I also wanted to stop being the thing that pulls the agents back to the desk. I run most of my day from my phone. If an agent can only get a credential while I am at the Mac with my thumb on the sensor, the agents only work while I am at the Mac.

The shape

Three pieces, all of them things that already exist.

1Password is the source of truth. Every credential lives there, in shared vaults, with a named field per machine where that matters.

A read-only service account per machine. 1Password lets you create a service account: a token that can read vaults without a person present. I create one per Mac, named after the machine, read-only, scoped to the few shared vaults the agents need. It cannot see my private vault at all; service accounts never can. If one machine is compromised, I revoke one token and the others keep working.

The macOS login keychain is the cache. The service-account token itself goes into the login keychain under a name the scripts know. So does every credential a script reads often. Scripts read the keychain per call. Nothing is exported in a shell profile, because a global export would hijack my own interactive 1Password, which still asks for Touch ID when I use it.

Seeding the keychain is the only step that touches a secret, and it is done in one pipeline so the value never prints:

security add-generic-password -U -a "$USER" -s NAME_OF_SECRET \
  -w "$(op item get "Item name" --vault "Vault name" --fields "Field name" --reveal)"

The value flows from 1Password straight into the keychain. The agent runs that command. The agent never sees the output, because there is none.

Verify by use, never by the seed

This is the rule I would have paid to learn earlier. Seeding a keychain entry fails in three ways that all look like success, with exit code zero and no error:

  • The prompt form of the command, -w with nothing after it, stores an empty string when there is no terminal to type into. Agent sessions have no terminal. It created the entry twice in one afternoon before I caught it.
  • pbpaste stores whatever was copied last. Copy the command out of a chat to run it, and the command is what gets stored.
  • The 1Password field holds a stale value, or a value for the wrong account. Right shape, rejected by the API.

Length is not a signal either. A working token and a dead one were both 53 characters. The only check that means anything is one authenticated call: op whoami must say SERVICE_ACCOUNT, the hosting CLI must list a real deploy, the error-tracking token must return the account. Every credential on every machine got that check before anything depended on it.

What it bought me

Yesterday I moved the whole fleet of agents from a Mac mini to a laptop. The setup walk checked every credential the agents use. All of them were already in the laptop's keychain from an earlier session and each passed its read-only call. I did not open 1Password. I did not touch the sensor. The agents were reading production within the hour, from a session I was watching on my phone.

Since then, I have needed to be at the computer for exactly two kinds of thing: a secret that lives in my private vault, which the service account cannot read by design, and signing in after a reboot, because FileVault keeps the keychain locked until someone does.

What it does not do

It does not prompt me per use. The gate is at seed time and in the vault scope. Once a credential is in the keychain, any process running as me on that machine can read it until I remove it or revoke the token. For my setup that is the right trade: the machines are mine, the tokens are read-only and scoped, and the agents' rules forbid printing a secret or running anything against production outside two named roles. If your threat model needs a biometric prompt every time an agent touches a credential, this is not that, and I do not know of a product that is.

The prompt

If you want to set this up with Claude Code, this is the prompt I would start from. It asks the agent to do the parts an agent should do and to hand you the two parts that need your hands.

Set up my coding agent to use my credentials from 1Password without me
pasting secrets, on this Mac. Never run curl | sh. Never print a secret or
let one land in this transcript. Every change needs my yes first.

1. Tell me how to create a 1Password service account named after this
   machine, read-only, scoped only to the vault(s) my agent needs, never my
   private vault. I will create it and copy the token.
2. Have me store that token in the macOS login keychain as
   OP_SERVICE_ACCOUNT_TOKEN with the value-argument form of
   security add-generic-password, run in my own Terminal. The prompt form
   stores an empty string in a non-TTY shell. Do not export it in my shell
   profile; read it per call.
3. Prove it by use, not by length: op whoami must show SERVICE_ACCOUNT,
   then one real read with --vault.
4. For each credential my scripts need, copy it from 1Password into the
   keychain in one pipeline so the value never prints, then verify it with
   one authenticated read-only call.
5. Write a short README: what is in the keychain (names only), how to
   re-seed when a token rotates, and how to revoke this machine's token.

Two things to know before you start. 1Password service accounts need a plan that includes them. And the machine-specific token is worth the extra minute: the first time you need to cut one machine off, you will be glad the others do not go with it.