Passwords & Logins: o agente entra nos sites sem nunca ver a tua palavra-passe

Dar um browser a um agente tem um problema óbvio: mais cedo ou mais tarde ele bate num formulário de login, e a partir daí ou lhe passas a palavra-passe ou o trabalho morre ali.

O cofre de credenciais do Hermes resolve isso pela única via que me parece aceitável: o segredo nunca passa pelo modelo. Chegou no release v0.21.2 (11 de setembro de 2026) e na v0.21.5 que tenho instalada já é rotina.

Não há nada para ligar

Isto não se configura: o cofre local está sempre ativo e vive em ~/.hermes/vault/, com âmbito por perfil. Nesta máquina o diretório está em 0700 e só lá mora o .vault.lock, porque ainda não guardei nada.

O agente chega lá por cinco ferramentas que viajam com o browser toolset — browser_vault_list, browser_vault_fill, browser_vault_save_login, browser_vault_enter_code e browser_vault_unlock — que são a mecânica por trás de um simples “entra no GitHub”.

O ciclo é sempre o mesmo: o agente lista os logins guardados, escreve ele próprio o identificador no campo e pede ao Hermes para preencher a palavra-passe. O resultado que ele vê é só isto:

{filled_fields: 1, origin: "https://github.com"}

O segredo vai também para o redator, pelo que uma leitura posterior da página não o consegue ecoar para o contexto. Sem login guardado, aparece-te um prompt mascarado: identificador à vista, palavra-passe escondida, e o que escreveres fica cifrado na máquina, ligado àquela origem exata. O preenchimento é recusado se a página não for exatamente a origem guardada, e a verificação repete-se dentro da página antes da escrita.

O cofre sem esperar por um formulário

Nem tudo tem de nascer de um prompt a meio de uma tarefa:

hermes vault list                          listar itens (metadados, nunca valores)
hermes vault add --kind login              guardar já (login, payment ou address)
hermes vault rm <handle>                   apagar um item pelo handle
hermes vault sources                       ver os gestores detetados
hermes vault sources --disable bitwarden   deixar de usar um gestor detetado

Sem o --kind, o add pergunta interativamente. E há a secção vault: do config.yaml, para quando os defaults não servem:

vault:
  onepassword:
    enabled: true                          # False = opt-out de um gestor detetado
    account: ""                            # shorthand de `op --account`; vazio = conta por omissão
    binary_path: ""                        # caminho absoluto para `op`; vazio = PATH
    service_account_token_env: OP_SERVICE_ACCOUNT_TOKEN
  bitwarden:
    enabled: true
    binary_path: ""

1Password e Bitwarden aparecem sozinhos

Se o op ou o bw estiverem instalados e com sessão iniciada, o Hermes apanha-os automaticamente, sem nada a ativar. A primeira vez que precisa de um desses logins pede-te o master password num prompt mascarado (uma vez por sessão, 30 minutos de inatividade), entrega-o ao CLI pelo canal não-interativo e guarda em memória só o token de sessão. O agente não vê o master password, nem o token, nem login nenhum.

Um item que liste vários sites preenche em cada uma dessas origens exatas; nada é inferido para lá dos URLs que lá estão. Neste host, o hermes vault sources responde 1Password not installed e Bitwarden detected, e o hermes vault list avisa que o Bitwarden está ligado mas fechado.

2FA, cartões e moradas

Códigos de dois fatores seguem a mesma lógica. Se o item guardar a chave de autenticador (a setup key ou o link otpauth:// do site, ou o TOTP de um item 1Password/Bitwarden), o Hermes gera o código e mete-o sozinho. Se o código chegar por SMS ou email, aparece um prompt pequeno na superfície onde estás e escreves lá o código, que também não passa pela conversa. Passkeys e aprovações em app não têm nada para escrever: o agente diz-te para completares no teu dispositivo e espera.

Cartões e moradas guardam-se da mesma maneira e ficam ligados ao site de checkout. A diferença importante: cada preenchimento de cartão pede confirmação, com o mesmo prompt de um comando perigoso, e recusar não escreve nada. As moradas não pedem. Em sessões headless o cartão é recusado, porque não há quem confirme — um prompt injection numa página de checkout pode pedir, mas não pode gastar.

Onde isto te morde

• Não confundir com os segredos de API. A secção secrets: (e o hermes secrets) puxa chaves de API de gestores de segredos para o ambiente do processo ao arranque. O vault: é para formulários de login, cartões e moradas no browser. Duas secções, dois propósitos.
• O 2FA do Bitwarden é o Password Manager (bw), não o Secrets Manager (bws) — e convém fazer bw login uma vez antes.
• Isto não protege contra a página. Assim que a palavra-passe está escrita no formulário, o site (e qualquer script que ele corra) tem-na, tal como se a tivesses escrito à mão; num backend de browser na cloud, o browser do fornecedor vê-a igual. O binding à origem protege-te de preencher no site errado, não de um site certo comprometido.
• Sessões headless ficam sem quem responda. Cron jobs, webhooks, o API server e o hermes chat -q não têm prompts: os logins locais guardados continuam a funcionar, mas um gestor bloqueado devolve unavailable_in_this_session e um login inexistente devolve prompt_unavailable. Desbloqueia numa sessão interativa primeiro; para 1Password em headless há o OP_SERVICE_ACCOUNT_TOKEN.
• A app não é consistente com os nomes. Na interface gráfica lê-se “Settings → Passwords & Logins”; os comentários dos defaults de config chamam-lhe “Credential Vault”. É deriva da aplicação, não confusão tua.

Vale a pena?

Sim, e não se nota até fazer falta. Sem cofre, um agente que navega obriga-te a colar segredos na conversa, e a partir daí eles ficam no histórico e no contexto. Aqui a palavra-passe sai da máquina encriptada e entra na página pela tomada direta do browser supervisionado. Não substitui bom senso — o site que a recebe continua a vê-la — mas resolve o que interessa: o agente trabalha sozinho sem tu lhe entregares as chaves todas.

Docs: Passwords & Logins · Referência dos toolsets · Release v2026.9.11