São 2 da manhã e o job agendado que você montou está no último passo: enviar um relatório para um dashboard interno. Ele trava em seco na página de login. A senha está na sua cabeça, ou numa nota, e a única forma de entregá-la é colar na janela de chat — onde ela vai continuar viva no transcript, nos logs e no contexto do modelo. Durante muito tempo foi simplesmente assim que a navegação por agente funcionou, e é a razão pela qual muita gente nunca deixou um agente chegar perto de uma conta que importava. O Hermes v0.22.0 muda o encanamento: na primeira vez que o agente chega a uma página de login sem login salvo, ele pergunta ali mesmo, e depois disso esses sites simplesmente funcionam.

Na primeira vez que ele encontra uma página de login, pergunta uma vez

No CLI ou na TUI o prompt é um texto mascarado no seu terminal, algo como 🔐 Save login for github.com: você digita primeiro o identificador, e essa parte aparece, depois a senha, que fica oculta. O Desktop mostra um card no lugar — “Save your github.com login?” — com um campo de identificador, um campo de senha mascarado e dois botões: Save & sign in e Don’t save. É toda a configuração necessária. Não há chave para gerar nem arquivo de config para editar; se você ainda não instalou o Hermes, comece pelo guia de instalação.

Depois disso, funciona. A senha é criptografada na sua máquina e injetada direto na página, e o modelo nunca a vê. O que volta para o modelo é uma linha: {filled_fields: 1, origin: "https://github.com"}. A senha também é registrada no redator, então uma leitura posterior da página não consegue repeti-la no transcript.

Códigos de dois fatores: automáticos, solicitados ou no seu dispositivo

Situação	Quem cuida disso
Uma chave de autenticador foi salva junto com o login — a chave de configuração ou o link otpauth:// que um site mostra quando você ativa o 2FA. Itens do 1Password e do Bitwarden que guardam uma seed TOTP também contam.	O Hermes gera o código atual e o digita. Ninguém é consultado.
O código é enviado para o seu celular ou e-mail.	Um pequeno prompt aparece na sua surface — “Verification code for github.com” — você digita e o Hermes insere na página. O código também nunca entra na conversa.
Passkeys, chaves de hardware e aprovações em app (“toque em Approve no Duo”).	Nada para digitar. O agente pede que você conclua no seu dispositivo e espera a página seguir.

A chave do autenticador entra por Settings → Passwords & Logins → Add, ou hermes vault add; depois de anexada, o item mostra um selo “2FA auto”.

Já usa 1Password ou Bitwarden? Não precisa habilitar nada

Se a ferramenta de linha de comando op ou bw estiver instalada e autenticada, o Hermes a detecta automaticamente, e esses logins de sites passam a ser preenchíveis junto com os locais. Na primeira vez que o agente precisa de um deles, ele pede que você desbloqueie o gerenciador com sua master password — um prompt mascarado, uma vez por sessão, que expira após 30 minutos de inatividade. O Hermes entrega a master password para o CLI do gerenciador pelo canal não interativo dele (op signin no stdin, bw unlock --passwordenv no ambiente do processo filho) e guarda na memória apenas o session token. O agente nunca vê a master password, o token nem login algum.

Um item que lista vários sites — amazon.co.uk, www.amazon.co.uk, eu.account.amazon.com — preenche em cada uma dessas origens exatas. Nada é inferido além das URLs salvas no item. Para desativar um gerenciador detectado, use hermes vault sources --disable bitwarden, ou o interruptor em Settings → Passwords & Logins.

Cartões e endereços no checkout

Cartões e endereços funcionam como logins: salvos uma vez (Settings → Passwords & Logins → Add, ou hermes vault add), vinculados ao site de checkout, preenchidos pelo agente só naquele site. A diferença é a aprovação. Todo preenchimento de cartão pergunta antes, com o mesmo prompt que aparece antes de um comando perigoso, e recusar não grava nada. Sessões headless — cron, webhooks, o servidor de API — não conseguem confirmar e são recusadas de imediato, então uma injeção de prompt que chega a uma página de checkout pode pedir, mas não pode gastar. Preenchimentos de endereço não precisam de confirmação.

O que é armazenado, e onde

• Desktop: Settings → Passwords & Logins lista tudo o que está salvo, os gerenciadores detectados com Unlock/Lock e as ações Add e Remove.
• CLI: hermes vault list, hermes vault add, hermes vault rm (com o handle do item), hermes vault sources.
• No disco: os itens ficam criptografados em ~/.hermes/vault/ — uma chave Fernet e um arquivo de vault, ambos com modo 0600 — com escopo no profile. Rótulos, origens de site e identificadores de login são metadados visíveis; senhas e valores de cartão nunca saem do vault a não ser para a página. Como as próprias chaves de armazenamento são criptografadas está no guia de criptografia de segredos do keychain.
• Execuções headless: jobs de cron, webhooks, o servidor de API e hermes chat -q não têm ninguém para responder a um prompt. Logins locais salvos continuam funcionando ali; um gerenciador de senhas bloqueado reporta unavailable_in_this_session e um login ausente reporta prompt_unavailable. Desbloqueie ou salve a partir de uma sessão interativa antes, ou dê ao 1Password um service account token (OP_SERVICE_ACCOUNT_TOKEN).

As chaves de config são assim:

vault:
  onepassword:
    enabled: false          # opt OUT de um gerenciador detectado (padrão: ligado quando instalado)
    account: ""             # atalho para `op --account`; vazio = padrão
    service_account_token_env: OP_SERVICE_ACCOUNT_TOKEN
  bitwarden:
    enabled: false

O que ele garante, e o que não garante

O que ele faz: a senha nunca entra no contexto do modelo por meio do Hermes — nem em resultados de ferramentas, logs, banco da sessão ou argumentos de CLI de qualquer processo. Os preenchimentos acontecem pelo socket CDP direto da sessão de browser supervisionada, e são recusados a menos que a origem da página coincida exatamente com a origem salva, verificada de novo dentro da página imediatamente antes da escrita.

O que ele não faz: proteger contra a própria página. Depois que uma senha é digitada em um site, aquele site — e qualquer script que ele execute — fica com ela, exatamente como quando você a digita. Em um backend de browser na nuvem, o browser do fornecedor vê a página como qualquer outro; os trade-offs entre nuvem e local estão no texto sobre fallback de browser na nuvem. O vínculo por origem é uma proteção contra preencher no site errado, não contra um site certo comprometido.

As ferramentas do lado do agente por trás de tudo isso são as browser_vault: browser_vault_list, browser_vault_fill, browser_vault_save_login e browser_vault_enter_code. O recurso chegou na v0.22.0 “The Threshold Release” (tag v0.22.0, 13 de outubro de 2026). Se você quer a história de como isso entrou, nosso texto anterior sobre preenchimento automático de credenciais no browser aprofunda a mecânica.