Tutorial 29: Mergulho Profundo em Segurança

Bem-vindos de volta, domadores de agentes! Hoje vamos colocar nossos capacetes e fazer um mergulho profundo no modelo de segurança do Hermes Agent. Se você já se perguntou o que acontece nos bastidores para manter suas sessões seguras, este tutorial é para você.

O Panorama Geral: Oito Camadas de Defesa

O Hermes não depende de uma única fechadura na porta. Em vez disso, ele usa uma abordagem de defesa em profundidade com oito camadas distintas de segurança. Pense nisso como um castelo: mesmo que alguém atravesse o fosso, ainda enfrenta as muralhas, os portões e os guardas lá dentro.

Aqui está a formação:

Autorização do usuário — quem pode conversar com o agente
Aprovação de comandos perigosos — verificação humana para ações destrutivas
Segurança na escrita de arquivos — listas de bloqueio e sandboxes para operações com arquivos
Isolamento por contêiner — sandboxing com Docker/Singularity/Modal
Filtragem de credenciais MCP — mantendo segredos longe de subprocessos
Varredura de arquivos de contexto — detecção de injeção de prompt em arquivos do projeto
Isolamento entre sessões — sessões não podem bisbilhotar os dados umas das outras
Sanitização de entrada — bloqueio de injeção de shell via parâmetros de diretório de trabalho

Cada camada importa, mas hoje vamos focar naquela com a qual você vai interagir mais: aprovação de comandos perigosos.

Como Funciona a Aprovação de Comandos Perigosos

Antes de o Hermes executar qualquer comando, ele o verifica contra uma lista curada de padrões perigosos. Se houver correspondência, você decide o que acontece em seguida.

Você controla esse comportamento através da seção approvals no ~/.hermes/config.yaml:

approvals:
  mode: smart                     # smart | manual | off
  timeout: 300                    # segundos para aguardar resposta do usuário
  cron_mode: deny                 # deny | approve
  single_query_mode: deny         # deny | approve
  mcp_reload_confirm: true        # confirmar antes de recarregar ferramentas MCP
  destructive_slash_confirm: true # confirmar antes de /clear, /new, etc.

Três Modos de Aprovação

A chave mode oferece três opções:

Modo	Comportamento
smart (padrão)	Usa um LLM auxiliar para avaliar o risco. Comandos de baixo risco (como `python -c "print('hello')"`) são aprovados automaticamente. Os realmente perigosos são negados automaticamente. Casos incertos são escalados para uma solicitação manual.
manual	Sempre pede sua aprovação para comandos perigosos. Sem exceções.
off	Desativa todas as verificações de aprovação. Equivalente a rodar com `--yolo`.

⚠️ Aviso: Definir approvals.mode: off desativa todos os avisos de segurança. Só faça isso em ambientes confiáveis, como pipelines de CI/CD ou contêineres descartáveis.

Modo YOLO: O Grande Botão Vermelho

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

Flag de CLI: hermes --yolo ou hermes chat --yolo
Comando de barra: Digite /yolo durante uma sessão
Variável de ambiente: Defina HERMES_YOLO_MODE=1

O comando /yolo é um alternador — cada uso liga ou desliga:

> /yolo
  ⚡ Modo YOLO ATIVADO — todos os comandos aprovados automaticamente. Use com cautela.

> /yolo
  ⚠ Modo YOLO DESATIVADO — comandos perigosos exigirão aprovação.

Quando o YOLO está ativo, o Hermes garante que você não vai esquecer. Você verá uma faixa vermelha no início da sessão e um fragmento ⚠ YOLO na barra de status, atualizado ao vivo conforme você alterna.

⚠️ Perigo: O modo YOLO desativa todas as verificações de segurança de comandos perigosos — exceto a lista de bloqueio rígida. Use-o apenas quando confiar totalmente nos comandos sendo gerados (por exemplo, scripts de automação bem testados em ambientes descartáveis).

Novo Nesta Versão: Chaves de Configuração Mais Inteligentes

Duas novas chaves de configuração merecem atenção especial:

mcp_reload_confirm (padrão: true) — Quando ativada, o /reload-mcp pergunta antes de reconstruir o conjunto de ferramentas MCP. Por quê? Porque reconstruir invalida o cache de prompt do provedor, o que significa que a próxima mensagem reenvia os tokens de entrada completos. Esse é um custo que você pode querer aprovar antes.

destructive_slash_confirm (padrão: true) — Quando ativada, comandos de sessão destrutivos (/clear, /new, /reset, /undo) pedem confirmação antes de descartar o estado da conversa. Você recebe um diálogo com três opções: Aprovar uma vez / Sempre aprovar / Cancelar. No Telegram, Discord e Slack, isso é roteado através de botões nativos de sim/não. Em outros lugares, cai para texto.

A TUI também respeita essa configuração para seus modais de /clear, /new e /reset. E se você está automatizando coisas, HERMES_TUI_NO_CONFIRM=1 força a pulagem desse modal completamente.

Sessões Sem Cabeça: Cron e Consulta Única

O que acontece quando um job de cron ou uma sessão de uma única execução hermes chat -q encontra um comando perigoso? Não há nenhum humano esperando para responder a uma solicitação.

É aí que entram cron_mode e single_query_mode:

deny (padrão) — Bloqueia o comando. O agente precisa encontrar outro caminho.
approve — Aprova automaticamente tudo nesse contexto.

Ambos têm como padrão deny por um bom motivo: melhor prevenir do que remediar quando ninguém está olhando.

Concluindo

O modelo de segurança do Hermes Agent tem tudo a ver com dar a você controle sem atrapalhar. O modo de aprovação inteligente cuida das coisas chatas automaticamente, enquanto o modo manual oferece supervisão total quando você precisa. E se você está em um ambiente confiável, o modo YOLO permite que você se mova rápido.

Só lembre: com grandes poderes vêm grandes responsabilidades. Use o YOLO com sabedoria!

Na próxima, vamos explorar como personalizar o sistema de aprovação para seu fluxo de trabalho específico. Até lá, fique seguro por aí!