Segurança para agente pessoal com arquivos

O problema

Agente com acesso a arquivo é útil. Também é perigoso.

O risco não é só “ele apagar tudo”. O risco comum é menor e mais chato: sobrescrever arquivo certo com conteúdo errado, mover coisa para lugar ruim, vazar segredo em contexto, editar produção sem perceber, instalar pacote desnecessário, ou deixar uma mudança sem rastro.

Segurança aqui não é paranoia. É design de rotina.

Três zonas de acesso

Divida o mundo em três zonas.

Se você não sabe classificar uma ação, trate como amarela. Se envolve cliente, dinheiro, credencial ou produção, trate como vermelha.

Regras mínimas

Escreva algo assim para o agente:

1. Pode ler arquivos do projeto atual.
2. Pode criar rascunhos novos em pasta combinada.
3. Pode propor mudanças antes de aplicar.
4. Mostre o diff antes de editar arquivo existente quando a mudança for relevante.
5. Deve pedir confirmação antes de apagar, mover, sobrescrever ou instalar.
6. Não pode mexer em .env, tokens, chaves, credenciais ou segredo sem instrução explícita.
7. Não pode publicar, enviar mensagem externa ou executar deploy sem confirmação.
8. Não pode rodar comando destrutivo sem repetir o alvo e o motivo.
9. Deve registrar o que mudou e como verificar.
10. Deve parar quando encontrar contexto contraditório.

Isso serve para Hermes, Claude Code, Codex ou qualquer agente com ferramenta. A sintaxe muda. A responsabilidade não.

Segredos não entram no prompt

Token colado em chat é vazamento com UX boa.

Segredo deve ficar em arquivo de ambiente, secret manager, variável local ou configuração apropriada. O agente pode saber que existe uma credencial. Ele não precisa ver a credencial inteira para toda tarefa.

Evite:

• mandar .env inteiro no prompt;
• pedir para o agente “guardar” token em memória;
• colar chave de API em issue, PR ou documento;
• dar acesso global quando uma variável específica bastava;
• usar o mesmo token para teste e produção.

No Hermes em VPS, veja o guia de setup e a skill de setup para tratar configuração como arquivo, não como conversa solta.

Confirmação boa não é “posso?”

Confirmação fraca:

Posso fazer isso?

Confirmação boa:

Vou editar src/pages/agentes/index.astro, trocar a chamada principal e rodar pnpm run build. Não vou mexer em deploy nem apagar arquivos. Confirmar?

A confirmação deve dizer:

• arquivos afetados;
• ação exata;
• risco;
• verificação;
• o que não será feito.

Se o agente não consegue explicar isso, ele ainda não entendeu a tarefa.

Checklist antes de liberar escrita

• O agente sabe qual pasta é segura?
• Existe backup, git ou histórico?
• Arquivos de segredo estão fora do escopo?
• Ações destrutivas exigem confirmação?
• Produção está bloqueada por padrão?
• O agente mostra diff ou resumo de alteração?
• Existe comando de verificação?
• O canal de acesso é privado?
• Você consegue revogar token ou parar processo?
• O primeiro teste altera algo sem importância?

Quando o agente toca cliente

Para arquivos próprios, pasta de teste, confirmação manual e tarefa reversível, o caminho faça você mesmo é suficiente. Não precisa chamar empresa para aprender a negar acesso e pedir confirmação.

Se o agente lê conversa de cliente, ticket, CRM, documento comercial ou histórico de atendimento, a barra sobe.

Não basta “meu assistente pessoal”. Você precisa de:

• base legal e permissão de acesso;
• regra de retenção;
• trilha de auditoria;
• supervisão humana;
• handoff;
• QA;
• limite de resposta;
• dono do erro.

Para arquivos próprios, organização local, leitura, diff e escrita confirmada em projeto pessoal, o caminho faça você mesmo é suficiente.

Quando entra cliente, produção, QA, handoff e dono do erro, o problema vira governança e evidência, não produtividade pessoal.

Links úteis dentro do site

• /agentes/ para os guias humanos.
• /skills/ para procedimentos copiáveis.
• /templates/ para checklists de decisão.
• Agente pessoal em VPS com Hermes para setup inicial.

Se você prefere ver em vídeo