Dá para deixar o Hermes Agent cuidando da sua caixa de entrada?

Um agente que LÊ sua caixa de entrada e um agente que responde por você são duas bichos completamente diferentes

O primeiro erra e você perde cinco minutos, o segundo erra e o cliente lê

O Hermes Agent é um agente open source da Nous Research, e o e-mail não é gambiarra de terceiro ali dentro: é um dos canais nativos do gateway de mensageria, com leitura por IMAP e envio por SMTP, dentro da própria thread, sem cliente especial nem API de bot

Ou seja, a pergunta da delegação já nasce em cima da mesa: até onde deixar ele mexer?

Bora destrinchar isso 🙂

O que é o Hermes Agent e em que ponto ele está agora

O Hermes Agent é um projeto open source da Nous Research, com repositório oficial no GitHub sob a organização NousResearch

A descrição do próprio repo já entrega a proposta: "The agent that grows with you"

Ele cria skills sozinho depois de tarefas mais complexas (5 ou mais chamadas de ferramenta), corrige skills que estão desatualizadas ou erradas durante o uso e mantém uma memória curada por ele mesmo em MEMORY.md

Guarda esse detalhe, porque ele volta lá na parte de risco

Em que versão o projeto está:

A release mais recente publicada é a v0.20.1, tag v2026.8.13, de 13/08/2026

Antes dela veio a v0.20.0, tag v2026.8.3, de 03/08/2026

E tem um detalhe honesto de anotar: a v0.20.1 é descrita como um rollup de estabilização e correções, e as notas detalhadas do período ficaram prometidas para a v0.21.0

Isso quer dizer que é software em movimento rápido, com documentação de ciclo ainda em aberto

Não é motivo pra não usar, é motivo pra não delegar tudo de uma vez

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

Os quatro caminhos de e-mail no Hermes: adapter nativo, Himalaya, Google Workspace e AgentMail

Antes de decidir o quanto delegar, tu precisa saber POR ONDE o agente encosta no e-mail

São quatro caminhos diferentes, e eles não são intercambiáveis

Repara numa coisa: o adapter nativo e a skill Himalaya são coisas separadas

O adapter é o canal de conversa por IMAP/SMTP, a skill Himalaya é gerência de caixa por comandos de terminal

E a própria doc do Google Workspace dá o atalho: se você quer SÓ e-mail, sem Calendar, Drive ou Sheets, a alternativa é a skill himalaya com App Password do Gmail

Triagem, resumo e rascunho: o que realmente vale delegar

Agora o que interessa

Cada tarefa da caixa de entrada tem um caminho técnico certo e um nível de risco próprio, e misturar os dois é onde o povo se machuca

Triagem e leitura: o caso mais tranquilo

Listar, buscar e mover mensagem é exatamente o que a skill Himalaya faz direto pela ferramenta de terminal, com --output json quando você quer saída estruturada pra ele processar

É leitura e organização: nada sai da sua caixa pra ninguém

E do lado do adapter nativo tem uma proteção que ajuda bastante aqui: mensagem de remetente não autorizado é ignorada por padrão

A justificativa da doc é bem pé no chão: caixa de entrada é cheia de mensagem não lida que não tem NADA a ver com o agente

O agente pode fazer sozinho: ler, listar, buscar, marcar e mover

Passa pelo dono: apagar em massa, sempre

Resumo dentro da própria thread

Aqui o adapter nativo brilha

Ele mantém o threading com os cabeçalhos In-Reply-To e References, então o resumo chega no lugar certo da conversa em vez de virar um e-mail solto que você nunca mais acha

Você manda a pergunta por e-mail, ele responde na mesma thread

E repara pra QUEM essa resposta vai: volta pra quem perguntou, ou seja, pra você, que está na allowlist

Não é mensagem saindo em seu nome pra um terceiro, é o canal de conversa fazendo o que ele existe pra fazer

O agente pode fazer sozinho: resumir o que já está na caixa dedicada e devolver o resumo na thread que você abriu

Passa pelo dono: nada, desde que a conta seja dedicada e a allowlist só tenha você

Rascunho de resposta: começa a esquentar

Compor, responder e encaminhar existem no Himalaya, e a recomendação da doc é fazer isso via entrada em pipe

O canal de saída é o mesmo SMTP da seção anterior, o que muda é o DESTINATÁRIO: aqui a mensagem sai da caixa pra alguém que não é você

E é essa troca de destinatário que muda o nível de risco, não o mecanismo de envio

E aqui vai a parte honesta: eu não encontrei na documentação nenhuma confirmação de que enviar e-mail entre na lista de padrões perigosos que dispara pedido de aprovação, nem um modo nativo de "somente rascunho" que salvasse a resposta sem mandar

Então não conte com um freio que você não viu documentado

Se você quer humano no loop no envio pra fora, o freio tem que ser a allowlist e a configuração de aprovação, não a esperança

O agente pode fazer sozinho: escrever o texto

