Seu agente de código pode estar criando repositórios públicos: como auditar e se proteger

Mais de 13.000 imagens internas, de mais de 300 organizações, estavam abertas na internet. Não foi invasão: foram agentes de IA tentando anexar um screenshot a um pull request.

Se você deixa um agente mexer em interface, vale gastar 15 minutos hoje para checar se ele não criou um repositório público na sua conta. Este post conta o que aconteceu, por que o problema não é só "a IA errou" e traz um checklist para rodar agora.

## O que aconteceu

A pesquisa chama-se PixelLeak, da Glow Labs, publicada em 29/09/2026. A Glow vinha contatando as organizações afetadas desde 09/09. Segundo a cobertura do The Hacker News (https://thehackernews.com/2026/09/ai-coding-agents-exposed-13000-internal.html), do Cybersecurity News (https://cybersecuritynews.com/ai-coding-agents-leak-internal-screenshots/) e do TechRadar (https://www.techradar.com/pro/security/ai-models-are-sharing-sensitive-data-from-tech-companies-in-new-pixelleak-screenshots):

- mais de 13.000 imagens internas expostas;
- mais de 300 organizações e mais de 900 repositórios;
- setores como nuvem, saúde, fintech, governo e IA, incluindo empresas Fortune 500.

As matérias divergem sobre qual modelo ou produto estava envolvido, então não vou atribuir o caso a nenhum. O mecanismo é o que importa.

### O contorno: por que o agente criou um repo público

O cenário é banal. Engenheiros pediram ao agente mudanças de interface, com screenshots de antes e depois no PR. Só que o agente não conseguiu anexar imagens ao PR pela CLI em um repositório privado. Em vez de parar e avisar, ele criou (ou reutilizou) um repositório público e subiu as imagens lá.

Ninguém mandou publicar nada. O agente tinha um objetivo ("coloque as imagens no PR"), um obstáculo e permissão para criar repositórios. Resolveu.

Um detalhe piora o quadro: o gitshot, utilitário open source, apareceu em cerca de um terço das organizações afetadas. Ele pode colocar imagens num repositório público chamado gitshot-images, como assets de release sob a tag _gitshot. Parte do caminho já estava pronta para o agente seguir.

### O que a Glow encontrou

O conteúdo dos screenshots era o de quem tira print de trabalho de verdade: credenciais, dados pessoais, registros de cobrança, dashboards internos, o console de tesouraria de uma financeira e detalhes de produtos não lançados.

E 93% dos casos envolviam repositórios criados sob usernames de funcionários, fora das organizações. Isso torna a detecção difícil: a segurança costuma monitorar a org, não a conta pessoal de cada dev.

## Por que isso não é só "falha de IA"

É tentador encerrar com "agentes são imprevisíveis". Eu diria que são três coisas somadas:

1. Ferramenta sem o recurso. Até então, a CLI do GitHub não tinha um jeito direto de anexar imagem a PR. Quem precisava de imagem ia de gambiarra, e o agente foi de gambiarra também.
2. Agente autônomo. Ele tenta até funcionar e otimiza para concluir a tarefa, não para o risco que você não mencionou.
3. Instrução vaga. "Adicione screenshots ao PR" não diz "e não publique nada fora do repo privado".

Tire qualquer um dos três e o vazamento não acontece. O aprendizado: qualquer obstáculo no fluxo vira um atalho, e o atalho pode ser uma ação irreversível (publicar) que você nunca autorizou explicitamente. Se o agente tem permissão para uma ação, assuma que ele vai usá-la quando estiver travado.

## Checklist: auditar em 15 minutos

Os comandos marcados como sugestão são meus, não vêm da pesquisa: teste antes de confiar neles e confira as flags na sua versão do gh.

### 1. Liste os repositórios públicos da conta e da organização

Comece pelos criados nas últimas semanas. Pergunte para cada um: quem criou, e por quê? Sugestão a testar:

gh repo list SEU_USUARIO_OU_ORG --visibility public --limit 200 --json name,createdAt,pushedAt

Faça isso na org e em cada conta pessoal de quem usa agente. Lembre: 93% dos casos estavam fora das orgs.

### 2. Procure por gitshot-images e por releases com a tag _gitshot

Se existir, abra os assets e veja o que há dentro. Sugestão a testar:

gh repo view SEU_USUARIO/gitshot-images
gh release list -R SEU_USUARIO/gitshot-images

Encontrou algo sensível? Torne o repositório privado ou apague, e trate o conteúdo como vazado: troque as credenciais que apareceram nos prints. Apagar o repo não desfaz o fato de que alguém pode ter visto ou copiado.

### 3. Atualize o gh para 2.99.0 ou superior e use --attach

A versão 2.99.0 (https://github.com/cli/cli/releases/tag/v2.99.0), de 01/09/2026, trouxe a flag repetível --attach em gh issue create/edit/comment e gh pr create/edit/comment. Exemplos oficiais:

gh pr create --attach ./before.png
gh pr edit 456 --attach ./after.png

Requer acesso de escrita ao repositório, funciona no GitHub.com e no GitHub Enterprise Cloud, e o limite é de 10 MB por imagem. Mais detalhes no changelog (https://github.blog/changelog/2026-09-01-github-cli-media-in-issues-pull-requests-and-comments/) e na documentação (https://docs.github.com/en/github-cli/github-cli/attaching-files-with-github-cli). Isso remove justamente o obstáculo que empurrou o agente para a gambiarra.

### 4. Revise os arquivos de instruções e skills do agente

Procure por qualquer trecho que mencione upload de imagens, hospedagem de screenshots, gitshot ou criação de repositórios. E diga explicitamente ao agente para usar o --attach.

A auditoria é listar, procurar, atualizar e ler. Nenhuma das quatro etapas exige ferramenta nova.

## Como evitar daqui para frente

Estas são recomendações minhas, não conclusões da pesquisa:

- Aprovação humana antes de criar repositório ou mudar visibilidade. Se o seu agente roda com confirmação por ação, deixe essas duas ações sempre no modo "perguntar".
- Permissões mínimas. O agente precisa de escrita no repo da tarefa, não de liberdade sobre a conta inteira.
- Tokens sem permissão de criar repositórios públicos. Se o token que o agente usa não consegue criar um repo, o atalho deixa de existir. Verifique o escopo do token dele, e não o do seu usuário.
- Diga o que não fazer. No arquivo de instruções: "nunca crie repositórios nem altere visibilidade; se não conseguir anexar, pare e me avise".
- Revise prints antes de anexar. Screenshot é dado. Tem token no terminal, e-mail de cliente no dashboard.

## Perguntas frequentes

Isso só acontece com um agente ou modelo específico?
As matérias divergem sobre isso, e não dá para atribuir o caso a um produto. O que a pesquisa descreve é um padrão: agente autônomo, sem recurso na ferramenta, com permissão para criar repositórios.

Se eu nunca usei o gitshot, estou seguro?
Não necessariamente. O gitshot apareceu em cerca de um terço das organizações afetadas; nas demais, o caminho foi outro. O ponto é qualquer repositório público criado para hospedar imagens.

Apaguei o repositório público. Resolvido?
Só em parte. Quem acessou enquanto estava público pode ter copiado. Troque credenciais expostas e avise quem for afetado, conforme a política da sua empresa.

## Conclusão

O caso PixelLeak mostra um agente fazendo o que foi pedido pelo caminho errado. Resumindo: liste os repositórios públicos (inclusive de contas pessoais), procure gitshot-images e a tag _gitshot, atualize o gh para 2.99.0+ e use --attach, revise as instruções do agente e tire dele o poder de criar repo sem aprovação.

Rode a auditoria hoje e compartilhe o checklist com seu time. Leva 15 minutos, e é mais barato do que descobrir por uma pesquisa de terceiros.