1password for free range agents

I want to give an agent a job, walk away, and come back to the result. A password manager asking me to approve access on the machine I just walked away from breaks that flow and led me to briefly create passwords.csv. But there is a better way.

My 1password is doing a great job at managing syncing of all the passwords, but then requires my finger when the agent tries to use anything. I tried MCP, CLI, and its own user in my 1password organization and it still was bugging me.

There are website accounts I am perfectly happy to delegate. Some are low-stakes enough that even considered passwords.csv. I want to decide which accounts belong in that category, then let the agent use them. We combine 2 things:

1. It’s own vault – obviously
2. Service account to access that vault without that damn confirmation dialog

Why the CLI keeps asking

There are different ways to authenticate the 1Password CLI. The desktop-app integration uses the identity of the person signed in to the app and can ask for device authentication. Its authorization is session-bound; it is designed around a human being available. The frequency depends on session and lock state, so it isn’t literally a prompt for every command. It can still feel that way when an agent is working across fresh processes or sessions. 1Password documents that interactive flow here.

1password service accounts

These are basically accounts designed specifically for agents. Instead of creating a new 1pass pretend user or giving it access to your account, you create a new one designed for non-interactive use.

• They DO NOT BUG YOU FOR confirmation
• They require a new vault and cannot access the Private/Public built-in vaults.

Go to Developer Tools -> Service accounts and create your 1password service accounts here (you need to set this up on the web)

The small piece of plumbing

The service account produces a token. On my Mac, we put that token in the login Keychain and created a small wrapper called op-codex.

The wrapper retrieves the token locally, passes it to the CLI as OP_SERVICE_ACCOUNT_TOKEN, and runs the requested command. The token doesn’t have to be pasted into a conversation or stored in the skill. This uses 1Password’s service-account authentication.

Note from my agent:

There was one very ordinary Mac detour. I initially saved the token in the iCloud Keychain. It was right there in Keychain Access, but the command-line lookup couldn’t find it. Copying it into login failed too. Creating a fresh entry directly in the login Keychain worked.

I approved that Keychain access with “Always Allow”. Subsequent CLI checks succeeded, and the service account could see the intended vault. We then imported an existing website login and read it back to verify the saved password matched. That tested both writing and reading, without displaying the password in the conversation.

This is a working setup in my current Mac session. I haven’t tested recovery after a reboot with nobody logging in. The OS still needs to make the token available: a locked Keychain can stop it, and an expired or revoked token will stop it. A Linux server would need its own local secret provisioning. Moving the human approval out of routine vault reads doesn’t solve every part of running an unattended computer.

What happens when a password is missing?

I also asked for a shared skill so future agent sessions know how to use this arrangement. It tells the agent to search the delegated vault for the correct website and account, use the credential for the task, and save updates there. If the credential is missing, it should ask me to add a Login item to that vault, including the URL, username, and password. It should then wait for me to say it’s ready.