Passa pelo dono: mandar pra qualquer destinatário que não seja você

Rotina rodando sem ninguém olhando

O Hermes tem agendamento por cron, além de integração MCP e vários backends de terminal

E do lado da AgentMail, e-mail de entrada em tempo real por webhook exige servidor público, então a alternativa citada pra uso pessoal é polling de list_threads por cronjob

Ou seja: dá pra montar uma rotina que roda de madrugada tranquilamente

E não é terra sem lei, tem rede embaixo: o sistema de aprovação falha fechado quando não existe humano no canal, e o gateway ainda tem um watchdog só de aviso pra sessão que empaca (volto nele lá no checklist)

Só que nenhum dos dois decide POR você o que pode sair da caixa pra fora

Por isso rotina sem humano é justamente onde a decisão de deixar o agente sempre ligado deixa de ser conforto e vira política de segurança

O agente pode fazer sozinho: triar e resumir em horário fixo

Passa pelo dono: qualquer coisa que saia da caixa pra fora

Os quatro riscos de soltar um agente na sua caixa (e como prevenir cada um)

Agora a parte que ninguém gosta de ler e todo mundo precisa

1. Sintoma: o agente responde pra quem não devia

Causa: qualquer um que consiga mandar mensagem pro canal vira interlocutor

O que o Hermes oferece: a autorização é avaliada em camadas, nesta ordem: flag de allow-all por plataforma, allowlist da plataforma (lista de IDs separada por vírgula), pareamento por DM com código aprovado pelo dono e allow-all global (GATEWAY_ALLOW_ALL_USERS)

No e-mail, o padrão é ignorar não autorizado, a menos que você configure platforms.email.unauthorized_dm_behavior: pair

Como prevenir: allowlist estreita e o padrão de ignorar mantido

E se liga nisso, que é o ponto mais subestimado: usuário autorizado no gateway tem acesso pleno às capacidades do agente, o que inclui uso de ferramentas e acesso ao sistema, não só conversa

Autorizar alguém no e-mail não é "deixar a pessoa trocar ideia com o bot"

2. Sintoma: o agente executa algo perigoso que veio dentro de um e-mail

Causa: e-mail é conteúdo de fora, e conteúdo de fora tenta virar instrução

O que o Hermes oferece: antes de executar um comando, ele compara com uma lista curada de padrões perigosos e exige aprovação explícita

São três modos, configurados em approvals.mode dentro de ~/.hermes/config.yaml

O gateway ainda intercepta comandos de controle vindos das plataformas de mensagem: /stop, /new, /queue, /status, /approve e /deny

Abaixo disso tem uma blocklist que recusa comandos catastróficos independentemente do modo de aprovação (os rm -rf da vida em sistema de arquivos, fork bombs, escrita direta em dispositivo de bloco), sem flag de override

E tem o Tirith integrado, varrendo o conteúdo dos comandos antes da execução, pegando coisa como spoofing de URL por homógrafos e padrão de pipe pra interpretador

Como prevenir: manter aprovação ligada e ficar longe de hermes --yolo, hermes chat --yolo e do comando /yolo na sessão

Enquanto o YOLO está ativo o Hermes mostra dois lembretes visuais persistentes, o que já diz muito sobre o que ele acha da ideia haha

E approvals.mode: off desativa TODOS os prompts de segurança: é indicado só pra ambiente confiável, tipo CI/CD e container

Caixa de entrada não é isso

3. Sintoma: prompt injection e credencial vazando

Causa: o agente lê arquivo de contexto que você não escreveu

O que o Hermes oferece: varredura de prompt injection nos arquivos de contexto, procurando unicode invisível, tentativa de sobrescrever instruções ("ignore previous instructions", "disregard your rules") e padrões de exfiltração de credenciais

A própria doc avisa: o scanner não substitui a revisão manual de arquivo de contexto que você não escreveu

E vai além no reconhecimento do risco: um agente com prompt injection pode exfiltrar credenciais lendo arquivos de configuração ou variáveis de ambiente, mesmo dentro de sandbox Docker

A mitigação citada é o proxy de egresso iron-proxy, em que o sandbox guarda tokens opacos e o daemon local troca por credencial real no tráfego de saída

Como prevenir: revisar contexto de origem duvidosa na mão e, se o conteúdo da caixa é sensível, pensar no proxy de egresso antes de escalar o uso

Se o incômodo é o teor dos e-mails saindo pra uma API lá fora, a discussão de rodar o modelo com Ollama muda bastante a conta

4. Sintoma: o comportamento muda sozinho com o tempo

Causa: o Hermes cria skills sozinho depois de tarefas com 5 ou mais chamadas de ferramenta, corrige skills durante o uso quando elas estão desatualizadas, incompletas ou erradas, e mantém MEMORY.md curado por ele mesmo

Isso é ótimo pro fluxo de trabalho e é exatamente o que "the agent that grows with you" quer dizer

