Le pides a Hermes que entre en tu panel de administración y cambie un valor de configuración. Navega hasta allí sin problema y luego se detiene en seco ante el formulario de inicio de sesión. No porque no sepa hacer clic, sino porque la contraseña solo la sabes tú. Así que la pegas en el chat y, desde ese momento, el texto plano vive en el historial de la sesión, en los registros y en el siguiente lote de contexto que le envías al modelo. Cambiaste un clic por entregar tu contraseña a todo el pipeline.

La bóveda de credenciales (credential vault) que Hermes acaba de integrar apunta justo a eso. El agente llega por sí solo a la página de inicio de sesión, escribe el identificador por su cuenta y Hermes inyecta la contraseña en el lado del servidor. Lo único que el modelo recibe de vuelta es una línea: {filled_fields: 1, origin: "https://github.com"}. La contraseña nunca entra en la conversación, ni en los registros, ni en la base de datos de sesiones, ni en la línea de comandos de ningún proceso.

Cómo se reparten las piezas

Hay dos capas: un almacén que guarda los inicios de sesión y herramientas de navegador que los colocan en la página. El agente solo recibe un handle (un identificador opaco) más metadatos visibles (etiqueta, identificador, origen). El secreto real lo resuelve el backend en el momento de rellenar y se escribe directamente en la página.

Herramienta	Qué hace
browser_vault_list	Lista los inicios de sesión rellenables: etiquetas, identificadores, orígenes. Nunca contraseñas.
browser_vault_save_login	Guarda un inicio de sesión nuevo desde la página en la que está el agente
browser_vault_fill	Inyecta un inicio de sesión en la página actual, con comprobación de origen
browser_vault_enter_code	Gestiona el paso del código de un solo uso
browser_vault_unlock	Desbloquea un gestor externo (1Password / Bitwarden)

Los elementos se guardan cifrados en ~/.hermes/vault/ (una clave Fernet más el archivo de la bóveda, ambos con permisos 0600) y están acotados por perfil: la misma idea de aislamiento que hay detrás de la navegación con perfil real.

La primera vez: te lo pregunta en la propia página de inicio de sesión

Lo mejor es que no hay que configurar nada. No hace falta aprenderse hermes vault add ni buscar un interruptor antes. Di «inicia sesión en GitHub» y, cuando el agente llegue a una página de inicio de sesión sin nada guardado para ese sitio, te lo preguntará ahí mismo, donde estés:

• CLI / TUI — un panel de dos pasos en el mismo modal que usa sudo: primero se muestra el correo o el nombre de usuario y después se teclea la contraseña oculta.
• Escritorio — una tarjeta de «¿Guardar tu inicio de sesión de github.com?» con campos etiquetados Correo o usuario y Contraseña, y dos botones: No guardar / Guardar e iniciar sesión.

Di que sí y Hermes la cifra, la vincula al origen de la página y la rellena al instante. Si lo rechazas, la herramienta devuelve save_declined y el agente deja de pedirlo durante ese turno. En cualquiera de los dos casos la contraseña nunca pasa por el chat: se tecleó en un prompt enmascarado, no en un mensaje.

Un detalle de diseño que merece la pena señalar: estas herramientas van con el conjunto de herramientas del navegador, no detrás de una comprobación de «la bóveda tiene elementos». Una bóveda vacía es justo cuando hace falta guardar un inicio de sesión, y una iteración anterior escondía la función detrás de esa comprobación, y por eso nadie la encontraba.

2FA: tres casos, tres comportamientos

Las contraseñas no son el último paso. El agente solía chocar con un muro aquí: el clasificador de inicios de sesión ignora a propósito los campos de código de un solo uso (una contraseña nunca debe acabar en una casilla de OTP) y no había ninguna herramienta para el segundo paso, así que lo único que podía hacer era preguntar por el chat.

Ahora se divide en tres casos:

