Hermes Agent errou uma tarefa importante: como reduzir o estrago antes que aconteça

Agente de IA errando não é exceção, é evento esperado

Se tu roda qualquer agente autônomo por tempo suficiente, uma hora ele vai interpretar mal um pedido, rodar o comando errado no diretório errado ou apagar algo que você achava seguro

Então a pergunta certa nunca foi "como eu confio no Hermes Agent?"

A pergunta é: o que acontece com o meu projeto no dia em que ele erra?

Esse post organiza as camadas de contenção do Hermes Agent, o agente de IA open source da Nous Research, do escopo apertado até o desfazer

Nada de fórmula mágica, é desenho de processo mesmo

O agente executou um comando destrutivo que você não autorizou

Sintoma: você olha o histórico e vê um comando de escrita ou remoção que rodou sem passar por você

Causa provável: o modo de aprovação estava frouxo

Antes de falar dos modos, vale saber que existe uma camada abaixo de todos eles: uma blocklist de comandos catastróficos que age ANTES da camada de aprovação e não tem flag de override

Ou seja, alguns comandos são recusados independentemente da configuração que tu escolher (volto nela no fim do post)

Feito o aviso, bora pros modos

O sistema de aprovação do Hermes Agent tem três modos, configurados em approvals.mode dentro de ~/.hermes/config.yaml: manual, smart e off

O manual é o padrão e sempre pergunta

O smart usa um LLM auxiliar pra avaliar se o comando sinalizado é realmente perigoso, e devolve três veredictos: APPROVE (auto-libera), DENY (bloqueia) ou ESCALATE (cai no prompt manual)

Formação Recomendada

Formação Claude Code

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

• 114 aulas
• 4 projetos
• 9h 18min

Conhecer formação

Se liga no detalhe que morde: quando o smart auto-aprova, aquele padrão ganha aprovação no escopo da sessão

Ou seja, o comando que passou uma vez tende a passar de novo, sem te perguntar nada

E o off desativa todos os prompts de segurança, recomendado só pra ambiente confiável (CI/CD, container e afins)

Só que off não é terra sem lei: a blocklist que citei ali em cima continua valendo mesmo com approvals.mode: off, porque ela não é um prompt, é um piso

E se a aprovação veio de uma sessão antiga?

Tem uma segunda causa, mais silenciosa que a primeira

Uma aprovação pode ser guardada em três escopos: once (não salva nada), session (fica só na memória) e always

O always é gravado em ~/.hermes/config.yaml e carregado no startup, aplicado silenciosamente nas sessões seguintes

Traduzindo: aquele "sim, pode" que tu deu com pressa três semanas atrás continua valendo hoje, sem aviso nenhum

Solução:

1. Deixe approvals.mode: manual como padrão de trabalho, e só desça pro smart quando o atrito estiver realmente atrapalhando
2. Configure o tempo de espera com approvals.timeout, que é 60 segundos por padrão e tem comportamento fail-closed: se ninguém responde, o comando é negado
3. Abra o ~/.hermes/config.yaml e leia o que ficou salvo como always, porque essa é a lista de coisas que o agente faz sem te consultar

approvals:
  mode: manual
  timeout: 60

O erro comum aqui é achar que escolher always é um atalho de produtividade

Não é atalho, é decisão permanente gravada em arquivo

Se você quer aprofundar essa parte antes de plugar o agente em conta, chave e serviço seu, vale olhar o que avaliar antes de dar acesso

O agente tinha acesso a muito mais do que a tarefa pedia

Sintoma: o erro em si até foi pequeno, mas o estrago passou longe do escopo da tarefa

Causa: superfície aberta demais

Todos os toolsets ligados, agente rodando direto no host, com o projeto inteiro ao alcance da mão

É como contratar alguém pra trocar uma lâmpada e entregar a chave de todos os cômodos da casa

Solução, em duas camadas

A camada leve é reduzir a superfície de ferramentas

As ferramentas do Hermes Agent são organizadas em toolsets, que podem ser ligados ou desligados por plataforma

hermes tools

Sem a flag --summary, esse comando abre uma UI curses de configuração por plataforma

E tem o interruptor único: a chave disabled_toolsets no arquivo de configuração é aplicada depois da configuração por plataforma, e sempre remove o toolset listado

É o "desliga em todo lugar", útil justamente pra você não depender de lembrar o que marcou em qual plataforma

A camada dura é outra: backend de sandbox

Com os backends docker, singularity, modal, daytona e vercel_sandbox, a checagem de comando perigoso é pulada, porque o próprio container passa a ser a fronteira de segurança

