The Credential Vault: Logins and Payments Without Ever Seeing a Password

The Hermes Agent credential vault lets the agent sign into websites, handle two-factor codes, and even fill in credit cards and addresses — while the underlying secrets never reach the model's context. It is one of the strongest answers to the question of how an autonomous agent can operate on the open web without becoming a password collector.

Say "log into GitHub" and the agent signs you in. The first time it reaches a sign-in page it has no login for, it asks you right there, in a masked prompt. After that it simply works, with nothing to set up in advance.

How Passwords Stay Out of the Model

The core design principle is that passwords are encrypted on your machine and injected directly into the page — the model never sees them. After a fill, the agent's view is a minimal, redacted tool result like {filled_fields: 1, origin: "https://github.com"}. The password is also registered with the redactor, so a later page read cannot echo it back into the conversation.

This protection extends beyond tool results. A saved password never enters the model's context through Hermes: not in tool results, not in logs, not in the session database, and not in the CLI arguments of any process. Fills happen over the supervised browser session's direct CDP socket.

Two-Factor Codes, Handled Three Ways

Sites that ask for an extra code after the password are handled the same way, with no weak link in the chain:

• Authenticator key saved with the login (the setup key or otpauth:// link a site shows when you enable 2FA — 1Password and Bitwarden TOTP seeds count too): Hermes generates the current code and enters it. Nobody is asked. Add the key in settings or via hermes vault add; the item then shows a 2FA auto badge.
• Code sent to your phone or email: a small prompt appears in your surface, you type the code, and Hermes enters it into the page. The code never enters the conversation either.
• Passkeys, hardware keys, or app approvals (like "tap Approve in Duo"): nothing to type. The agent tells you to complete it on your device and waits for the page to move on.

Paying and Filling Addresses

Cards and addresses work the same way as logins: saved once and bound to the checkout site, then filled by the agent on that site only. Two rules keep spending safe:

• Every card fill asks you first, with the same approval prompt as a dangerous command; declining writes nothing.
• Headless sessions cannot confirm. Cron jobs, webhooks, the API server, and hermes chat -q have nobody to answer a prompt, so card fills there are refused. A prompt injection reaching a checkout page can ask, but it cannot spend. Address fills need no confirmation.

Managing What's Saved

Items live encrypted under ~/.hermes/vault/ (a Fernet key plus a vault file, both 0600), scoped to the profile. Labels, site origins, and login identifiers are visible metadata; passwords and card values never leave the vault except into the page. Manage everything from Settings → Passwords & Logins or the CLI: hermes vault list, hermes vault add, hermes vault rm <handle>, and hermes vault sources.

If you already use 1Password or Bitwarden, nothing needs enabling — if the op or bw command-line tool is installed and signed in, Hermes picks it up automatically. The first time a manager login is needed, you unlock it with your master password (masked, once per session). Hermes hands the master password to the manager's CLI through a non-interactive channel and keeps only the session token in memory.

What This Does and Does Not Guarantee

Two boundaries are worth being explicit about. The vault does guarantee that a password never enters the model's context through Hermes, and that a fill is refused unless the page origin exactly matches the saved origin — checked again inside the page immediately before the write, so filling on the wrong site is the guard, not a hope.

It does not protect against the page itself. Once a password is typed into a site, that site (and any script it runs) has it, exactly as when you type it yourself. On a cloud browser backend, the vendor's browser sees the page like any other. The origin binding protects against filling on the wrong site — not against a compromised right one.

Key Takeaways

• Passwords and cards are encrypted on your machine and injected into the page via CDP; the model never sees, logs, or echoes them.
• 2FA is covered end-to-end, from auto-generated TOTP codes to device-based approvals.
• Card fills always require your approval and are refused in headless sessions, so prompt injection cannot spend money.
• 1Password and Bitwarden logins work with nothing to enable; the master password never reaches the agent.
• The vault guards against wrong-site fills and model exposure — the site itself is trusted once you hand it a password.