Agora, numa caixa de entrada, quer dizer que a rotina que você aprovou em agosto pode não ser a mesma rotina em outubro

Como prevenir: revisar skill que mexe com e-mail de tempos em tempos

E tem caminho de volta pras bundled: hermes skills reset <nome> --restore

O que segura a onda quando ninguém responde:

Uma coisa boa de arquitetura: o sistema de aprovação falha FECHADO

Chamador não interativo (ponte de arquivos ACP, job em background sem canal humano) é negado

E o prompt de comando perigoso tem timeout configurável que nega por padrão se ninguém responder

Ou seja, esquecer o agente rodando não vira carta branca automática

O mínimo para delegar e-mail sem susto

Checklist curto do que precisa estar de pé ANTES de apontar o agente pra qualquer caixa

1. Crie uma conta de e-mail dedicada. A recomendação é da própria documentação: não aponte pro seu e-mail pessoal, porque o agente guarda a senha no arquivo .env e tem acesso total à caixa via IMAP

O erro comum deste passo: começar "só pra testar" na conta principal e nunca migrar depois

2. Gere um App Password em vez da senha principal. No Gmail com autenticação em dois fatores, o App Password é exigido

O erro comum deste passo: colar a senha da conta e ficar quebrando a cabeça com falha de autenticação que não é do Hermes

3. Rode o assistente interativo da CLI, que é o caminho recomendado de configuração dos canais de mensageria:

hermes gateway setup

Ele guia a configuração de cada plataforma, mostra o que já está configurado e oferece iniciar ou reiniciar o gateway

No e-mail ele pergunta endereço, senha, hosts IMAP/SMTP e remetentes permitidos

4. Confira as variáveis do canal de e-mail. São estas:

EMAIL_ADDRESS=
EMAIL_PASSWORD=      # App Password, não a senha principal
EMAIL_IMAP_HOST=
EMAIL_SMTP_HOST=
EMAIL_ALLOWED_USERS=

O erro comum deste passo: deixar EMAIL_ALLOWED_USERS largo demais, lembrando que autorizado ali significa acesso a ferramentas e ao sistema

5. Deixe o padrão de ignorar remetente não autorizado como está, a não ser que você tenha um motivo MUITO claro pra ligar platforms.email.unauthorized_dm_behavior: pair

6. Saiba onde fica o aviso de sessão travada. O gateway tem um watchdog só de notificação, agent.session_stall_timeout, com padrão de 300 segundos (0 desativa), que avisa quando existe follow-up pendente e o relógio de atividade ficou parado

É aviso, não é freio: serve pra você perceber que alguma coisa empacou

Veredito: até onde delegar a caixa de entrada ao Hermes Agent

Três faixas, e cada uma justificada por fato, não por gosto

Delegue sem medo: leitura, busca, organização e resumo, em conta dedicada

Por quê: Himalaya faz ler, listar, buscar, mover e apagar direto pela ferramenta de terminal, o adapter nativo mantém o resumo na thread certa com In-Reply-To e References, e o padrão do canal é ignorar remetente não autorizado

Nada disso manda mensagem em seu nome pra ninguém: a resposta na thread volta pra quem está na allowlist, ou seja, pra você

Delegue com humano no loop: rascunho e resposta pra fora

Por quê: compor, responder e encaminhar são recomendados via pipe no Himalaya, e o envio sai pelo SMTP do adapter

Como não está documentado que enviar e-mail dispare pedido de aprovação, o teu controle real é EMAIL_ALLOWED_USERS estreito mais aprovação ligada em approvals.mode, com /approve e /deny na mão

Não delegue ainda: caixa pessoal principal, envio autônomo por cron sem revisão e qualquer YOLO ou approvals.mode: off fora de ambiente descartável

Por quê: a doc pede conta dedicada porque a senha vive no .env e o acesso IMAP é total, o modo off é indicado só pra ambiente confiável tipo CI/CD e container, e a doc assume que exfiltração de credencial por prompt injection é possível mesmo em sandbox Docker

Somando a isso: as notas detalhadas do ciclo da v0.20.1 ficaram pra v0.21.0, então parte do que mudou recentemente ainda não está descrita de forma curada

Delegar o envio às cegas em cima disso é apostar, não é decidir

Conclusão

Resumo do veredito: leitura, triagem e resumo em conta dedicada é uso maduro e tranquilo do Hermes Agent no e-mail

Escrever e mandar pra fora é onde você continua sendo o adulto da sala, com allowlist curta e aprovação ligada

O próximo passo concreto é bem simples: cria a conta dedicada, gera o App Password, roda hermes gateway setup, e passa as primeiras semanas SÓ com triagem e resumo

Só depois disso, e com allowlist estreita, você abre o envio

E vale ficar de olho na v0.21.0, que é onde a documentação detalhada desse ciclo ficou prometida

Quando ela sair, a gente revisita essa conta por aqui…

até o próximo post! 🙂