Parece contraintuitivo, né? Mas é coerente com o que a documentação oficial de segurança diz na cara: a única fronteira de segurança contra um LLM adversarial é o sistema operacional

Nada dentro do processo do agente é contenção

Nem o portão de aprovação, nem redação de saída, nem scanner de padrões, nem allowlist de ferramentas: tudo isso é heurística sobre texto que o atacante pode influenciar

Raro ver projeto sendo tão honesto sobre o próprio limite, e isso conta muito a favor

Como prevenir: escopo apertado por padrão, ampliação só quando a tarefa exigir

O container não protegeu o que você achava que estava protegido

Esse sintoma vem em dois sabores opostos, e os dois assustam

Sabor 1: você ligou o backend Docker e mesmo assim viu arquivo do host sendo mexido

Sabor 2: o agente simplesmente "não enxerga" o projeto e fica dando voltas

Causa: por padrão o Hermes não passa o diretório de trabalho do host pra dentro do container

É preciso optar explicitamente por isso

Sem esse opt-in, o /workspace é do sandbox, e o compartilhamento só acontece via docker_volumes, com a sintaxe host_path:container_path[:options]

Solução: conhecer o bloco terminal antes de sair rodando

terminal:
  backend: docker
  docker_image: sua-imagem
  docker_volumes:
    - /caminho/do/host/projeto:/workspace/projeto

Além dessas, o bloco tem terminal.docker_forward_env, terminal.docker_env, terminal.docker_run_as_host_user, terminal.docker_extra_args, terminal.docker_persist_across_processes e terminal.docker_orphan_reaper

O backend Docker executa cada comando dentro de um container persistente, com endurecimento de segurança já ligado: todas as capabilities removidas, sem escalada de privilégio e limite de PIDs

E dá pra apertar recurso com container_cpu, container_memory e container_disk

O erro comum deste passo é o clássico da pressa: montar a raiz do trabalho inteiro num volume só pra parar de tomar erro de caminho

Aí o container vira teatro, porque a fronteira que você criou tem uma porta escancarada no meio

Monte só o caminho que a tarefa precisa

O estrago já aconteceu: como voltar atrás no Hermes Agent

Sintoma: arquivos alterados ou apagados, e a conversa contaminada com um estado que não bate mais com o disco

Causa: nenhum snapshot ativo no momento do erro

E aqui mora a pegadinha: os checkpoints são opt-in a partir da v2, ou seja, vêm desligados por padrão

Habilita por sessão assim:

hermes --checkpoints

Com isso ligado, o Hermes Agent tira snapshot do projeto antes de operações destrutivas

Os gatilhos incluem comandos como rm, rmdir, cp, install, mv, sed -i, truncate, dd, shred, redirecionamento de saída (>) e git reset / git clean / git checkout

O limite é de no máximo um checkpoint por diretório por turno

Onde esses snapshots ficam?

Em um repositório git sombra compartilhado, com store único em ~/.hermes/checkpoints/store/, com deduplicação entre projetos e turnos

O .git real do seu projeto não é tocado, o que evita aquela dor de cabeça de histórico bagunçado

Restaurando de verdade

O comando é o /rollback, e ele não é um pulo no escuro:

1. Rode /rollback diff primeiro, que mostra a prévia do que vai mudar
2. Rode /rollback pra restaurar os arquivos rastreados
3. Perceba que ele tira um snapshot pré-rollback, então dá pra desfazer o desfazer
4. Note também que ele desfaz o último turno da conversa, justamente pro contexto bater com o que está no disco

E pra conversa tem o /undo, que desfaz 1 turno por padrão e aceita contagem:

/undo 3

As linhas removidas ficam soft-deleted (active=0), guardadas pra auditoria, e somem das buscas e re-prompts

Como prevenir: ligar --checkpoints antes da tarefa arriscada

Depois do estrago, checkpoint desligado é só um arrependimento com nome técnico haha

Quando nem a aprovação salva você: o piso da blocklist

Tem uma expectativa comum de que exista um modo "libera tudo" de verdade

Muita gente lê o --yolo exatamente assim: ausência total de trava

Não é bem isso

Alguns comandos catastróficos são recusados independentemente da configuração, por uma blocklist que age antes da camada de aprovação e não tem flag de override

Estão nessa faixa casos como apagamento irreversível do sistema de arquivos, fork bombs e escrita direta em block device

A blocklist é o piso abaixo do --yolo

