Rodar em Máquina Pessoal ou de Trabalho

Você está prestes a rodar um agente na máquina em que vive — um notebook pessoal ou uma estação de trabalho gerenciada pela empresa. Qual é a postura segura?

Resposta curta: os padrões já fazem quase todo o trabalho. O Hermes vem seguro por padrão, com um modelo de defesa em profundidade que cobre aprovação de comandos, segurança na escrita de arquivos e tratamento de credenciais. Esta página mostra o que já vem ligado, quais parafusos apertar numa máquina compartilhada ou de trabalho, e como desfazer erros quando eles acontecem. Todo controle citado aqui está detalhado no guia de Segurança.

O que os padrões já protegem

Instalação nova, sem nenhuma configuração — estas proteções já estão ativas:

Comandos perigosos exigem aprovação. Antes de executar qualquer comando, o Hermes o compara com uma lista curada de padrões perigosos — remoções recursivas, escritas em /etc/, operações de disco, pipe para shell e mais. O padrão approvals.mode: smart usa um LLM auxiliar para avaliar o risco: comandos de baixo risco são aprovados automaticamente só para aquele comando, comandos realmente perigosos são negados automaticamente, e os casos duvidosos sobem para uma pergunta manual.

Os pedidos de aprovação falham fechado. Se você não responder a um pedido de aprovação dentro do tempo limite (300 segundos por padrão), o comando é negado. Sair da mesa nunca aprova nada em silêncio.

Uma lista de bloqueio absoluto é o piso, sempre ligado. Alguns comandos — rm -rf /, fork bombs, zerar um disco físico — são recusados independentemente do modo de aprovação, do --yolo ou de um "permitir sempre" explícito. A lista de bloqueio age antes de a camada de aprovação sequer ver o comando, e não existe flag para contornar.

Escritas em caminhos sensíveis são bloqueadas. As ferramentas write_file e patch não conseguem tocar em cofres de credenciais do sistema (~/.ssh/, ~/.aws/, ~/.kube/, /etc/sudoers, ~/.netrc), em cofres de credenciais do Hermes (auth.json, .env, dados de pareamento) nem em arquivos de segredo de projeto (.env, .env.local, .envrc) em qualquer lugar do disco. Escritas bloqueadas retornam erro na hora — não há pedido de aprovação e não há como contornar pela interface de chat.

Segredos são ocultados na saída. O security.redact_secrets vem ligado: padrões que parecem chaves de API, tokens e senhas na saída de ferramentas são ocultados antes de entrar no contexto da conversa e nos logs.

Seus dados só vão para onde você aponta. As chamadas de API vão apenas para o provedor de LLM que você configurar. O Hermes Agent não coleta telemetria, dados de uso nem analytics. Suas conversas, memória e skills ficam guardadas localmente em ~/.hermes/. Veja o FAQ.

informação

Há mais coisa embaixo da superfície — proteção contra SSRF em todas as ferramentas que aceitam URL, ambientes filtrados para subprocessos MCP, varredura de injeção de prompt em arquivos de contexto. A página de Segurança documenta cada camada.

Apertando os parafusos numa máquina compartilhada ou de trabalho

Numa máquina com dados da empresa, credenciais de produção ou arquivos de outras pessoas, acrescente estas camadas sobre os padrões.

Mude as aprovações para manual

O modo smart aprova sozinho os comandos de baixo risco. Se você quer ver com os próprios olhos todo comando sinalizado:

approvals:
  mode: manual

O modo manual sempre pergunta antes de executar um comando sinalizado.

Escreva suas próprias regras de negação

O approvals.deny é uma lista de padrões glob que bloqueiam comandos de terminal correspondentes de forma incondicional — mesmo sob --yolo, /yolo ou mode: off. É a contraparte editável pelo usuário da lista de bloqueio absoluto embutida. Use-a para declarar o que nunca pode rodar nesta máquina:

approvals:
  deny:
    - "git push --force*"
    - "*curl*|*sh*"
    - "dd if=* of=/dev/*"

Os padrões são globs fnmatch que ignoram maiúsculas e minúsculas e são comparados com o texto inteiro do comando; a comparação roda sobre as mesmas variantes normalizadas/desofuscadas que o detector de padrões perigosos usa, então truques simples de aspas não escapam de uma regra. Sempre coloque os padrões entre aspas — um * solto no começo é erro de parse do YAML. As mudanças valem na hora, sem reiniciar. Detalhes: Regras de negação próprias.

Isole as escritas de arquivo

O HERMES_WRITE_SAFE_ROOT restringe o write_file e o patch ao(s) prefixo(s) de diretório que você listar — qualquer coisa fora é bloqueada de vez. Vários diretórios raiz são separados por : no Unix:

export HERMES_WRITE_SAFE_ROOT=/caminho/do/projeto:/home/voce/.hermes

Caminhos sensíveis dentro do diretório seguro continuam bloqueados — apontar para $HOME não libera escrever em ~/.ssh/id_rsa.

cuidado

Não coloque isso no ~/.hermes/.env sem pensar. Se você apontar só para um diretório de projeto, o agente não consegue escrever em ~/.hermes/cron/jobs.json, nas skills de perfil, nem em outros estados do Hermes fora daquele prefixo. Inclua a sua pasta do Hermes como segundo diretório raiz, como acima.

Tire a execução de comandos do seu computador

