🛡️ Segurança e Operação

Tudo que você cola no chat do Hermes vai pro SQLite (sessions). Token colado fica indexado, pesquisável via session_search e copiado em backups. Para sempre.

Token vazado por descuido é o vetor de ataque mais comum. Você passa o aprendizado adiante, alguém com acesso ao SQLite (ou ao backup, ou a um log) puxa a chave.

Use sempre hermes config set KEY value. Se colou por engano, revogue a credencial imediatamente e gere outra. Não tente "limpar" o histórico — assuma vazado.

Comando que escreve a variável diretamente em /root/.hermes/.env (dentro do container) sem passar pelo histórico de chat nem pelos logs.

É o caminho seguro. O CLI lê o valor por stdin, persiste no .env e confirma sem ecoar. Funciona em laptop, VPS e Docker.

Exemplos: hermes config set TELEGRAM_TOKEN xxx, hermes config set OPENROUTER_API_KEY xxx. Quando rodando em Docker, exec no container antes: docker exec -it hermes hermes config set ....

Em Docker, o .env da raiz do projeto no host não chega ao processo. O Hermes lê o .env de /root/.hermes/.env dentro do container (volume montado em ~/.hermes no host).

É a confusão #1 da comunidade. Você edita o .env "errado", reinicia, nada muda, acha que é bug do Hermes — é só caminho equivocado.

Confira com docker exec -it hermes env | grep TELEGRAM. Se a var não aparece, o volume não está montando direito ou o nome está errado. Logs de erro: ~/.hermes/logs/errors.log.

Para apagar uma chave antiga, renomear ou organizar comentários, edite direto: docker exec -it hermes nano /root/.hermes/.env.

O config set só sobrescreve ou adiciona. Não tem subcomando "delete" amigável. Quando a chave deixa de ser usada (você trocou de provedor), apague manualmente pra reduzir superfície de ataque.

Sempre faça backup antes: cp /root/.hermes/.env /root/.hermes/.env.bak. Reinicie o gateway depois: hermes gateway restart.

No GitHub você escolhe entre token clássico (acesso amplo) e fine-grained (escopo por repositório, expiração obrigatória). Na OpenAI você define scopes do project key.

Token vazado é prejuízo proporcional ao escopo. Token clássico full-access expõe todos seus repos. Fine-grained no repo X só expõe X.

Regra: comece com escopo mínimo, expanda quando o agente reclamar de "permission denied". Sempre defina expiração (90 dias é padrão razoável).

Hermes redige automaticamente valores de variáveis de ambiente quando aparecem em mensagens de erro. ~/.hermes/logs/errors.log raramente tem o token "real" exposto.

Você pode pedir suporte, colar pedaços do log, postar no Discord da comunidade — sem vazar credencial. Mas confira sempre antes de compartilhar.

Auto-redação cobre nomes conhecidos (TELEGRAM_TOKEN, *_API_KEY). Valores hardcoded em código ou em mensagem livre podem escapar. Antes de postar log, abra e leia.

Três camadas: 1) firewall do provedor (Hostinger/AWS), 2) ufw no host (Ubuntu), 3) isolamento do container Docker. Cada uma bloqueia algo que a outra deixou passar.

Confiar só em uma é frágil. Se você desligar ufw temporariamente para debugar e esquecer, o firewall do provedor ainda te cobre.

Princípio: nada exposto sem motivo claro. Toda porta aberta tem que ter justificativa documentada.

A Hostinger oferece firewall no próprio painel (e Upguard como serviço de monitoramento). Bloqueia tráfego antes de chegar na VM, reduzindo carga e log noise.

Não precisa esperar o pacote chegar no Ubuntu pra ser descartado. Provedor já filtra. Você economiza CPU, banda e linhas de log.

Mínimo recomendado: bloqueie tudo, abra só 22 (SSH), 80/443 (web) e portas específicas que você usa. Reveja a cada 90 dias.

Uncomplicated Firewall — wrapper amigável de iptables. Em quatro linhas você fecha a VPS para o mundo: ufw default deny, ufw allow 22, ufw allow 443, ufw enable.

É o controle mais granular que você tem do lado da VM. Fecha tráfego que chegou através do firewall do provedor (ex: outro container vizinho).

Sempre ufw allow 22 antes de ufw enable — sob pena de se trancar fora. Verifique com ufw status verbose.

Três ajustes no /etc/ssh/sshd_config: PasswordAuthentication no (chave-only), Port 2222 (não-padrão) e instalar fail2ban (bana IPs que tentam força bruta).

99% dos ataques contra VPS são scan automatizado de SSH na 22 com password fraca. Tirar 22 da equação descarta a maioria. fail2ban resolve o resto.

Antes de desabilitar password, garanta que sua chave funciona. Antes de mudar porta, abra ela no ufw e firewall do provedor. Teste numa segunda sessão antes de fechar a primeira.

Restringir SSH apenas a IPs conhecidos. Hostinger permite via console, AWS via Security Groups, ufw via ufw allow from 1.2.3.4 to any port 22.

Se você só acessa de dois lugares (casa + escritório), não tem motivo pro mundo inteiro tentar SSH. Reduz superfície de ataque a quase zero.

Cuidado com IP dinâmico — se sua casa muda IP toda madrugada, você vai se trancar fora. Solução: IP fixo via VPN ou Tailscale, e libera só o IP da VPN.

Você pede em linguagem natural: "Faça auditoria do firewall e proponha hardening." O Hermes roda ufw status, ss -tlnp, lista portas ativas, compara com o que faz sentido e sugere mudanças.

Você não precisa virar SRE. Ele lista, explica e sugere. Você revisa e aprova. Mantém a operação dentro do seu escopo de tempo disponível.