E é por isso que ela também segue de pé com approvals.mode: off: ela não depende de prompt nenhum pra agir

Mas repara na palavra: piso, não contenção

Contenção é SO ou container, o resto é heurística

As confirmações auxiliares que quase ninguém configura

O bloco approvals ainda tem outras chaves que valem cinco minutos do seu tempo:

approvals:
  cron_mode: deny
  mcp_reload_confirm: true
  destructive_slash_confirm: true

O cron_mode aceita deny ou approve, e é o que define o comportamento em execução agendada

Com o destructive_slash_confirm ativo, comandos de sessão destrutivos pedem confirmação antes de descartar o estado da conversa, com botões nativos de sim/não em Telegram, Discord e Slack

Vale pra /clear, /new, /reset e /undo

E no modo de uso do computador, ações destrutivas exigem aprovação: click, type, drag, scroll, key e focus_app pedem confirmação via diálogo do CLI ou botões na plataforma de mensagem

É o tipo de coisa chata no começo e salvadora depois 😀

O que aprendi rodando o Hermes Agent na prática

No vídeo abaixo eu mostro o Hermes Agent do zero, e algumas decisões que tomei ali dizem mais sobre contenção do que qualquer parágrafo teórico

A primeira: rodei o agente inteiro em uma VPS contratada só pra isso, em vez de instalar na minha máquina de trabalho

É a contenção mais barata que existe, porque se der ruim, deu ruim numa caixa descartável

Depois escolhi o quick setup, o modo mínimo, só pra colocar de pé e observar o comportamento antes de configurar o resto

Pulei a configuração do gateway de mensagens e deixei pra depois, usando o agente primeiro no terminal

Na parte de modelo, optei por um roteador de LLMs no lugar da API direta da Anthropic, porque quem usa agente com essas APIs tem corrido risco de bloqueio

E ao criar a chave de API eu defini limite de crédito, porque agente tende a consumir mais que uso normal, e mostrei que dá pra definir expiração da chave também

Antes de mandar tarefa real, pedi ao próprio agente um resumo das ferramentas dele, pra saber o que ele conseguia acessar: arquivos, navegação web, memória, tarefas recorrentes

Esse passo parece bobo e é dos mais úteis, porque conhecer a superfície é o que te permite decidir o que desligar

Comecei com pedidos de baixo risco, tipo uso de disco e memória da máquina

E aí veio o momento que resume o post: o agente marcou um comando de rede como perigoso e pediu confirmação

Eu liberei apenas uma vez, em vez de dar permissão ampla

Se liga em como isso conversa com os escopos: era exatamente a escolha entre once e always

Outra coisa que me chamou atenção: vi ele contornar um bloqueio de busca sozinho, trocando o buscador quando o primeiro barrou

Isso é ótimo pra tarefa e é justamente o que te faz respeitar a camada de contenção, porque um agente que dá jeitinho pra passar por obstáculo é um agente que vai dar jeitinho em outros lugares também

E fica o recado que eu já dei no vídeo: leia a documentação oficial em vez de confiar só no que um criador de conteúdo mostra, inclusive eu

Qual nível de contenção usar em cada situação

Não existe receita única aqui, existe combinação por cenário

Repara que o off não é o vilão do post: ele tem lugar, e o lugar dele é onde já existe container fazendo o trabalho pesado

O problema nunca é o modo, é usar o modo certo no ambiente errado

Se o que tu quer no fim das contas é rotina previsível e não um agente decidindo sozinho, aliás, vale comparar Hermes Agent ou n8n antes de escolher a ferramenta

Conclusão: desenhe o processo antes de precisar dele

Erro de agente é estatística, não azar

O que separa um incidente chato de um desastre é a camada que você preparou antes, quando ainda estava tudo calmo e nada tinha quebrado

O Hermes Agent te dá as peças: modos de aprovação com escopo, timeout que nega por omissão, toolsets desligáveis, sandbox como fronteira real, blocklist de piso e checkpoint com rollback previewável

Nenhuma delas se liga sozinha, e é aí que mora o perigo

Próximo passo concreto, hoje ainda:

1. Abra o ~/.hermes/config.yaml e confira o que está em approvals.mode
2. Leia a lista de aprovações salvas como always e apague o que você não reconhece mais
3. Rode hermes tools e desligue os toolsets que a sua rotina não usa, ou jogue eles em disabled_toolsets
4. Comece a próxima sessão com --checkpoints

Quinze minutos de configuração valem mais que qualquer plano de recuperação improvisado às três da manhã 😛

Até o próximo post!