Lo que pide el sitio	Lo que hace Hermes
Un código, y el inicio de sesión guardado lleva una clave de autenticador (bóveda local, o un elemento de 1Password / Bitwarden con una semilla TOTP)	Genera el código actual y lo introduce. No se pregunta a nadie.
Un código enviado al teléfono, al correo o a una app, sin ninguna clave guardada	Aparece un pequeño aviso en tu interfaz («Código de verificación para github.com»), lo escribes y Hermes lo introduce. El código tampoco entra en la conversación.
Una passkey, una llave hardware o un toque de aprobación en una app	No hay nada que teclear. El agente te dice que lo termines en tu dispositivo y espera a que la página avance.

Una clave de autenticador es la «clave de configuración» —o el enlace otpauth://— que muestra un sitio cuando activas el 2FA. Añádela en Ajustes → Contraseñas e inicios de sesión → Añadir (es un campo opcional), o en el asistente de hermes vault add; los elementos que la llevan muestran una insignia 2FA auto.

La introducción de códigos también es deliberadamente conservadora: los dígitos se teclean uno por campo solo cuando el widget es inconfundible —exactamente tantos controles como dígitos tiene el código, todos con maxlength=1, en el mismo formulario y adyacentes—. En cualquier otro caso se escribe el código entero de una vez, para que una página con campos de «código» de promoción, código postal o referidos nunca reciba una lluvia de dígitos.

¿Ya usas 1Password o Bitwarden? Nada que activar

Si la CLI op o bw está instalada y con la sesión iniciada, Hermes la detecta automáticamente y sus inicios de sesión web pasan a ser handles rellenables junto a los locales. Los handles llevan un espacio de nombres según el backend — vault_… para los locales, op:… y bw:… para los gestores — así que las herramientas no necesitan ningún cambio de esquema para dirigirse al correcto.

La primera vez que necesita uno de esos inicios de sesión te pide desbloquear el gestor: prompt enmascarado, una vez por sesión y caduca tras 30 minutos de inactividad. La contraseña maestra va a la propia CLI del gestor a través de su canal no interactivo (op signin por stdin, bw unlock --passwordenv en el entorno del proceso hijo). Hermes solo guarda el token de sesión en memoria —nada en disco, nada en copias de variables de entorno— y nunca ve la contraseña maestra, el token ni ningún inicio de sesión.

¿Prefieres no usar ninguno de los gestores detectados? hermes vault sources --disable bitwarden, o el interruptor en Ajustes.

Pagar y rellenar direcciones: cada relleno de tarjeta necesita tu visto bueno

Las tarjetas y las direcciones se guardan igual: una vez, vinculadas al sitio de pago, y se rellenan solo allí. La diferencia está en la confirmación: cada relleno de tarjeta te pregunta primero, con el mismo aviso de aprobación que un comando peligroso, y si lo rechazas no se escribe nada. Los rellenos de dirección no necesitan confirmación.

El otro límite que conviene memorizar: las sesiones headless no pueden rellenar tarjetas. Los trabajos de cron, los webhooks y el servidor de API no tienen a nadie que pulse confirmar, así que esos rellenos se rechazan. Una inyección de prompt que llegue a una página de pago puede pedir, pero no puede gastar. Es el mismo principio que en las aprobaciones sin supervisión: cuando nadie puede responder, lo predeterminado es no, no sí.

Gestionarla desde la CLI

El escritorio se encarga de todo en Ajustes → Contraseñas e inicios de sesión; en la CLI hay cuatro subcomandos:

# Alta interactiva para un inicio de sesión, una tarjeta o una dirección. La contraseña pasa por
# getpass: nunca se acepta como argumento de línea de comandos.
hermes vault add
hermes vault add --kind payment     # tarjeta de pago
hermes vault add --kind address     # dirección de envío / facturación

# Solo metadatos: handle, fuente, tipo, etiqueta, identificador, origen
hermes vault list

