👷 Trate como funcionário novo
A mentalidade que destrava tudo: Hermes não é "robô infalível", é funcionário recém-contratado com latência baixa e zero malícia, mas também zero contexto. Você não dá acesso total a um estagiário no dia 1. Mesma lógica.
📈 Confiança gradual (exemplo de timeline)
🎯Por que funciona
Erro do agente nas primeiras semanas é prejuízo limitado. Erro com permissão total no primeiro dia pode quebrar produção, corromper banco, vazar dados. Confiança expandida gradualmente é confiança ganha.
📧 Contas separadas
Crie identidade nova para o agente. Nunca use sua conta principal (Gmail pessoal, GitHub principal). Se o agente for comprometido, você quer blast radius mínimo.
📬 Email dedicado
- •AgentMail — serviço criado especificamente pra agentes
- •Gmail dedicado — ex:
seunome.hermes@gmail.com - •ProtonMail — se quiser maior privacidade
🐙 GitHub do agente
- •Conta GitHub separada com email do agente
- •Adicionado como collaborator nos repos específicos
- •Nunca dono dos repos importantes
⚠️Por que separar
Se a conta do agente for comprometida, sua identidade pessoal, recovery de bancos, 2FA de tudo — fica intacto. O atacante pega só o que o agente tinha acesso. Você revoga, troca chaves e segue.
🏷️ Chaves nomeadas por agente
OpenRouter, OpenAI, Anthropic, GitHub — todos permitem nomear chaves. Use isso. Uma chave por agente, com nome descritivo. Quando algo dá errado, você sabe quem queimou tokens, quem foi comprometido, qual revogar.
🏷️ Padrão de nomenclatura
hermes-pessoal— agente do dia a dia, baixo riscohermes-marketing— automação de redes sociais, conteúdohermes-financeiro— relatórios, alertas, contas separadashermes-cliente-acme— agente exclusivo de um clientehermes-experimental— testes, skills novas, limite baixo
📊Benefícios do isolamento
- •Auditoria de gasto granular — você vê exatamente qual agente queimou X dólares
- •Revogação cirúrgica — apaga uma chave sem afetar os outros
- •Limites independentes — agente experimental tem cap de $10/mês, pessoal tem $50
- •Logs separados — analytics do provedor mostra padrão de cada agente
⚠️Não compartilhe
"Vou usar a mesma chave nos dois agentes pra economizar tempo" → não. É exatamente o atalho que se paga caro depois. Um vazamento contamina os outros, auditoria fica embaralhada, revogação derruba tudo.
💳 Cartão de crédito limitado
Loop infinito de uma skill mal escrita pode queimar centenas de dólares numa noite. Hard cap impede o estrago. Alerta avisa antes. Sempre use cartão virtual com limite baixo para serviços pay-per-token.
💳 Cartão virtual
- •Nubank Ultravioleta — virtual com limite custom
- •Revolut — disposable cards
- •Privacy.com (US) — cards descartáveis com cap mensal
- •BTG Mais — virtual com limite ajustável
🚦 Hard cap nos provedores
- •OpenRouter: monthly limit por chave
- •OpenAI: usage limits por project
- •Anthropic: spending threshold por workspace
- •Hostinger: auto-shutdown da VPS quando estora budget
📊 Estratégia em 3 níveis
- 1.Alerta em 50% do budget — você é avisado
- 2.Soft limit em 80% — agente é avisado, ainda funciona
- 3.Hard cap em 100% — chave para de aceitar requests
⚠️História real
Skill mal escrita entrou em loop chamando GPT-4 a cada 100ms. Sem hard cap, queimou $800 em 4 horas durante a madrugada. Com hard cap em $50, teria parado em 15 minutos com perda de $50. Use hard cap.
✋ Permissões granulares: once / session / always
Quando o Hermes pede para rodar comando ou usar tool sensível, ele oferece três níveis de aprovação. Cada um tem trade-off entre segurança e fricção. Saber qual usar quando é metade da disciplina operacional.
🔒 Once (uma vez)
Aprova só essa execução específica. Próxima vez pergunta de novo.
Use quando: comandos destrutivos (rm -rf, git push --force), mudanças em produção, ações irreversíveis.
⏱️ Session (sessão atual)
Aprova até a sessão acabar. Quando você reinicia, pergunta de novo.
Use quando: trabalho focado em uma tarefa, comandos da mesma família repetidos, instalações de pacote durante setup.
♾️ Always (sempre)
Aprova permanentemente. Vira backdoor sem mais perguntas. Cuidado.
Use quando: comandos de leitura puros (ls, cat, git status), tools que você confia 100% (envio de Telegram pra você mesmo).
🎯 Regra prática
- Leitura (cat, ls, git status, curl GET) → always
- Escrita controlada (git commit, criar arquivo) → session
- Destrutivo (rm, push --force, drop table) → once
- Externo com custo (criar VM, comprar API credits) → once
🔀 Multi-agente = múltiplas chaves
Cada Hermes (pessoal, marketing, financeiro) deve ser silo. Container separado, volume separado, .env separado, chaves separadas, perfil de Telegram/Discord separado. Compromisso de um não cascateia.
📁Layout em disco
/home/user/
├── hermes-pessoal/
│ ├── docker-compose.yml
│ └── data/.hermes/ → /root/.hermes do container
├── hermes-marketing/
│ ├── docker-compose.yml
│ └── data/.hermes/
└── hermes-financeiro/
├── docker-compose.yml
└── data/.hermes/🧪 docker-compose por agente
services:
hermes-pessoal:
image: nousresearch/hermes-agent:latest
container_name: hermes-pessoal
volumes:
- ./data/.hermes:/root/.hermes
restart: unless-stopped📋 Checklist de isolamento
- ✓Containers diferentes (
container_namedistintos) - ✓Volumes diferentes (cada um aponta pra seu
~/.hermes-X) - ✓Chaves de API diferentes (uma por agente)
- ✓Bots de Telegram diferentes (um por agente)
- ✓Email/GitHub diferentes (quando faz sentido)
- ✓Documentar tudo em
SECURITY.mdno repo central
💡Documente
Crie um SECURITY.md no repo central com: nome do agente, propósito, chaves usadas, escopo de cada chave, dono humano responsável, data da última rotação. Em 6 meses você não lembra.
🎯Resumo do módulo
Próximo módulo:
4.4 - 📋 Auditoria recorrente + skill semanal