Il est 2 heures du matin et la tâche planifiée que vous avez mise en place en est à sa dernière étape : soumettre un rapport à un dashboard interne. Elle s’arrête net devant la page de connexion. Le mot de passe est dans votre tête, ou dans une note, et la seule façon de le transmettre est de le coller dans la fenêtre de chat — où il restera dans la transcription, les logs et le contexte du modèle. Pendant longtemps, c’était simplement ainsi que fonctionnait la navigation par agent, et c’est la raison pour laquelle beaucoup de gens n’ont jamais laissé un agent s’approcher d’un compte qui comptait. Hermes v0.22.0 change la plomberie : la première fois que l’agent tombe sur une page de connexion sans identifiants enregistrés, il vous le demande sur place, et ensuite ces sites fonctionnent tout simplement.

La première fois qu’il tombe sur une page de connexion, il demande une fois

Sur le CLI ou le TUI, le prompt est un texte masqué dans votre terminal, du genre 🔐 Save login for github.com : vous saisissez d’abord l’identifiant, qui est affiché, puis le mot de passe, qui reste caché. Le Desktop affiche plutôt une carte — « Save your github.com login? » — avec un champ identifiant, un champ mot de passe masqué et deux boutons : Save & sign in, et Don’t save. C’est toute la configuration. Aucune clé à générer, aucun fichier de config à éditer ; si vous n’avez pas encore installé Hermes, commencez par le guide d’installation.

Ensuite, cela fonctionne sans intervention. Le mot de passe est chiffré sur votre machine et injecté directement dans la page, et le modèle ne le voit jamais. Ce qui revient au modèle tient en une ligne : {filled_fields: 1, origin: "https://github.com"}. Le mot de passe est également déclaré auprès du redactor, de sorte qu’une lecture ultérieure de la page ne peut pas le renvoyer dans la transcription.

Codes à deux facteurs : automatiques, demandés, ou sur votre appareil

Situation	Qui s’en charge
Une clé d’authentificateur a été enregistrée avec les identifiants — la clé de configuration ou le lien otpauth:// qu’un site affiche quand vous activez la 2FA. Les éléments 1Password et Bitwarden qui contiennent une graine TOTP comptent aussi.	Hermes génère le code courant et le saisit. Personne n’est sollicité.
Le code est envoyé sur votre téléphone ou par e-mail.	Un petit prompt apparaît dans votre interface — « Verification code for github.com » — vous le saisissez, et Hermes l’entre dans la page. Le code n’entre pas non plus dans la conversation.
Passkeys, clés matérielles et approbations dans une application (« appuyez sur Approve dans Duo »).	Rien à saisir. L’agent vous indique de le valider sur votre appareil et attend que la page passe à la suite.

La clé d’authentificateur s’ajoute via Settings → Passwords & Logins → Add, ou hermes vault add ; une fois attachée, l’élément affiche un badge « 2FA auto ».

Vous utilisez déjà 1Password ou Bitwarden ? Rien à activer

Si l’outil en ligne de commande op ou bw est installé et connecté, Hermes le détecte automatiquement, et ces identifiants de sites deviennent remplissables aux côtés des identifiants locaux. La première fois que l’agent a besoin de l’un d’eux, il vous demande de déverrouiller le gestionnaire avec votre mot de passe principal — un prompt masqué, une fois par session, qui expire après 30 minutes d’inactivité. Hermes transmet le mot de passe principal au CLI du gestionnaire via son canal non interactif (op signin sur stdin, bw unlock --passwordenv dans l’environnement du processus enfant) et ne garde en mémoire que le token de session. L’agent ne voit jamais le mot de passe principal, le token, ni aucun identifiant.

Un élément qui liste plusieurs sites — amazon.co.uk, www.amazon.co.uk, eu.account.amazon.com — se remplit sur chacune de ces origines exactes. Rien n’est déduit au-delà des URL enregistrées sur l’élément. Pour désactiver un gestionnaire détecté, utilisez hermes vault sources --disable bitwarden, ou l’interrupteur dans Settings → Passwords & Logins.

