Você pede ao Hermes para entrar no seu painel de administração e mudar um valor de configuração. Ele navega até lá sem problema, e então trava na tela de login. Não porque não consegue clicar — mas porque só você sabe a senha. Então você a cola no chat e, a partir desse momento, o texto puro fica no histórico da sessão, nos logs e no próximo lote de contexto enviado ao modelo. Você trocou um clique por entregar sua senha para todo o pipeline.

O novo cofre de credenciais (credential vault) do Hermes, recém-integrado, ataca exatamente esse ponto. O agente chega sozinho até a tela de login, digita o identificador por conta própria, e o Hermes injeta a senha no lado do servidor. O que o modelo recebe de volta é uma única linha: {filled_fields: 1, origin: "https://github.com"}. A senha nunca entra na conversa, nos logs, no banco de dados da sessão nem na linha de comando de qualquer processo.

Como as peças se dividem

São duas camadas: um cofre que guarda os logins e ferramentas de navegador que os colocam na página. O agente só recebe um handle (identificador opaco) mais metadados visíveis (rótulo, identificador, origem). O segredo em si é resolvido no momento do preenchimento pelo backend e escrito direto na página.

Ferramenta	O que faz
browser_vault_list	Lista logins preenchíveis — rótulos, identificadores, origens. Nunca senhas.
browser_vault_save_login	Salva um novo login a partir da página em que o agente está
browser_vault_fill	Injeta um login na página atual, com verificação de origem
browser_vault_enter_code	Trata a etapa do código de uso único
browser_vault_unlock	Desbloqueia um gerenciador externo (1Password / Bitwarden)

Os itens ficam criptografados em ~/.hermes/vault/ (uma chave Fernet mais o arquivo do cofre, ambos com 0600) e são escopados por perfil — a mesma ideia de isolamento por trás da navegação com perfil real.

A primeira vez: ele pergunta na própria tela de login

A melhor parte é a configuração zero. Você não precisa aprender hermes vault add nem procurar um botão antes. Diga “faça login no GitHub” e, quando o agente chega a uma tela de login sem nada salvo para aquele site, ele pergunta onde você está:

• CLI / TUI — um painel de duas etapas no mesmo modal que o sudo usa: o e-mail/nome de usuário é exibido, e depois a senha é digitada de forma oculta.
• Desktop — um cartão “Salvar seu login do github.com?” com campos rotulados E-mail ou nome de usuário e Senha, e dois botões: Não salvar / Salvar e entrar.

Se você aceitar, o Hermes criptografa a senha, vincula-a à origem da página e a preenche imediatamente. Se recusar, a ferramenta retorna save_declined e o agente para de pedir naquele turno. De um jeito ou de outro, a senha nunca passa pelo chat — ela foi digitada num campo mascarado, não numa mensagem.

Um detalhe de design que vale notar: essas ferramentas viajam junto com o browser toolset (conjunto de ferramentas do navegador), e não atrás de uma verificação do tipo “o cofre tem itens”. Um cofre vazio é justamente quando salvar login é necessário, e uma versão anterior escondia o recurso atrás dessa verificação — por isso ninguém o encontrava.

2FA: três casos, três comportamentos

Senhas não são o último passo. O agente costumava bater numa parede aqui: o classificador de login ignora deliberadamente campos de código de uso único (uma senha nunca pode cair numa caixa de OTP), e não havia ferramenta para a segunda etapa — então o único movimento possível era perguntar no chat.

Agora isso se divide em três caminhos:

O que o site pede	O que o Hermes faz
Um código, e o login salvo carrega uma chave de autenticador (cofre local, ou um item do 1Password / Bitwarden com uma seed TOTP)	Gera o código atual e o insere. Ninguém é consultado.
Um código enviado por telefone / e-mail / app, sem chave salva	Um pequeno prompt aparece na sua interface (“Código de verificação para github.com”), você digita, e o Hermes o insere. O código também nunca entra na conversa.
Uma passkey, chave de hardware ou toque de aprovação num app	Nada a digitar. O agente avisa para você concluir no seu dispositivo e espera a página avançar.

Uma chave de autenticador é a “chave de configuração” — ou o link otpauth:// — que o site mostra quando você ativa o 2FA. Adicione-a em Configurações → Senhas e logins → Adicionar (um campo opcional), ou no assistente hermes vault add; os itens que carregam uma ganham um selo 2FA auto.

A inserção de código também é deliberadamente conservadora: os dígitos são digitados um por campo apenas quando o widget é inequívoco — exatamente tantos controles quantos dígitos o código tem, todos com maxlength=1, no mesmo formulário e adjacentes. Caso contrário, o código inteiro vai de uma vez só, para que uma página com campos de “código” de promoção, CEP ou indicação nunca receba uma rajada de dígitos.

Já usa 1Password ou Bitwarden? Não há nada a ativar

Se a CLI op ou bw estiver instalada e autenticada, o Hermes a detecta automaticamente e seus logins de sites viram handles preenchíveis ao lado dos seus logins locais. Os handles têm namespace por backend — vault_… para o local, op:… e bw:… para os gerenciadores — então as ferramentas não precisam de mudança de schema para encaminhar ao certo.

