Um repositório recém-clonado ainda não ganhou sua confiança. Então, um agente também não deveria tratar aquele setup como confiável só porque o README parece bem escrito.
Como Funciona
O setup de um repositório começa com comandos de instalação, testes, scripts de bootstrap e outros. Para um agente atento, esses comandos podem virar uma sequência rápida de ações. O agente pode rodar qualquer comando que seja permitido, sem uma revisão cuidadosa.
Riscos
O risco não vem de um arquivo chamado malware.sh. Ele pode aparecer em lugares que parecem normais dentro de um projeto, como scripts de install, postinstall, prepare e bootstrap; comandos copiados do README sem inspeção; ferramentas que baixam ou executam binários; arquivos de configuração que disparam automação; comandos de diagnóstico que acessam rede, shell ou variáveis de ambiente; e testes que assumem serviços locais, chaves ou arquivos fora do repo.
Solução
Para mitigar esses riscos, uma política curta de permissão pode ser implementada. Por exemplo, comandos de leitura estão liberados, comandos de teste conhecidos podem rodar, instalação de dependências em repo novo precisa de revisão, scripts de setup precisam ser lidos antes, e qualquer comando com rede, shell amplo ou efeito destrutivo pede aprovação. Tokens e variáveis sensíveis não entram no ambiente por padrão.
Implementação
Um hábito simples é pedir um plano antes do agente executar setup em um repo novo. Além disso, se o repositório é desconhecido, evitaria rodar o primeiro setup no mesmo ambiente onde ficam seus tokens, chaves SSH, sessão de cloud, arquivos pessoais e configs do trabalho. Isso pode ser feito usando um container, uma VM, uma máquina descartável, ou um workspace com variáveis mínimas.
Conclusão
Gerenciar a segurança de setup de repositórios com agentes requer cautela e uma política de permissão curta. Ao implementar essas práticas, você pode evitar riscos e garantir que os agentes sigam os trilhos apropriados.