Permissão para rodar comandos no terminal precisa estar configurada. Sempre revise antes de executar mudanças críticas (especialmente em SSH e firewall).

Mentalidade de onboarding aplicada a software: dia 1 com escopo mínimo, expansão gradual conforme prova confiabilidade. Igual estagiário humano — só com latência menor.

Reduz blast radius. Erro do agente nas duas primeiras semanas é prejuízo limitado. Erro com permissão total no primeiro dia pode quebrar produção.

Dia 1: ler arquivos, mandar Telegram. Semana 2: commitar em repos específicos. Mês 1: deploy em staging. Mês 3: produção com revisão.

Crie email novo só pro agente. AgentMail é serviço criado pra isso; Gmail dedicado também serve. Nunca use sua conta principal.

Se a conta do agente for comprometida, o blast radius é só ela. Sua identidade pessoal, recovery de bancos, 2FA de tudo — fica intacto.

Use também para login em serviços de terceiros (OpenRouter, GitHub do agente). Centraliza credenciais "do agente" longe das suas.

No OpenRouter (e na maioria dos provedores), você cria chaves com nome. hermes-pessoal, hermes-marketing, hermes-financeiro — uma por agente.

Quando algo dá errado, você sabe qual agente queimou tokens. Pode revogar uma chave sem afetar os outros. Auditoria de gasto fica granular.

Nunca compartilhe a mesma chave entre Hermes diferentes. Mesmo que dê preguiça, é o tipo de atalho que se paga caro depois.

Use cartão virtual (Nubank, Revolut, Privacy.com) com limite pequeno só pras assinaturas do agente. Configure alerta de gasto e hard cap mensal no provedor.

Loop infinito de uma skill mal escrita pode queimar centenas de dólares numa noite. Hard cap impede. Alerta avisa antes do estrago.

No OpenRouter: defina monthly limit por chave. Na OpenAI: usage limits por project. No cartão virtual: limite hard de R$ 200/mês para agente experimental.

Quando o Hermes pede para rodar comando ou usar tool sensível, ele oferece três níveis: aprovar uma vez, aprovar a sessão inteira, ou aprovar pra sempre.

Cada escolha tem trade-off. once é seguro mas chato (toda hora pergunta). always é cômodo mas vira backdoor permanente. session é o meio termo.

Regra: comandos destrutivos (rm -rf, git push --force) → once. Comandos de leitura (ls, cat) → always. Resto → session.

Cada Hermes (pessoal, marketing, financeiro) deve ter seu próprio bloco de credenciais isolado. Containers separados, .env separados, chaves separadas, perfis separados.

Compromisso de um agente não cascateia. Auditoria de cada um é limpa. Você pode aposentar um agente sem mexer nos outros.

Padrão de docker-compose: um service por agente, com volume ~/.hermes-pessoal, ~/.hermes-marketing, etc. Documente quem tem acesso a quê em SECURITY.md.

Auditoria manual é boa nas duas primeiras semanas. Depois, vira "vou fazer no fim de semana" e nunca mais. Cron resolve: máquina não esquece, não cansa, não posterga.

Segurança é problema de hábito. Se depende da sua disciplina, falha. Se depende da máquina, funciona. Você só revisa o relatório.

Frequência ideal: pesado uma vez por semana, leve a cada 5 minutos. Intervalo curto demais vira ruído ignorado. Longo demais perde o evento.

Skill em ~/.hermes/skills/auditoria-vps/SKILL.md que checa: portas abertas (ss -tlnp), processos suspeitos (top consumidores), disco (df -h), logs estranhos (auth.log, syslog).

Procedimento claro = execução previsível. Você revisa um relatório consistente, não tenta lembrar do nada o que checar.

SKILL.md tem YAML front matter (name, description, tags). Procedure lista os checks. Verification confirma que rodou. Pitfalls anota falsos-positivos comuns.

Comando: /cron add "every Sunday at 09:00" "Rode auditoria-vps e me mande o relatório no Telegram" --skill auditoria-vps.

Domingo 9h é o slot ideal: você acorda no fim de semana com café, lê o relatório, age se for o caso. Sem pressão da semana de trabalho.

Use --skill para injetar a skill na sessão fresh. --workdir se houver contexto específico de pasta. --deliver telegram garante a entrega.

Modo --no-agent roda script sem chamar LLM. Custo zero. Um script Bash checa RAM e disco, sai silencioso se OK, retorna erro se passar do threshold.

Watchdog barato. Você descobre antes do site cair. Sem alerta = tudo bem. Alerta = ação imediata. Sinal-ruído altíssimo.

Comando: hermes cron create "every 5m" --no-agent --script memory-watchdog.sh --deliver telegram --name "memory-watchdog". Script .sh roda em /bin/bash.

A cada 90 dias, gerar novas chaves (GitHub, OpenRouter, Telegram bot se necessário) e revogar as antigas. Cron lembra; você executa.

Token vazado meses atrás e não trocado é vulnerabilidade silenciosa. Rotação periódica garante que mesmo um leak não-detectado tem janela limitada.

Cron: /cron add "every 90 days" "Rote os tokens GitHub, OpenRouter e Telegram. Avise quais foram trocados.". Documente cada rotação na MEMORY.md.

Quando algo deu errado (token vazou, cron consumiu loop infinito, comando destrutivo aprovou sem revisar), peça ao agente: "Salva isso na MEMORY.md como lição".

É a forma mais barata de fazer pós-mortem. Próxima sessão começa lembrando. Reduz reincidência. Vira aprendizado persistente.

Padrão de entrada: data + sintoma + causa-raiz + ação de correção. Limite ~800 tokens — entradas antigas saem quando memória enche, mas o padrão persiste.