# Eliminar por handle
hermes vault rm vault_3f9c1a

# Qué gestores de contraseñas se detectaron; desactivar o volver a activar uno
hermes vault sources
hermes vault sources --disable onepassword
hermes vault sources --enable onepassword

Las etiquetas, los orígenes de los sitios y los identificadores de inicio de sesión son metadatos visibles: el agente puede leerlos y teclear el identificador por su cuenta. Las contraseñas y los valores de las tarjetas, no.

Una aclaración, porque el nombre se solapa: esta bóveda no es el SecretSource externo de v0.19. SecretSource lee claves de API para Hermes desde Bitwarden Secrets Manager o 1Password y las convierte en variables de entorno, configuradas bajo secrets. La bóveda de credenciales guarda inicios de sesión web, tarjetas y direcciones, configurados bajo vault. Nombres parecidos, tareas que no tienen nada que ver.

Sesiones headless (cron, webhooks, el servidor de API)

Ahí nadie puede responder a un prompt, y los modos de fallo son distintos:

• Los inicios de sesión guardados localmente siguen funcionando: no hacen falta avisos.
• Un gestor de contraseñas bloqueado informa de unavailable_in_this_session.
• Sin inicio de sesión guardado para el sitio informa de prompt_unavailable.

Para que 1Password se pueda usar sin supervisión, dale un token de cuenta de servicio: configúralo en OP_SERVICE_ACCOUNT_TOKEN y el prompt de contraseña maestra desaparece:

vault:
  onepassword:
    enabled: true                      # false opts OUT of a detected manager
    account: ""                        # `op --account` shorthand; empty = default
    service_account_token_env: OP_SERVICE_ACCOUNT_TOKEN
  bitwarden:
    enabled: true
    binary_path: ""                    # absolute path to bw; empty = PATH

Qué garantiza esto y qué no

«El modelo nunca ve la contraseña» es fácil de malinterpretar, así que conviene ser precisos.

Sí mantiene la contraseña fuera del contexto del modelo en todo el recorrido por Hermes: no aparece en los resultados de las herramientas, ni en los registros, ni en la base de datos de sesiones, ni en el argv de ningún proceso. Los rellenos se hacen por el socket CDP directo de la sesión de navegador supervisada, y el origen se vuelve a comprobar dentro de la página justo antes de escribir: tiene que coincidir exactamente con el origen guardado o el relleno se rechaza.

No te protege de la propia página. Una vez que una contraseña se teclea en un sitio, ese sitio —y cualquier script que ejecute— la tiene, exactamente igual que cuando la escribes tú. En un backend de navegador en la nube, el navegador del proveedor ve la página como cualquier otra. La vinculación al origen protege contra rellenar en el sitio equivocado, no contra uno correcto pero comprometido.

El almacén en sí es cifrado local, un mecanismo distinto del cifrado opcional con el llavero del sistema operativo: la bóveda usa una clave Fernet y archivos con permisos 0600, y no toca el llavero del sistema.

Estado del lanzamiento: solo en main, por ahora

A fecha de este artículo, la función no ha llegado a ninguna versión etiquetada. La última versión, v0.21.1 (tag v2026.9.7, publicada el 7 de septiembre), no contiene agent/vault_backends/, tools/browser_vault_tool.py ni hermes_cli/vault.py: eso aterrizó en main el 10 de septiembre.

Así que:

• hermes update a v0.21.1 no te lo traerá. Habrá que esperar a que la próxima versión etiquetada lo incluya.
• Para usarlo hoy tienes que seguir main (la vía de instalación por git) y aceptar que main se mueve a diario.

En cualquier caso, la primera prueba después de tu próxima actualización es la misma de siempre: pídele al agente que inicie sesión en algún sitio y observa si se detiene en la página de inicio de sesión y te pregunta —por primera vez— si quieres guardar ese inicio de sesión.