Son las 2 de la madrugada y el trabajo programado que configuraste está en su último paso: enviar un informe a un panel interno. Se detiene en seco en la página de inicio de sesión. La contraseña está en tu cabeza, o en una nota, y la única forma de pasársela es pegarla en la ventana del chat, donde se quedará viviendo en la transcripción, en los logs y en el contexto del modelo. Durante mucho tiempo, así funcionaba la navegación de los agentes, y es la razón por la que mucha gente nunca dejaba que un agente se acercara a una cuenta que de verdad importaba. Hermes v0.22.0 cambia la fontanería: la primera vez que el agente llega a una página de inicio de sesión sin credenciales guardadas, te pregunta ahí mismo, y a partir de entonces esos sitios simplemente funcionan.

La primera vez que se topa con una página de inicio de sesión, pregunta una vez

En la CLI o la TUI, el prompt es texto enmascarado en tu terminal, algo como 🔐 Save login for github.com: primero escribes el identificador, y esa parte se muestra, y luego la contraseña, que queda oculta. El escritorio muestra en su lugar una tarjeta — “Save your github.com login?” — con un campo de identificador, un campo de contraseña enmascarado y dos botones: Save & sign in y Don’t save. Eso es toda la configuración. No hay ninguna clave que generar ni archivo de configuración que editar; si aún no has instalado Hermes, empieza por la guía de instalación.

Después simplemente funciona. La contraseña se cifra en tu máquina y se inyecta directamente en la página, y el modelo nunca la ve. Lo que le llega de vuelta al modelo es una sola línea: {filled_fields: 1, origin: "https://github.com"}. La contraseña también queda registrada en el redactor, así que una lectura posterior de la página no puede hacer que reaparezca en la transcripción.

Códigos de dos factores: automáticos, con prompt o en tu dispositivo

Situación	Quién se encarga
Se guardó una clave de autenticador junto al inicio de sesión — la clave de configuración o el enlace otpauth:// que muestra un sitio al activar 2FA. Los elementos de 1Password y Bitwarden que contienen una semilla TOTP también cuentan.	Hermes genera el código actual y lo introduce. No se pregunta a nadie.
El código se envía a tu teléfono o a tu correo.	Aparece un pequeño prompt en tu superficie — “Verification code for github.com” — lo escribes, y Hermes lo introduce en la página. El código tampoco entra nunca en la conversación.
Passkeys, llaves de hardware y aprobaciones en app (“toca Approve en Duo”).	No hay nada que escribir. El agente te pide que lo completes en tu dispositivo y espera a que la página avance.

La clave del autenticador se introduce desde Settings → Passwords & Logins → Add, o con hermes vault add; una vez asociada, el elemento muestra una insignia “2FA auto”.

¿Ya usas 1Password o Bitwarden? No hay nada que activar

Si la herramienta de línea de comandos op o bw está instalada y con la sesión iniciada, Hermes la detecta automáticamente, y esos inicios de sesión web se pueden rellenar junto a los locales. La primera vez que el agente necesita uno de ellos, te pide que desbloquees el gestor con tu contraseña maestra: un prompt enmascarado, una vez por sesión, que caduca tras 30 minutos de inactividad. Hermes entrega la contraseña maestra a la CLI del gestor a través de su canal no interactivo (op signin por stdin, bw unlock --passwordenv en el entorno del proceso hijo) y solo conserva el token de sesión en memoria. El agente nunca ve la contraseña maestra, ni el token, ni ningún inicio de sesión.

Un elemento que lista varios sitios — amazon.co.uk, www.amazon.co.uk, eu.account.amazon.com — se rellena en cada uno de esos orígenes exactos. No se infiere nada más allá de las URL guardadas en el elemento. Para desactivar un gestor detectado, usa hermes vault sources --disable bitwarden, o el interruptor en Settings → Passwords & Logins.

Tarjetas y direcciones en el pago

Las tarjetas y las direcciones funcionan como los inicios de sesión: se guardan una vez (Settings → Passwords & Logins → Add, o hermes vault add), quedan vinculadas al sitio de pago y el agente solo las rellena en ese sitio. La diferencia es la aprobación. Cada relleno de tarjeta te pregunta antes, con el mismo prompt que aparece antes de un comando peligroso, y si lo rechazas no se escribe nada. Las sesiones headless — cron, webhooks, el servidor de API — no pueden confirmar y se rechazan de plano, así que un prompt injection que llegue a una página de pago puede pedir, pero no puede gastar. El relleno de direcciones no necesita confirmación.

Qué se guarda y dónde

• Escritorio: Settings → Passwords & Logins lista todo lo guardado, los gestores detectados con Unlock/Lock, y las acciones Add y Remove.
• CLI: hermes vault list, hermes vault add, hermes vault rm (con el handle del elemento), hermes vault sources.
• En disco: los elementos viven cifrados bajo ~/.hermes/vault/ — una clave Fernet y un archivo de vault, ambos en modo 0600 — acotados al perfil. Las etiquetas, los orígenes de los sitios y los identificadores de inicio de sesión son metadatos visibles; las contraseñas y los valores de las tarjetas nunca salen del vault, salvo hacia la página. Cómo se cifran las propias claves de almacenamiento se trata en la guía de cifrado de secretos en el keychain.
• Ejecuciones headless: los cron jobs, los webhooks, el servidor de API y hermes chat -q no tienen a nadie que responda a un prompt. Los inicios de sesión locales guardados siguen funcionando ahí; un gestor de contraseñas bloqueado informa unavailable_in_this_session y un inicio de sesión ausente informa prompt_unavailable. Desbloquea o guarda primero desde una sesión interactiva, o dale a 1Password un token de cuenta de servicio (OP_SERVICE_ACCOUNT_TOKEN).

Las claves de configuración tienen este aspecto:

vault:
  onepassword:
    enabled: false          # deja FUERA un gestor detectado (por defecto: activo si está instalado)
    account: ""             # atajo de `op --account`; vacío = predeterminado
    service_account_token_env: OP_SERVICE_ACCOUNT_TOKEN
  bitwarden:
    enabled: false

Qué garantiza y qué no

Lo que hace: la contraseña nunca entra en el contexto del modelo a través de Hermes — ni en los resultados de herramientas, ni en los logs, ni en la base de datos de sesiones, ni en los argumentos de CLI de ningún proceso. Los rellenos ocurren a través del socket CDP directo de la sesión de navegador supervisada, y se rechazan a menos que el origen de la página coincida exactamente con el origen guardado, algo que se vuelve a comprobar dentro de la página justo antes de escribir.

Lo que no hace: protegerte de la propia página. En cuanto una contraseña se escribe en un sitio, ese sitio — y cualquier script que ejecute — la tiene, exactamente igual que cuando la escribes tú mismo. Con un backend de navegador en la nube, el navegador del proveedor ve la página como cualquier otro; las ventajas y desventajas entre la nube y lo local se tratan en el artículo sobre el fallback a navegador en la nube. La vinculación al origen protege contra rellenar en el sitio equivocado, no contra un sitio correcto comprometido.

Las herramientas del lado del agente detrás de todo esto son las browser_vault tools: browser_vault_list, browser_vault_fill, browser_vault_save_login y browser_vault_enter_code. La función llegó en la v0.22.0 “The Threshold Release” (tag v0.22.0, 13 de octubre de 2026). Si quieres la historia de cómo aterrizó, nuestro artículo anterior sobre autorrelleno de credenciales en el navegador profundiza en la mecánica.