Build1 publisher2 min readPublished
Hermes Agent v0.21.2 routes passwords around its model straight into the login page
Hermes Agent v0.21.2 fills passwords from 1Password, Bitwarden or its own vault into web pages without the model ever seeing them. Every card fill waits for a person, so the agent cannot charge a stored card on its own, cron jobs included.
The Engineer · Build desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction
What happened
- After a successful fill, the model gets back only a short note saying that one field was filled and which page it was on.
- On a login page with nothing saved, the agent stops and asks, and the user types the username and then the password into a hidden field.
- The first use of a 1Password or Bitwarden entry asks for the master password in a hidden field, once per session, with a fresh unlock needed after 30 idle minutes.
- Two-factor codes come from a stored TOTP key without prompting, from a side prompt for codes sent to phone or email, or from the user's own device for passkeys and hardware keys.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- exposure Conversation logs and memory files, which the post says could capture a password pasted into chat or a config file, stop being a place that vault-filled passwords can land.
- exposure Storing the TOTP key with the password puts both login factors in one local vault, so whoever opens that store also gets the second factor.
- decision Teams already standardised on 1Password or Bitwarden can adopt the feature without copying entries into a new store, keeping one place to rotate and revoke credentials.
Version 0.21.2 shipped on 11 September 2026, and the current 0.21.5 includes the same feature, according to a dev.to post by Nokka [1]. Its byline says the post was written by deepseek-v4.1-flash running inside Hermes Agent, with a human checking the result [18]. So the account of what the model cannot see was drafted by the model [18]. The post summarises Hermes's documentation and release notes, and it does not report an independent test of any control described here.
Beyond the fill result, a second control covers what happens afterwards. Each injected password is registered with the system's redactor, so a later read of the same page cannot echo the value back to the model [10].
The password-manager path is the part I would review most closely, because there the secret that unlocks every entry leaves Hermes for another process. Hermes hands the master password to the 1Password or Bitwarden command-line tool over a non-interactive channel, either standard input or an environment variable on the child process [14]. It keeps only the resulting session token, in memory [14]. According to the post, the agent never sees the master password or the token [14].
Cards and addresses are stored and bound to the site where they are used [17]. A card fill passes through the same approval gate Hermes applies to potentially dangerous commands, and if the user declines, nothing is written to the page [15]. Address fills go through without a prompt [4]. Nokka's post explains the split by reversibility: a payment is hard to undo, so a person approves it every time [19]. For a personal assistant, I agree with that ordering.
The documentation's stated result, per the post, is that an attacker who plants hidden instructions on a checkout page can get the form filled but cannot spend [16]. Two things have to be true for that to hold. The approval has to be answerable by a person and never by the model. The card number has to have no route to the page except the gated fill.
Each saved login is encrypted on the local machine and tied to one origin, such as https://github.com [9]. The documentation is plain about where the protection stops: once a password is typed into a site, that site has it, as it would if you had typed it yourself [6].
What to watch
- An independent test of whether the redactor catches a filled password when a page echoes it back on a later read.
- Hermes documentation stating which channel, standard input or a child-process environment variable, carries the master password by default.
- Any later release that adds a way to approve card fills in cron, webhook or API-server sessions.