Todo usuário pesado de Hermes Agent conhece aquele momento: você está vendo o agente trabalhar, tudo vai bem, e de repente —pum— aparece um pedido de aprovação. Você realmente leu? Sejamos honestos. Depois do quinquagésimo aviso de rm no dia, a maioria só aperta «aprovar». Isso é fadiga de aprovação, e é uma brecha de segurança vestida de conveniência: quanto mais prompts você carimba sem pensar, menos significado cada um tem.

O Hermes v0.19.0 (a Quicksilver Release) atacou esse problema pela raiz. As aprovações inteligentes agora são o padrão: em vez de pedir que você aprove cada comando sinalizado, o Hermes faz um revisor LLM independente avaliar cada um, aprovar automaticamente os de baixo risco, negar automaticamente os realmente perigosos e só escalar os incertos para você. Menos interrupções, mesmo controle humano — se tanto, mais forte, porque sua atenção só é gasta onde importa.

Este post é um guia prático: como o novo fluxo de aprovação realmente funciona, as chaves reais do config.yaml (verificadas contra o código-fonte do v0.19, não contra lendas) e como definir linhas vermelhas que nem o modo yolo consegue cruzar.

O problema: fadiga de aprovação é um bug de segurança

A aprovação manual funcionava quando os agentes executavam um punhado de comandos por sessão. Agentes modernos executam dezenas ou centenas. Cada prompt é uma troca de contexto; cada troca de contexto drena sua atenção; atenção drenada aprova coisas que não deveria. Pesquisadores de segurança têm um nome para isso —habituação— e é exatamente assim que passa o único comando que você deveria ter lido com cuidado.

O fluxo antigo tinha ainda um segundo problema: você era o classificador de risco. O Hermes sinalizava um comando, você julgava, pronto. A qualidade do julgamento dependia do quanto você estava desperto naquele momento exato — o pior design possível para um mecanismo de segurança.

As aprovações inteligentes corrigem as duas coisas: a classificação de rotina vai para um modelo que nunca se cansa, e a decisão final continua com você.

Como funcionam: três veredictos, um comando por vez

Quando o Hermes quer executar um comando que corresponde à sua lista de padrões perigosos, o fluxo não é mais «perguntar ao humano». É:

1. Um LLM auxiliar avalia o comando de forma independente — não o agente principal, mas um modelo revisor separado.
2. O revisor retorna um de três veredictos:
   • Seguro → aprovado automaticamente, sem interrupção.
   • Perigoso → negado automaticamente, com o motivo registrado.
   • Incerteza → escalado para você aprovar ou negar manualmente.

O detalhe importante está nas notas de versão: cada veredicto cobre apenas aquele comando exato. Um comando posterior que corresponda ao mesmo padrão recebe sua própria revisão nova. Não existe atalho do tipo «já aprovamos essa classe antes, aprove de novo». O revisor não pode ser anestesiado por padrões, e você também não — porque só vê os casos genuinamente ambíguos.

Você: "implanta o servidor de staging e roda a migração"
Hermes: [kubectl apply --dry-run ...]      → revisão: seguro, aprovado automaticamente
        [kubectl rollout restart ...]      → revisão: seguro, aprovado automaticamente
        [kubectl delete namespace prod]    → revisão: PERIGOSO, negado automaticamente
        [psql -c "DROP TABLE users;"]      → incerto → escalado para você

Esse é o fluxo que acaba com o concordar.

A configuração real: approvals.mode, não lendas

Se você leu posts antigos sobre as aprovações do v0.19, talvez tenha visto chaves inventadas como smart_approvals: true ou deny_rules: com campos pattern:/reason:. Elas não existem. O esquema real no config.yaml é:

# ~/.hermes/config.yaml
approvals:
  mode: smart        # smart | manual | off  (smart é o padrão)
  timeout: 300       # segundos de espera pela sua resposta antes de falhar fechado
  cron_mode: deny    # deny | approve — o que jobs cron fazem com comando sinalizado
  deny: []           # suas linhas vermelhas: padrões glob bloqueados incondicionalmente

Chave	Padrão	O que faz
mode	smart	Política de aprovação para comandos shell sinalizados
timeout	300	Segundos que o Hermes espera sua resposta antes de tratar como negação
cron_mode	deny	Comportamento sem supervisão: deny bloqueia comandos sinalizados em cron, approve executa
deny	[]	Padrões glob que bloqueiam comandos incondicionalmente — mesmo com yolo

Verifique sua configuração atual a qualquer momento:

hermes config | grep -A 4 approvals

Os três modos em português claro:

• smart (padrão) — a revisão LLM filtra comandos de rotina; os perigosos são negados; os incertos chegam até você.
• manual — todo comando sinalizado pergunta para você, como antes do v0.19.
• off — nenhum prompt de aprovação; equivalente a --yolo / HERMES_YOLO_MODE=1. Só para sandboxes confiáveis.

Linhas vermelhas: approvals.deny vence o yolo

