My AI Agents Kept Asking Me to Touch the Fingerprint Reader

I wanted my agents to get on with their work. Instead, I kept getting asked to touch the fingerprint reader.

I use Buzz to work with AI agents in shared conversations. Some of their tasks need credentials from 1Password. Each lookup brought me back into the loop: approve access, let the agent continue, approve access again.

I had already put a Nomad token in the macOS Keychain to solve this for one tool. But the next tool still needed its own secret. Fixing them one at a time was getting old.

Why I was still in the loop

The agents were using 1Password through its command-line tool, op. In my Buzz setup, fresh tool calls kept triggering another approval request through the desktop app.

That is reasonable when I am sitting at a terminal asking for a password. It gets annoying when I have handed off a task and gone back to something else.

What I changed

I gave the agents a separate 1Password login for automation: a service account. It has its own token and access permissions, so it can retrieve credentials without asking me to approve each lookup through the desktop app.

I keep that token in my Mac’s login Keychain. A small wrapper called op-sa reads it when needed, passes it to the 1Password command-line tool, and runs the requested command.

The repeated Touch ID prompts stopped in this setup. I do not keep the token in the agent configuration or a .env file. If the wrapper cannot retrieve it, it stops rather than falling back to another approval prompt.

These are local tools I built for my setup, not commands that come with 1Password. This is the shape of the solution, rather than a copy-and-paste installation guide.

Fewer prompts make permissions more important

My intended rule is simple: keep credentials for agents in a dedicated vault. Put a credential there to grant access; move it out to revoke access.

The audit for this post found that the service account could still see three vaults. The single-vault boundary is the target, not the current state. I also have not verified its intended read-only access with a write attempt.

That distinction matters. Removing the prompts means I am relying on the account’s permissions instead of reviewing each lookup. Those permissions need to match what I actually want the agents to do.

The Keychain also does not isolate the token from other processes running as my Mac user. It keeps the token out of my configuration files, but it does not create a separate security boundary around each agent.

The surprising part was checking the token

Getting the token into the Keychain caused more trouble than I expected. One hidden input prompt silently cut it short and still reported success. On another attempt, the clipboard contained the setup command instead of the token.

So we added a validator. Then two agents tested it against the real 1Password tool and found six bugs in our checks.

My favourite example: the validator trimmed whitespace before checking a token. That looked helpful. But the wrapper passed the original value to 1Password, spaces included. Our check accepted something the real tool rejected.

The useful lesson was straightforward: test what the next tool actually receives. A cleaner version of the input can give you a reassuring answer to the wrong question.

What I have now

Credential lookups no longer keep pulling me back to the fingerprint reader. Other macOS permission prompts are a separate problem, and rotating this token still means updating the Keychain on each Mac.

The next bit of housekeeping is narrowing those vault grants. The interruption is gone; deciding what the agents should be allowed to read is still my job.