I want my agents to do useful work: run a report, call an API, check something while I'm away. Some of that needs credentials. Having to approve access halfway through defeats the point of scheduling it.
I kept 1Password and changed how the agents access it.
What worked, and what broke
I started with a separate vault for agent credentials and a 1Password service account that could access it. My personal passwords stayed separate. The agents could retrieve what they needed without using my interactive desktop session.
That worked, until we hit the API allowance.
A Search Console report failed because it couldn't retrieve its Google refresh token. Google was fine. We'd used 1,000 out of 1,000 requests on the 1Password account.
Several tasks were fetching credentials, and the daily allowance was shared across service accounts. Another token wouldn't fix that.
We cut unnecessary reads and added 1Password Connect for ordinary agent credential tasks. Connect keeps a synced cache of the vault data, so repeated reads can be served from there instead of repeatedly fetching those secrets from 1Password's service.
I still have a service-account path for integrations that need it. You don't have to move everything to Connect at once.
How to set it up on a Mac
The steps below cover the service-account setup. Connect is an optional next step if you run into repeated-read limits
Start with a test credential so you can check everything before adding anything important.
1. Create the vault and test item
In 1Password, create a vault called Agent Demo.
Inside it, create a Password item called Example API. Give its password field a harmless test value. We’ll use this reference to retrieve it:
op://Agent Demo/Example API/password
The three parts are the vault name, item name and field name. They need to match your item.
2. Create the service account
Open 1Password’s service-account setup and create an account with read access to Agent Demo only.
Save the service-account token when 1Password displays it. This token lets the automation access that vault, so treat it like a password. Don’t paste it into your agent’s chat.
3. Store that token in Keychain
Open Keychain Access on your Mac. Select the login keychain, then choose File → New Password Item.
Enter:
- Keychain Item Name: 1password-token
- Account Name: agent-token
- Password: the service-account token from the previous step
Click Add.
To find it later, search Keychain Access for 1password-token. That is the item name. OP_SERVICE_ACCOUNT_TOKEN is something different: it is the environment variable the 1Password CLI expects.
4. Install the CLI and test the connection
If you use Homebrew:
brew install --cask 1password-cli
Run this in a local Terminal window:
(
set +x
unset OP_CONNECT_HOST OP_CONNECT_TOKEN
OP_SERVICE_ACCOUNT_TOKEN="$(
security find-generic-password \
-s '1password-token' \
-a 'agent-token' \
-w
)" || exit 1
export OP_SERVICE_ACCOUNT_TOKEN
if op read 'op://Agent Demo/Example API/password' >/dev/null; then
printf 'Success: the test credential is accessible.\n'
else
printf 'Could not read the test credential.\n' >&2
exit 1
fi
)This looks up the Keychain item using its name and account, supplies the token to op, and checks whether it can read your test item. It does not print either credential.
The parentheses keep the environment changes inside this test rather than leaving the token exported in your shell.
macOS may ask you to approve Keychain access. A successful interactive test does not guarantee that a scheduled job can retrieve the same item.
5. Connect it to a real task
The test above deliberately discards the retrieved value. For a real task, the script doing the work should capture it privately and pass it to the API or program that needs it.
This is the part that depends on your agent. Its launcher is simply the script or service that starts it. That launcher needs to load the service-account token before starting the process that uses op.
Give the agent the secret reference, not the secret:
Use op://Agent Demo/Example API/password for this task. Retrieve it inside the consuming script. Do not return the value in tool output or chat.
Then test through the same launcher or scheduler you actually use. If Keychain reports “interaction not allowed”, the background access path needs fixing. Creating another 1Password token won’t solve that.
The service-account guide covers the setup. If you have lots of repeated reads, look at Connect. A small workflow may be perfectly fine with a service account alone.
The instructions I give the agent
I keep the operating rules in a skill. Here's a reusable version with my private setup details removed. Save it as SKILL.md in your agent's skill directory, replace the example vault name and configure the authentication separately. If you only use a service account, leave Connect out.
--- name: agent-credentials description: Use when an authorised task needs credentials from 1Password. --- # Agent credentials ## Setup and scope - Approved vault: Agent Demo. Replace this example during setup. - Use the installed official 1Password CLI, op. - Authentication must already be configured by the owner through a trusted launcher or local secret store. Never request tokens in chat or search notes, history or unrelated files for them. - Access only the exact item and field needed for the authorised task. If the reference or permission is unclear, ask first. - Do not access personal vaults or change access permissions. ## Choose authentication - If Connect is configured for this task, use it for supported reads. Otherwise use the configured service-account path. - Use a task-scoped child environment. Remove inherited OP_SERVICE_ACCOUNT_TOKEN, OP_CONNECT_* and OP_SESSION* variables before supplying the selected provider's credentials. - Connect requires OP_CONNECT_HOST and OP_CONNECT_TOKEN. A service account requires OP_SERVICE_ACCOUNT_TOKEN. - Never change global authentication or unrelated integrations. - After starting with Connect, use service-account recovery only if the owner has configured and authorised it for availability or sync failures, within the same vault and task scope. - Permission refusals are terminal. Desktop access requires explicit approval for this task, never unattended fallback. ## Retrieve and use a credential 1. Resolve the exact reference, for example: op://Agent Demo/Example API/password 2. Invoke op read with that reference from the consuming script or trusted launcher. Capture stdout privately in memory, not in tool output returned to the agent conversation. 3. Pass the value directly to the intended process or request. Never place secrets in command arguments, logs or chat. 4. Reuse the value within the task where appropriate. Do not repeatedly list vaults or fetch the same field unnecessarily. 5. Keep shell tracing off. Do not dump environment variables, full item JSON or raw errors that might contain secrets. 6. Do not create persistent caches or secret files without explicit approval of storage, lifetime and removal. ## Writes and verification - Create, update or delete credentials only when authorised. - Use the supported write interface for the selected provider. Connect-backed CLI commands are limited; use the Connect API for approved writes rather than assuming all op commands work. - Pass secret-bearing write payloads through stdin or an in-memory request body, never command arguments or temporary files. - Read back the exact target and compare values in memory. Report only whether verification matched, not the values. - After a timeout or uncertain write, reconcile on the original backend before retrying or switching providers. Do not create duplicate items because an immediate read hasn't found one. ## Failures - On HTTP 429, stop requests to that backend. Report the limit and reset information if available. Do not loop, rotate tokens or switch identities to evade the allowance. - On access denied, stop and report the permission problem. - On unavailable bootstrap credentials, stop. Do not substitute a personal login or search for another token. - Report incomplete or unverified work honestly.
The skill tells the agent how to behave. The actual access restrictions are configured in 1Password.
Someone also suggested keyring, which gives scripts access to the operating system's credential store. That's useful for local storage, but it doesn't replace the vault permissions or solve 1Password's request limits.
The benefit for me is practical: agents can retrieve credentials for approved tasks without waiting for me to unlock 1Password each time. I don't have to copy API keys into conversations, and my personal passwords stay outside the agent vault.
A scheduled report should be waiting for me when I sit down, rather than waiting for my fingerprint.