Esta é a parte que torna seguro relaxar com o modo inteligente. A lista deny é um conjunto de padrões glob que bloqueiam comandos correspondentes incondicionalmente — antes de qualquer bypass do yolo, antes do /yolo, antes do mode: off. É a contraparte editável pelo usuário da lista negra rígida embutida no Hermes, e é a linha de defesa mais importante que você pode configurar:

approvals:
  mode: smart
  deny:
    - "git push --force*"
    - "rm -rf /"
    - "*curl*|*sh*"
    - "kubectl delete namespace*"

Os padrões são globs fnmatch insensíveis a maiúsculas. Coloque-os entre aspas no YAML — um * inicial sem aspas é erro de parse. Um comando correspondente é bloqueado com motivo registrado, sem discussão. Mesmo no modo yolo. Esta é sua lista de «não importa o quão confiante o agente esteja, isso nunca acontece», e deve conter as poucas operações cujos modos de falha são inaceitáveis: force-push em branches compartilhados, exclusões recursivas, exclusão de namespaces de produção, segredos escritos via CLI.

A saída para uma execução realmente deliberada? Nenhuma na configuração — e é esse o ponto. Se você precisa mesmo fazer um force-push, remova o padrão, execute o comando e o adicione de volta. O atrito é intencional e mínimo.

/deny <reason>: faça da recusa um ensinamento

As aprovações inteligentes não só reduzem prompts — elas tornam os prompts que você de fato responde mais valiosos. Quando o revisor escala um comando para você e você o recusa, agora pode dizer ao agente por quê:

O Hermes quer executar: docker system prune -a -f

> /deny agressivo demais — outros contêineres compartilham esse cache de imagens

O motivo é escrito de volta no contexto, e o agente corrige o rumo — procura um comando mais restrito em vez de tentar o mesmo de novo torcendo para você ceder. Uma recusa com motivo é feedback; uma recusa seca é um muro. Crie o hábito de dar uma frase de porquê, e a próxima tentativa do agente será visivelmente melhor.

A propósito: se o agente está indo completamente na direção errada, o /stop continua matando a execução na hora. O fluxo de aprovação e o botão de parada são complementares — um filtra comandos, o outro corta a sequência inteira.

Jobs cron: ninguém está lá para concordar

As aprovações inteligentes brilham em sessões interativas — mas e nas sem supervisão? Quando um job cron agendado encontra um comando sinalizado, não há usuário para escalar. O padrão cron_mode: deny lida com isso de forma conservadora: o comando é bloqueado e o agente precisa encontrar outro caminho. Se você confia em um job específico (por exemplo, um backup noturno que legitima limpa arquivos antigos), pode mudar a política dele:

approvals:
  cron_mode: approve   # aprova automaticamente comandos sinalizados em contexto cron

Pense bem antes de ativar isso. deny não custa nada quando o agente encontra um caminho alternativo; approve transforma cada prompt de cron em execução silenciosa. Para a maioria dos jobs, deny mais uma lista estreita de exceções em approvals.deny é a forma certa.

Qual modo você deve usar?

Situação	Recomendação
Trabalho interativo diário	smart (padrão) — você mantém o veto, perde o ruído
Cirurgia de repositório / operações destrutivas	smart + regras deny — linhas vermelhas para o irreversível
Sandbox totalmente confiável / contêiner CI	off ou --yolo, mas mantenha deny como rede de segurança
Nostalgia	manual — se você realmente quer todos os prompts de volta

Para a maioria das pessoas, a resposta é: deixe mode: smart, gaste dez minutos escrevendo regras deny e use /deny <reason> toda vez que recusar. Essa é toda a atualização.

Além das aprovações: defesa em profundidade

As aprovações inteligentes são uma camada do modelo de defesa em profundidade do Hermes, não a história inteira. Outras camadas que valem conhecer: os checkpoints tiram snapshots automáticos do sistema de arquivos antes de operações destrutivas (um erro vira rollback, não desastre), a redação de segredos limpa strings com formato de chave API das saídas de ferramentas antes de chegarem ao contexto ou aos logs, e o isolamento por contêiner (backends Docker/Singularity/Modal) pode encerrar a ferramenta de terminal por completo. As aprovações decidem se um comando roda; os checkpoints decidem o que acontece depois. Eles se compõem.

Resumo

As aprovações inteligentes do Hermes v0.19 não significam «o agente pode tudo agora». É o oposto: um humano cansado que carimbava cada prompt é substituído por um revisor incansável que filtra a rotina, bloqueia o perigoso e só traz à tona o ambíguo. A configuração real são três chaves e um hábito:

• approvals.mode: smart — o padrão que acaba com a fadiga de aprovação.
• approvals.deny: [...] — suas linhas vermelhas, ativas mesmo no modo yolo.
• approvals.cron_mode: deny — jobs sem supervisão continuam conservadores.
• O hábito: /deny <reason> — cada recusa ensina.

Seu agente ganha autonomia; você mantém cada grama de controle. Chega de concordar.

Quer mais guias de segurança e fluxo de trabalho do Hermes? Confira a análise aprofundada da v0.19.0, a configuração de aprovações com três portões, nosso explicador do modo yolo e o guia de tratamento de erros e recuperação. Novo no Hermes? Comece pelo guia de instalação.