Cartes et adresses au moment du paiement

Les cartes et les adresses fonctionnent comme les identifiants : enregistrées une fois (Settings → Passwords & Logins → Add, ou hermes vault add), liées au site de paiement, remplies par l’agent uniquement sur ce site. La différence, c’est l’approbation. Chaque remplissage de carte vous demande d’abord votre accord, avec le même prompt que celui affiché avant une commande dangereuse, et un refus n’écrit rien. Les sessions headless — cron, webhooks, serveur API — ne peuvent pas confirmer et sont refusées d’emblée : une injection de prompt qui atteint une page de paiement peut donc demander, mais pas dépenser. Les remplissages d’adresse ne nécessitent aucune confirmation.

Ce qui est stocké, et où

• Desktop : Settings → Passwords & Logins liste tout ce qui est enregistré, les gestionnaires détectés avec Unlock/Lock, ainsi que les actions Add et Remove.
• CLI : hermes vault list, hermes vault add, hermes vault rm (avec le handle de l’élément), hermes vault sources.
• Sur le disque : les éléments sont chiffrés sous ~/.hermes/vault/ — une clé Fernet et un fichier vault, tous deux en mode 0600 — et rattachés au profile. Les libellés, les origines des sites et les identifiants de connexion sont des métadonnées visibles ; les mots de passe et les valeurs de carte ne quittent jamais le vault, sauf pour aller dans la page. La façon dont les clés de stockage elles-mêmes sont chiffrées est traitée dans le guide de chiffrement des secrets du keychain.
• Exécutions headless : les tâches cron, les webhooks, le serveur API et hermes chat -q n’ont personne pour répondre à un prompt. Les identifiants locaux enregistrés continuent d’y fonctionner ; un gestionnaire de mots de passe verrouillé renvoie unavailable_in_this_session et un identifiant manquant renvoie prompt_unavailable. Déverrouillez ou enregistrez d’abord depuis une session interactive, ou fournissez à 1Password un token de compte de service (OP_SERVICE_ACCOUNT_TOKEN).

Les clés de configuration ressemblent à ceci :

vault:
  onepassword:
    enabled: false          # opt OUT of a detected manager (default: on when installed)
    account: ""             # `op --account` shorthand; empty = default
    service_account_token_env: OP_SERVICE_ACCOUNT_TOKEN
  bitwarden:
    enabled: false

Ce que ça garantit, et ce que ça ne garantit pas

Ce que ça fait : le mot de passe n’entre jamais dans le contexte du modèle via Hermes — ni dans les résultats d’outils, ni dans les logs, ni dans la base de données de sessions, ni dans les arguments CLI d’un quelconque processus. Les remplissages passent par la socket CDP directe de la session de navigateur supervisée, et ils sont refusés si l’origine de la page ne correspond pas exactement à l’origine enregistrée, vérifiée de nouveau dans la page juste avant l’écriture.

Ce que ça ne fait pas : protéger de la page elle-même. Une fois un mot de passe saisi dans un site, ce site — et n’importe quel script qu’il exécute — le possède, exactement comme lorsque vous le tapez vous-même. Sur un backend de navigateur cloud, le navigateur du fournisseur voit la page comme n’importe quel autre ; les compromis entre cloud et local sont traités dans l’article sur le repli vers le navigateur cloud. La liaison à l’origine est une protection contre un remplissage sur le mauvais site, pas contre un site légitime compromis.

Les outils côté agent qui sous-tendent tout cela sont les outils browser_vault : browser_vault_list, browser_vault_fill, browser_vault_save_login et browser_vault_enter_code. La fonctionnalité est arrivée dans la v0.22.0 « The Threshold Release » (tag v0.22.0, 13 octobre 2026). Si vous voulez l’histoire de son arrivée, notre article précédent sur l’autofill des identifiants dans le navigateur détaille davantage les mécanismes.