The exact way I let an AI agent reach into my password manager without handing it the keys to everything. Copy it without copying my mistakes.
What I was worried about was simple enough: what has access to what. These systems still hallucinate and confabulate, and every so often something from the environment gets passed into the model, or leaks out somewhere it shouldn't. That's reason enough to be sceptical about how you wire them up — and even if you keep good password hygiene, you should stay sceptical, because these tools are new, largely automated, and mostly running unmonitored.
So the worry was straightforward: if I handed an agent my whole vault and something went wrong, the whole vault was exposed. Give it access to only what it needs, and the problem shrinks to that. Digging through 1Password's developer docs, I found you can do exactly that — build a vault holding just the keys a job needs, then create a service account the machine uses to reach them.
Is this caution or paranoia? A bit of both, honestly, and they go hand in hand — cautious in how you set it up, a little paranoid that it could still go wrong. That second half matters, because it's why you don't set this up and walk away: you keep watching, and check every so often that it's still doing only what it's supposed to.
A way to give an AI agent exactly the secrets it needs for one job — and nothing else. If the agent (or its scoped token) is ever compromised, the damage stops at the edge of one small vault. It's the principle of least privilege applied to AI, using 1Password's service accounts and secret references. Nothing here is exotic; it's four steps and about twenty minutes.
This is the builder's version of what 1Password for Claude now does in the browser (the consumer setup lives here) — the scoped-vault pattern below has worked for CLI and SDK agents far longer.
1. Give the agent its own vault.
Create a dedicated 1Password vault — call it something like Agent — and put only the credentials that agent needs in it. Never point the tooling at your personal or shared vaults. Your bank, your email and the family logins live somewhere it can't reach. If a token leaks, the blast radius is this vault and nothing more.
2. Create a read-only service account, scoped to that vault.
In 1Password → Developer → Service Accounts, create a new service account and grant it access to the Agent vault only — read-only wherever the agent doesn't genuinely need to write. A service account is a login for software rather than a person; scoping it to one vault is what turns "here are my passwords" into "here is exactly one drawer."
Store the token it gives you as an environment variable — OP_SERVICE_ACCOUNT_TOKEN — in your shell profile or secrets manager. Never paste it into a script, a .env you commit, or a prompt.
3. Reference secrets by path — don't paste them.
In your config and scripts, put a reference to the secret, never the secret itself:
# A reference 1Password resolves at runtime:
API_KEY="op://Agent/some-service/credential"
Resolve it only at the moment it's used, so the real value never lands in a file, a log, or the model's context:
# inject references just-in-time for one command:
op run -- node your-agent.js
# or read a single secret on demand:
op read "op://Agent/some-service/credential"
Both use 1Password's op command-line tool (install guide), and the secret-reference syntax is always op://<vault>/<item>/<field>. The value lives in 1Password; your code only ever holds the path to it.