O isolamento mais forte é não rodar comandos na sua máquina, ponto. A ferramenta de terminal suporta vários backends:

Backend	Isolamento
local	Nenhum — roda no host (as checagens de comando perigoso valem)
docker	Contêiner — o próprio contêiner é a fronteira de segurança
ssh	Máquina remota — mantém a execução em outro servidor

terminal:
  backend: docker
  docker_image: "nikolaik/python-nodejs:python3.11-nodejs20"
  docker_forward_env: []  # Só lista de permissão explícita; vazio mantém os segredos fora do contêiner

Todo contêiner Docker roda com configurações endurecidas — todas as capabilities do Linux removidas (com um conjunto mínimo devolvido), no-new-privileges, limite de número de processos e montagens tmpfs com tamanho limitado. Com um backend em contêiner, comandos destrutivos dentro do contêiner não conseguem prejudicar o host, e é por isso que as checagens de comando perigoso são puladas ali.

Para ssh, defina terminal.backend: ssh no config.yaml e informe os dados do host por TERMINAL_SSH_HOST, TERMINAL_SSH_USER e TERMINAL_SSH_KEY no ~/.hermes/.env. Veja Isolamento de rede.

Se as mensagens estiverem ligadas: listas de permissão e pareamento

Vai rodar o gateway nesta máquina? O padrão já é negar: se nenhuma lista de permissão estiver configurada e o GATEWAY_ALLOW_ALL_USERS não estiver definido, todos os usuários são negados. Mantenha isso explícito:

# ~/.hermes/.env
TELEGRAM_ALLOWED_USERS=123456789
GATEWAY_ALLOWED_USERS=123456789

Ou use o pareamento por mensagem direta em vez de fixar IDs: usuários desconhecidos recebem um código de pareamento de uso único, e você os aprova pela CLI com hermes pairing approve <plataforma> <código>. Nunca defina GATEWAY_ALLOW_ALL_USERS=true numa máquina com a qual você se importa.

A camada de desfazer: checkpoints e /rollback

Os portões de aprovação evitam o estrago; os checkpoints revertem. Quando ativados, o Hermes tira snapshots automáticos do seu projeto antes de operações destrutivas — write_file, patch e comandos de terminal destrutivos como rm, mv, sed -i e git reset — para um repositório git sombra em ~/.hermes/checkpoints/store/. O .git real do seu projeto nunca é tocado.

Os checkpoints são opcionais. Ative por sessão:

hermes chat --checkpoints

Ou globalmente:

checkpoints:
  enabled: true

Depois, dentro de uma sessão:

Comando	Descrição
/rollback	Lista todos os checkpoints com estatísticas de mudança
/rollback diff <N>	Pré-visualiza o que mudou desde o checkpoint N
/rollback <N>	Restaura para o checkpoint N (também desfaz o último turno do chat)
/rollback <N> <arquivo>	Restaura um único arquivo do checkpoint N

dica

Pré-visualize com /rollback diff <N> antes de restaurar, e combine checkpoints com worktrees do git para segurança máxima — cada sessão do Hermes no seu próprio worktree, com os checkpoints como camada extra.

O que este modelo de ameaça é — e o que não é

Tenha clareza sobre o que esses controles defendem. Como diz o guia de Segurança:

Regras de negação são uma proteção contra um agente honesto, mas errado — o mesmo modelo de ameaça do detector de padrões perigosos. Elas não são um sandbox contra um processo deliberadamente adversário — para isso, use um backend isolado (Docker, Modal) ou um ambiente com saída de rede restrita.

O mesmo vale para as proteções de escrita de arquivo: elas se aplicam apenas ao write_file e ao patch, enquanto a ferramenta terminal roda com o mesmo usuário do sistema. A lista de negação reduz o dano acidental e dá aos modelos um sinal claro de parada; ela não isola um agente hostil ou comprometido. Se o seu requisito é contenção e não guarda-corpo, a resposta é um backend de terminal isolado — é essa a fronteira feita para isso.

Uma configuração inicial cautelosa

Tudo o que está acima, montado. Ajuste ao seu gosto em ~/.hermes/config.yaml:

approvals:
  mode: manual                  # Veja você mesmo todo comando sinalizado
  timeout: 300                  # Pedidos sem resposta são negados (falha fechado)
  deny:                         # Lista do que nunca roda — sobrevive até ao /yolo
    - "git push --force*"
    - "*curl*|*sh*"
    - "dd if=* of=/dev/*"

security:
  redact_secrets: true          # Já é o padrão; aqui só para deixar claro

checkpoints:
  enabled: true                 # Snapshot antes de operações destrutivas

terminal:
  backend: docker               # Ou ssh — mantenha a execução fora do host
  docker_forward_env: []        # Nenhum segredo do host dentro do contêiner

E no ~/.hermes/.env, se você quiser o sandbox de escrita:

HERMES_WRITE_SAFE_ROOT=/caminho/do/projeto:/home/voce/.hermes

Veja também

• Segurança — a referência completa de defesa em profundidade: cada padrão de aprovação, flags de endurecimento de contêiner, autorização no gateway, filtragem de credenciais no MCP
• Checkpoints e rollback — configuração, manutenção do repositório e fluxos de restauração
• Ferramentas e conjuntos de ferramentas — todos os backends de terminal e a configuração de cada um
• Configuração — a referência completa do config.yaml

---