52,8% dos usuários do Hermes já ativaram YOLO: você ainda não conhece esses 7 modos comuns?

Na comunidade Hermes, dizem que mais da metade dos usuários já ativou o YOLO pelo menos uma vez. Mas YOLO não é a história toda — é apenas um ponto extremo no espectro de segurança do Hermes. Quem realmente extrai o máximo do Hermes alterna entre sete modos comuns, em vez de recorrer a /yolo sempre que algo fica lento.

Hermes Agent é construído sobre uma premissa padrão forte: se você permite executar um comando, o agente deve assumir as consequências. Por isso, antes de executar qualquer coisa que possa danificar seu sistema, ele para e pergunta. Isso é chamado de Aprovação de Comandos Perigosos (Dangerous Command Approval), e YOLO é apenas uma forma de ignorá-la.

Este post cobre os sete modos de segurança e autonomia do Hermes. Depois de ler, você será capaz de dizer ao seu agente:

  • “O modo smart é suficiente para o desenvolvimento normal.”
  • “Eu rodo esse script com frequência, aprove para a sessão.”
  • “Vou fazer um refactoring em massa, ligue o YOLO, mas nunca permita git push --force.”
  • “Execute isso no Docker, assim não precisamos de aprovações e o host fica seguro.”

1. Modo smart: deixe a IA avaliar o risco (recomendado por padrão)

approvals:
  mode: smart

smart é o modo padrão do Hermes. Quando um comando corresponde a um padrão perigoso, o Hermes pede a um modelo auxiliar que avalie o risco real.

  • Comandos obviamente seguros (por exemplo, python -c "print('hello')") são aprovados automaticamente.
  • Comandos obviamente perigosos (por exemplo, rm -rf /) são negados automaticamente.
  • Casos incertos são escalados para você.

Isso reduz drasticamente a “fadiga de aprovação”. Você não precisa confirmar cada bash -c, enquanto ações realmente destrutivas ainda são detectadas.

Ideal para: desenvolvimento diário, tarefas exploratórias e ambientes nos quais você já confia no agente.

2. Modo manual: cada comando perigoso passa por você

approvals:
  mode: manual

Se você prefere não delegar a avaliação de risco a um modelo auxiliar, use o modo manual. Cada comando que corresponde a um padrão perigoso é pausado e aguarda sua aprovação.

Na CLI, o prompt costuma parecer assim:

⚠️  DANGEROUS COMMAND: recursive delete
    rm -rf /tmp/old-project

    [o]nce  |  [s]ession  |  [a]lways  |  [d]eny

    Choice [o/s/a/D]:

Quatro opções:

  • once: permite apenas esta execução.
  • session: permite este padrão pelo resto da sessão.
  • always: adiciona o padrão à sua lista de permissões permanente em ~/.hermes/config.yaml.
  • deny (padrão): bloqueia o comando.

Ideal para: trabalho de alta segurança, iniciantes ou execução de comandos desconhecidos.

3. Modo YOLO: ignore todos os prompts de aprovação

O modo YOLO ignora todas as aprovações de comandos perigosos. Você pode ativá-lo de três formas:

# Ao iniciar
hermes --yolo
hermes chat --yolo

# Durante uma sessão
/yolo

# Variável de ambiente
HERMES_YOLO_MODE=1

Quando ativo, o Hermes exibe um banner vermelho e um indicador na barra de status para que você não se esqueça de que a rede de segurança foi removida.

> /yolo
  ⚡ YOLO mode ON — all commands auto-approved. Use with caution.

YOLO se encaixa em cenários em que você tem certeza de que os comandos são seguros, como:

  • Scripts de automação repetidos;
  • Trabalho dentro de containers ou ambientes descartáveis;
  • Tarefas nas quais você está atento e pode pressionar Ctrl+C a qualquer momento.

Mas lembre-se: YOLO não é 100% irrestrito — a lista negra hardline que veremos a seguir ainda se aplica.

4. Lista negra hardline: o limite que nem YOLO consegue cruzar

Mesmo com approvals.mode: off ou /yolo ativado, o Hermes ainda recusa certos comandos irreversíveis e catastróficos. Essa é a lista negra hardline.

Exemplos:

Comando Por que está bloqueado
rm -rf / Apaga o sistema de arquivos raiz
:(){ :|:& };: Bomba fork do bash
mkfs.* contra um dispositivo raiz montado Formata o sistema em execução
dd if=/dev/zero of=/dev/sd* Zera um disco físico
Canalizar URLs não confiáveis para sh Superfície de ataque de execução remota de código muito grande

Esses padrões são mantidos em tools/approval.py::UNRECOVERABLE_BLOCKLIST e não podem ser substituídos por nenhuma flag.

Filosofia de design: YOLO significa “eu confio que a IA não cometerá erros”, enquanto a lista hardline significa “mesmo que a IA — ou o usuário — erre, a máquina não pode ser destruída”.

5. Regras deny personalizadas: YOLO com exceções

Se YOLO parece muito permissivo e manual muito barulhento, use approvals.deny para traçar suas próprias linhas vermelhas:

