O vazamento mais perigoso nem sempre parece um ataque. Às vezes ele nasce de uma automação bem-intencionada, com acesso demais, tentando terminar uma tarefa.
Foi esse o ponto de partida de um playbook publicado por Simon Roses: um agente de código, autorizado a ler arquivos e fazer push, empacotou conteúdo sensível e levou tudo para um repositório público. Segundo o relato, havia dados pessoais e tokens válidos no pacote. Não foi um hacker explorando uma cadeia sofisticada. Foi uma ferramenta fazendo algo que o ambiente permitia.
Para quem usa Copilot, Codex, Claude Code, Cursor, scripts com LLM ou qualquer agente com acesso a repo, essa é a parte que importa: quando o segredo já foi para o público, a prioridade não é “apagar rápido para ficar bonito”. É neutralizar o dano.
O erro clássico é começar pelo git history
A reação instintiva é apagar o arquivo, tornar o repositório privado, reescrever histórico e respirar aliviado. Só que segredo vazado não funciona assim.
Repositórios públicos são varridos por bots o tempo todo. Se uma chave de cloud, GitHub, banco ou API aparece em um commit público, trate como se alguém já tivesse copiado. Mesmo que você apague depois, podem existir forks, clones, caches, eventos públicos e commits ainda alcançáveis por hash.
Por isso a ordem prática muda:
Primeiro: pare o agente e corte a credencial de push
Se o agente ainda está rodando, a primeira ação é interromper a sessão. Depois, revogue a credencial que permitiu o push: token pessoal, chave SSH, app de GitHub, credencial de CI ou qualquer identidade usada por aquela automação.
Isso evita o cenário mais irritante: você começa a limpar, o agente tenta “corrigir” a própria tarefa e publica de novo.
Também vale preservar evidência antes que ela suma. Logs de sessão, transcript do agente, histórico de shell, reflog local e logs de CI ajudam a responder perguntas básicas: que arquivos foram lidos, que comando foi executado, para onde foi o push e em que horário.
Depois: rotacione tudo que virou público
Essa é a parte que não pode esperar a limpeza visual. Se vazou token, senha, chave de API ou credencial de cloud, ela precisa morrer.
Comece pelas chaves com maior blast radius: credenciais de organização, admin, cloud, GitHub com escopo amplo, provedores de IA e produção. Depois venha para as demais. E não basta gerar uma chave nova; é preciso confirmar que a antiga deixou de funcionar.
O ponto é simples: um segredo rotacionado vira lixo para quem copiou. Um segredo “apagado do histórico”, mas ainda válido, continua sendo uma porta aberta.
A limpeza do repo vem depois da contenção
Tornar o repositório privado, remover arquivos e reescrever histórico ainda pode fazer sentido. Só não deve ser vendido como contenção completa.
Se houve fork público, clone antes da remoção ou registro do commit em algum arquivo externo, a cópia pode sobreviver. O que você controla de verdade é a utilidade das credenciais vazadas. Por isso o playbook certo coloca rotação antes de estética.
Na etapa de limpeza, use ferramentas próprias para varrer histórico, como Gitleaks, TruffleHog ou git-filter-repo, e abra solicitação ao GitHub quando houver conteúdo sensível que precise sair de caches, pull requests ou referências antigas. Mas faça isso já sabendo que dado pessoal exposto não tem “rotate”.
A parte que muita equipe esquece: auditoria de uso
Rotacionar para o futuro resolve metade do problema. A outra metade é descobrir se alguém usou a chave entre o vazamento e a rotação.
Para cada segredo encontrado, procure logs do provedor correspondente. Em cloud, isso significa trilhas de auditoria. Em GitHub, eventos de acesso, criação de token, alterações de permissão e ações suspeitas. Em provedores de IA, vale olhar consumo por chave, projeto, modelo e horário.
Esse ponto ficou especialmente importante porque chaves de IA hoje podem gerar custo, acessar arquivos, chamar ferramentas, criar saídas com dados internos e esconder abuso em “uso normal” se ninguém olhar por chave ou projeto.
Agente bom também precisa de limite chato
A lição não é parar de usar agente de código. A lição é parar de tratar agente como estagiário mágico com acesso irrestrito ao armário inteiro.
Antes de liberar uma ferramenta dessas em repositório de trabalho, vale checar:
- se ela consegue ler arquivos de segredo, dumps, logs e dados reais;
- se ela pode fazer push direto para remoto público;
- se existe sandbox ou allowlist de comandos;
- se os logs da sessão ficam guardados tempo suficiente;
- se commits gerados por agente passam por revisão humana;
- se tokens usados pela automação têm escopo mínimo e expiração.
O dev experiente já aprendeu que “funcionou na minha máquina” não basta. Com agente de IA, a versão nova é: “o agente conseguiu fazer” também não basta. Ele precisa conseguir fazer só o que deveria.
Se acontecer, pense como incidente, não como vergonha
O pior momento para inventar processo é quando o token já apareceu no GitHub. Então o resumo operacional fica assim: pare o agente, preserve os logs, liste o que vazou, rotacione as credenciais, audite uso, reduza exposição do repositório e trate dados pessoais como incidente de privacidade quando for o caso.
Apagar o arquivo pode até acalmar o print. Mas o que salva a operação é matar a credencial e entender o que ela fez enquanto estava viva.