Na primeira vez que precisa de um desses logins, ele pede que você desbloqueie o gerenciador: prompt mascarado, uma vez por sessão, expirando após 30 minutos de inatividade. A senha mestra vai para a própria CLI do gerenciador pelo seu canal não interativo (op signin via stdin, bw unlock --passwordenv no ambiente do processo filho). O Hermes guarda apenas o token de sessão na memória — nada em disco, nada em backups de variáveis de ambiente — e nunca vê a senha mestra, o token nem qualquer login.

Prefere não usar um gerenciador detectado? Use hermes vault sources --disable bitwarden, ou o botão nas Configurações.

Pagamentos e endereços: todo preenchimento de cartão precisa do seu aval

Cartões e endereços são salvos do mesmo jeito — uma vez, vinculados ao site de checkout, e preenchidos apenas ali. A diferença está na confirmação: todo preenchimento de cartão pergunta primeiro, pelo mesmo prompt de aprovação de um comando perigoso, e recusar não grava nada. Preenchimentos de endereço não exigem confirmação.

A outra fronteira que vale memorizar: sessões headless não podem preencher cartões. Cron jobs, webhooks e o servidor de API não têm ninguém para clicar em confirmar, então esses preenchimentos são recusados. Uma injeção de prompt que chegue a uma página de checkout pode pedir — não pode gastar. É o mesmo princípio das aprovações sem supervisão: quando ninguém pode responder, o padrão é não, não sim.

Gerenciando pela CLI

O Desktop cuida de tudo em Configurações → Senhas e logins; o lado da CLI são quatro subcomandos:

# Adição interativa de um login, cartão ou endereço. A senha passa pelo
# getpass — ela nunca é aceita como argumento de linha de comando.
hermes vault add
hermes vault add --kind payment     # cartão de pagamento
hermes vault add --kind address     # endereço de entrega / cobrança

# Apenas metadados: handle, source, kind, label, identifier, origin
hermes vault list

# Remover por handle
hermes vault rm vault_3f9c1a

# Quais gerenciadores de senha foram detectados; desativar ou reativar um
hermes vault sources
hermes vault sources --disable onepassword
hermes vault sources --enable onepassword

Rótulos, origens de site e identificadores de login são metadados visíveis — o agente pode lê-los e digitar o identificador sozinho. Senhas e valores de cartão não são.

Uma observação, porque os nomes se sobrepõem: este cofre não é o SecretSource externo da v0.19. O SecretSource lê chaves de API para o Hermes de dentro do Bitwarden Secrets Manager ou do 1Password para variáveis de ambiente, configurado em secrets. O cofre de credenciais armazena logins de sites, cartões e endereços, configurado em vault. Nomes parecidos, trabalhos sem relação.

Sessões headless (cron, webhooks, o servidor de API)

Não há ninguém para responder um prompt ali, e os modos de falha são distintos:

• Logins salvos localmente continuam funcionando — nenhum prompt é necessário.
• Um gerenciador de senhas bloqueado reporta unavailable_in_this_session.
• Nenhum login salvo para o site reporta prompt_unavailable.

Para tornar o 1Password utilizável sem supervisão, forneça a ele um token de conta de serviço — defina-o em OP_SERVICE_ACCOUNT_TOKEN e o prompt de senha mestra 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

O que isto garante e o que não garante

“A senha nunca chega ao modelo” é fácil de interpretar além da conta, então vale ser preciso.

Isto garante manter a senha fora do contexto do modelo através do Hermes — não em resultados de ferramentas, logs, banco de dados da sessão ou no argv de qualquer processo. Os preenchimentos acontecem pelo socket CDP direto da sessão de navegador supervisionada, e a origem é verificada de novo dentro da página imediatamente antes da escrita: ela precisa coincidir exatamente com a origem salva, ou o preenchimento é recusado.

Isto não garante proteção contra a própria página. Assim que uma senha é digitada num site, aquele site — e qualquer script que ele execute — passa a tê-la, exatamente como quando você mesmo a digita. Num backend de navegador na nuvem, o navegador do fornecedor vê a página como qualquer outro. A vinculação de origem protege contra preencher no site errado, não contra um site certo comprometido.

O cofre em si é criptografia local, um mecanismo separado da criptografia opcional via keychain do sistema operacional: o cofre usa uma chave Fernet mais arquivos 0600 e não toca no keychain do sistema.

Status de lançamento: só no main, por enquanto

Até o momento deste texto, o recurso não chegou a nenhuma versão marcada com tag. A versão mais recente, a v0.21.1 (tag v2026.9.7, lançada em 7 de setembro), não contém agent/vault_backends/, tools/browser_vault_tool.py nem hermes_cli/vault.py — esses arquivos chegaram ao main em 10 de setembro.

Então:

• hermes update para a v0.21.1 não vai trazer isto. Espere a próxima versão marcada com tag.
• Para usar hoje, você precisa acompanhar o main (o caminho de instalação via git) e aceitar que o main muda diariamente.

De qualquer forma, o primeiro teste depois da sua próxima atualização é a mesma linha de sempre: peça ao agente para entrar em algum site e observe se ele para na tela de login e pergunta — pela primeira vez — se você quer salvar aquele login.