Keep Agent Secrets Out of Prompts with 1Password
An AI agent eventually needs to authenticate to something: a code host, cloud service, database, or infrastructure API. The dangerous shortcut is to paste the credential into the conversation or save it in a project file.
1Password provides a better boundary. Store the secret in the password manager, give an approved process temporary access, and keep the reusable value out of the model’s context.
The mental model
Section titled “The mental model”The agent should know that an application needs SERVICE_TOKEN. It usually does not need to know the token itself.
A safer flow is:
- A human or automation identity is authorized in 1Password.
- The workflow refers to the required field with a secret reference.
- 1Password resolves the value at runtime.
- The application receives it for the task.
- The agent sees the result of the application, not the credential.
This is capability without custody. It reduces exposure, although it cannot prevent a badly behaved application from printing the value later.
Windows and Linux with the 1Password CLI
Section titled “Windows and Linux with the 1Password CLI”The 1Password CLI is named op and is available for Windows, Linux, and macOS. On an attended workstation, it can integrate with the desktop app so a person authorizes terminal access using the authentication available on that platform.
Secret references have this general shape:
op://vault/item/fieldAn environment template can contain the reference instead of plaintext:
SERVICE_TOKEN=op://development/example-service/tokenThen op run can resolve the variable for one child process:
op run --env-file=.env.tpl -- application-commandThe template can be reviewed and versioned if it contains no other sensitive information. The child process can still read its environment, so use a narrowly scoped credential and a trusted application.
For software that requires a configuration file, op inject can render a template. Avoid writing the rendered plaintext to disk when the application can consume it through a pipe or temporary restricted location.
Headless servers need a different identity
Section titled “Headless servers need a different identity”Biometric or interactive approval is a good workstation pattern, not an unattended-server pattern. Scheduled jobs, containers, and CI systems can use a 1Password service account.
A service account should have access only to the required vaults and operations. Its token is displayed once and is itself a powerful secret. Deliver it through the platform’s protected secret mechanism as OP_SERVICE_ACCOUNT_TOKEN; never save it in a repository, container image, shell profile, agent prompt, or documentation note.
Service-account scope is intentionally difficult to change. If the workload needs different access, revoke the old identity and create a correctly scoped replacement.
Safe use with agents
Section titled “Safe use with agents”Prefer a reviewed wrapper command that runs one application through op run over unrestricted access to the complete 1Password CLI.
Also watch for secondary leaks:
- shell tracing and verbose debug modes;
- standard output and error logs;
- process inspection;
- crash reports and screenshots;
- generated configuration files; and
- an agent copying command output into its transcript.
1Password secures retrieval. The rest of the execution path still matters.
When I recommend it
Section titled “When I recommend it”Use this pattern when agents or automation need API keys, tokens, SSH credentials, or other reusable secrets. It is especially valuable when the same credential must be rotated centrally or used across Windows workstations, Linux servers, and CI jobs.
Do not use a password manager as permission to give an agent every credential in a vault. Start with the task, create the narrowest useful access path, and preserve human approval for high-impact operations.