[Feature]: 1Password (op://) secret source backend

[hwrdprkns]

Problem or Use Case

Feature Request: 1Password as a Hermes secret source

Context

Hermes currently supports Bitwarden Secrets Manager (BWS) as an external secret source, documented at:
https://hermes-agent.nousresearch.com/docs/user-guide/secrets/

The docs also mention:

"More backends (Vault, AWS Secrets Manager, 1Password CLI) are easy to add behind the same interface — the lift is one module in agent/secret_sources/ and one CLI handler. File a request if you have a specific one in mind."

1Password is one of the most widely used password managers, and its official op CLI supports both interactive desktop sessions and non-interactive service-account tokens — making it a natural fit for programmatic credential access in Hermes startup.

What 1Password / the op CLI offers

• op://vault/item/field secret references — a stable, human-readable URI scheme for individual credentials
• Service-account tokens for headless/CI workloads (OP_SERVICE_ACCOUNT_TOKEN) with scoped vault read access
• Desktop/interactive session auth (OP_SESSION_*) for laptop/developer use — no extra setup beyond signing in to the app
• Audit logs for every credential access in the 1Password web console
• End-to-end encryption — the standard 1Password security model
• Available on the individual, team, and business plans; the developer plan covers most personal uses

This is functionally equivalent to what Bitwarden Secrets Manager provides for Hermes' use case, with the additional benefit that many teams already have 1Password for Business.

Proposed Solution

Proposed implementation

A new backend module agent/secret_sources/onepassword.py that:

1. Reads an env mapping of ENV_VAR_NAME → op://vault/item/field references from secrets.onepassword.env in config.yaml
2. Resolves each reference with a single op read -- <reference> call at startup (after .env loads)
3. Injects resolved values into os.environ, matching the existing Bitwarden startup hook
4. Supports OP_SERVICE_ACCOUNT_TOKEN for service-account auth and OP_SESSION_* for desktop sessions — op handles auth entirely; Hermes shells out to an already-authenticated CLI
5. Caches successful pulls in-process and on disk (<hermes_home>/cache/op_cache.json, mode 0600) so back-to-back invocations don't re-shell op for every reference
6. Is startup-safe and fail-open: a missing binary, expired session, bad reference, or empty value each emit a one-line warning and fall through to whatever credentials .env already had

Also adds hermes secrets onepassword {setup,status,set,remove,sync,disable} CLI commands (aliases op, 1password) for managing the configuration interactively.

Why this matters

1Password is already the credential store for a large number of individual developers and engineering teams. Adding it as a Hermes secret source lets them rotate provider API keys centrally in 1Password rather than maintaining plaintext .env files across multiple machines or gateway deployments.

Alternatives Considered

Bitwarden Secrets Manager is already supported. 1Password differs in that it uses per-field op:// references rather than a project-level bulk sync, and its CLI supports both service-account and interactive session auth natively without Hermes needing to manage binary download or installation.

Feature Type

New tool

Scope

Medium (new agent/secret_sources/onepassword.py + hermes_cli/onepassword_secrets_cli.py + env_loader wiring + tests + docs)

Contribution

• I'd like to implement this myself and submit a PR

Related PR: #36896

[loganfinney27]

Cross-linking #19201 (load_hermes_dotenv override=True clobbers runtime-injected env vars — type/bug, P2) with this feature request, because the two issues interlock in a way that strengthens the case for the native backend here:

On a hardware-limited Mac locked to macOS 12.7.6 (can't install 1Password 8 → no desktop-app CLI integration in 1Password 8's Developer settings → service-account-token is the only viable op CLI auth path), the active workaround pattern is:

op run --env-file=~/.hermes/.env -- python -m hermes_cli.main gateway run --replace

with .env holding KEY="op://<vault>/<item>/<field>" references for every secret-bearing var.

This pattern is broken today by #19201 — op run resolves the references and exports plaintext to os.environ, then load_hermes_dotenv runs with override=True and re-clobbers them with the literal op://... strings. The daemon then sends literal op://<vault>/<item>/<field> to upstream APIs as the credential and 401s across every env-based cloud route (messaging gateways, inference, anything env-derived).

The native backend proposed here resolves this structurally:

• Reads op:// refs from a dedicated config block, not .env
• Resolves via op read once at startup, after load_hermes_dotenv runs — so override=True becomes orthogonal instead of the blocker
• Service-account-token auth means no desktop-app dependency, which matters on machines that can't run 1Password 8

So this feature isn't just a nice-to-have alongside the existing Bitwarden source — it's the durable solution to the #19201-shaped workaround problem for the op:// pattern, particularly for users stuck on older macOS where the desktop-app-CLI integration isn't available. One data point for prioritization: at least one of us is actively trying to use this stack and hitting the override bug as the blocker.

(Stack: Hermes 0.14.0, macOS 12.7.6, 1Password CLI 2.34.0 via service-account token. Drafted by Claude with the deployment context; verified against the running daemon.)