approvals:
  mode: off           # efetivamente YOLO
  deny:
    - "git push --force*"
    - "*curl*|*sh*"
    - "dd if=* of=/dev/*"

As regras são curingas fnmatch insensíveis a maiúsculas e minúsculas, comparadas com o texto completo normalizado do comando. Mesmo sob YOLO, um comando correspondente é bloqueado rigorosamente.

Isso é perfeito para cenários do tipo “Eu confio na maioria das operações, mas algumas ações nunca são permitidas”:

  • Deixe o agente editar código e executar testes livremente, mas proíba git push --force;
  • Permita que ele baixe dependências, mas bloqueie curl ... | sh;
  • Permita que ele opere Docker, mas nunca escreva diretamente em dispositivos de bloco.

6. Modo write approval: controle as gravações de memória e skills

Além dos comandos de terminal, o Hermes também escreve coisas por conta própria: salva fatos importantes na memory e fluxos aprendidos como skills. Se você teme que ele “aprenda coisas erradas”, ative o write approval.

memory:
  write_approval: true

skills:
  write_approval: true

Quando ativado, cada gravação de memória ou skill fica em espera em ~/.hermes/pending/ até que você revise e aprove:

# Revisar gravações de skills pendentes
/skills pending
/skills diff <id>
/skills approve <id>
/skills reject <id>

# O mesmo para memory
/memory pending
/memory approve <id>
/memory reject <id>

Ideal para:

  • Impedir que o agente memorize automaticamente informações sensíveis ou incorretas;
  • Instâncias compartilhadas do Hermes onde skills aprendidas precisam de revisão humana;
  • Depurar o ciclo de aprendizado antes de permitir qualquer persistência.

7. Isolamento por containers: substitua aprovações por fronteiras

O último modo não é sobre como aprovar, mas sobre tornar as aprovações desnecessárias. O Hermes oferece suporte a vários backends de terminal:

Backend Isolamento Verificação de comandos perigosos
local Nenhum, roda no host ✅ Sim
ssh Máquina remota ✅ Sim
docker Container ❌ Ignorada (o container é a fronteira)
singularity Container ❌ Ignorada
modal Sandbox na nuvem ❌ Ignorada
daytona Sandbox na nuvem ❌ Ignorada

Ao executar no Docker, Modal ou Daytona, as verificações de comandos perigosos são ignoradas porque, mesmo que o container seja destruído, o host permanece ileso. Gateways de produção do Hermes costumam ser configurados assim.

Os containers Docker também são executados com um conjunto padrão de flags de segurança endurecidas:

_BASE_SECURITY_ARGS = [
    "--cap-drop", "ALL",
    "--security-opt", "no-new-privileges",
    "--pids-limit", "256",
    "--tmpfs", "/tmp:rw,nosuid,size=512m",
]

Ideal para: implantações de produção, CI/CD, ambientes multilocatários e qualquer sandbox onde a destruição seja aceitável.

Tabela rápida para escolher o modo certo

Modo Aprovação de comandos Aprovação de gravações Quando usar
smart Pré-verificação por IA + revisão humana em casos limítrofes Opcional Padrão para desenvolvimento diário
manual Todos os comandos perigosos exigem aprovação humana Opcional Tarefas de alto risco ou iniciantes
YOLO Todos os comandos perigosos ignorados Opcional Automação temporária, scripts confiáveis
hardline Comandos catastróficos bloqueados permanentemente Não aplicável Piso de segurança sempre ativo
deny rules Padrões de bloqueio personalizados Não aplicável YOLO com exceções
write approval Opcional Obrigatória para gravações de memory/skill Impedir que o agente aprenda coisas erradas
container isolation Sem verificação Limitada pelo container Produção ou sandbox

Recomendações práticas

  1. Fique no padrão: o modo smart cobre a maior parte do trabalho diário sem interrupções constantes.
  2. Use aprovação por sessão para lotes: mais seguro que YOLO, mas evita confirmar cada comando.
  3. Combine YOLO com regras deny: se for usar YOLO, mantenha pelo menos algumas linhas vermelhas personalizadas.
  4. Execute produção no Docker: o isolamento é mais confiável do que aprovações e elimina a fadiga de aprovação completamente.
  5. Audite sua lista de permissões: command_allowlist cresce com o tempo. Limpe-a periodicamente com hermes config edit.
  6. Ative write approval para Hermes compartilhado: especialmente importante ao executar um gateway de longa duração em equipe.

Conclusão

O sistema de aprovação do Hermes não existe para te atrasar. Ele existe para ajudar você a equilibrar delegação confiante e frenagem a tempo. YOLO é divertido, mas é apenas um dos sete modos. Os usuários avançados sabem quando ficar em smart, quando mudar para manual, quando desligar o YOLO e quando deixar o Docker fazer o trabalho de segurança por eles.

Da próxima vez que você for digitar /yolo, pergunte-se: Eu realmente preciso ignorar todas as aprovações, ou uma aprovação por sessão mais uma regra deny seria suficiente?