Uma falha de desenho nos agentes de IA do GitHub permite que uma issue pública conduza a automação a ler arquivos privados e publicar o conteúdo em um comentário aberto. O ataque não exige credenciais roubadas: basta explorar a combinação entre entrada pública, acesso amplo e saída pública, segundo pesquisadores da Noma Security.
Resumo e pontos-chave
- O ataque foi chamado de GitLost e mira os fluxos de trabalho autônomos do GitHub.
- Uma issue aparentemente normal pode carregar instruções ocultas para o agente.
- O risco cresce quando o agente recebe leitura em vários repositórios privados.
- O vazamento pode aparecer em comentários, issues ou outros objetos visíveis.
- A defesa começa por reduzir permissões, separar dados públicos e exigir revisão humana.
O que aconteceu
O GitHub Agentic Workflows transforma instruções escritas em linguagem natural, dentro de arquivos Markdown, em automações executadas pelo GitHub Actions. O agente pode ler issues e solicitações de alteração, usar ferramentas e responder sozinho. A plataforma está em prévia pública e pode trabalhar com Copilot, Claude, Gemini ou Codex, conforme a configuração escolhida pelo responsável pelo repositório. O GitHub descreve o recurso em seu blog oficial.
Pesquisadores da Noma Security demonstraram que uma issue pública pode induzir o agente a buscar dados fora do repositório aberto e colocar o resultado em um comentário público. O atacante não precisa entrar na organização nem obter uma senha. Ele precisa apenas publicar conteúdo que o agente consiga ler e que seja processado pelo fluxo automático. A demonstração foi reportada pelo The Hacker News.
O nome GitLost resume o problema: o GitHub continua funcionando, o agente executa a tarefa autorizada e o vazamento acontece por uma interpretação maliciosa do contexto. Não é necessário quebrar a autenticação. O abuso está na distância entre o que o administrador pretendia autorizar e o que o modelo entende que deve fazer.
Como o vazamento funciona
O primeiro elemento é a injeção indireta de instruções. Em vez de atacar a mensagem de configuração do agente, o criminoso escreve comandos dentro de uma issue, de uma solicitação de alteração ou de outro texto que a automação foi programada para ler. O agente recebe esse conteúdo junto com a tarefa legítima e pode tratá-lo como uma ordem confiável.
O segundo elemento é a permissão excessiva. Os fluxos de trabalho começam com acesso somente de leitura, mas uma organização pode conceder um token capaz de consultar vários repositórios, inclusive os privados. Essa ampliação é útil para gerar contexto entre projetos, porém também aumenta o alcance de uma instrução maliciosa. O relatório sobre o GitLost detalha essa combinação de acesso.
O terceiro elemento é a saída exposta. Se o agente pode escrever um comentário em uma issue pública, o próprio GitHub vira o canal de exfiltração. A resposta pode parecer uma atualização comum, mas conter trechos de um arquivo privado, configuração interna ou documentação que não deveria sair da organização.
| Componente | Função legítima | Risco explorado | Fonte |
|---|---|---|---|
| Issue pública | Fornecer contexto para a automação | Carregar instruções indiretas | The Hacker News |
| Token de leitura | Consultar outros projetos | Alcançar repositórios privados | The Hacker News |
| Comentário público | Entregar o resultado ao solicitante | Publicar dados internos | GitHub |
Por que isso importa
O caso muda a forma de pensar sobre automação de código. Um robô tradicional repete comandos previsíveis. Um agente de IA interpreta texto, escolhe ferramentas e decide quais informações usar para concluir uma tarefa. Quando a entrada vem de uma pessoa externa, o repositório deixa de ser apenas um conjunto de arquivos: ele também vira uma superfície de comando.
O risco não depende de o agente ter permissão para alterar código. A leitura já pode ser suficiente para expor segredos armazenados em arquivos, detalhes de arquitetura, chaves esquecidas ou propriedade intelectual. A publicação do resultado em um comentário transforma uma permissão de consulta em um caminho de saída controlado pelo atacante.
Pesquisas da Wiz sobre ações de GitHub com recursos de IA encontraram problemas semelhantes de fronteira de confiança, além de vetores para exfiltração de credenciais criadas durante o fluxo. A empresa recomenda não confiar no modelo para impedir sozinho a injeção de instruções e evitar combinar automações de IA com acesso amplo e arquivos sensíveis. A análise técnica da Wiz explica esses riscos.
O que o GitHub promete
O GitHub afirma que os fluxos de trabalho usam uma arquitetura de defesa em profundidade. A execução ocorre em uma máquina virtual com contêineres, isolamento de rede e ferramentas permitidas por lista. O acesso de escrita fica desativado por padrão e operações como abrir uma solicitação de alteração ou comentar dependem de saídas seguras e aprováveis. A arquitetura de segurança foi apresentada pelo próprio GitHub.
Essas barreiras reduzem o impacto, mas não eliminam o erro de configuração. O próprio modelo de ameaça do GitHub considera que agentes não devem ser confiáveis por padrão quando recebem entradas não confiáveis. A proteção só funciona se a organização preservar as separações de permissão, rede, dados e aprovação previstas no desenho.
Essa é a parte que merece desconfiança. “Somente leitura” não significa “sem risco”. Uma conta com leitura em dezenas de projetos e autorização para responder publicamente ainda pode ser um mecanismo eficiente de vazamento. O controle precisa avaliar o caminho completo: quem fornece o texto, o que o agente pode consultar e para onde a resposta pode ir.
Como reduzir o risco
- Revise os gatilhos. Liste fluxos acionados por issues, comentários ou solicitações de alteração públicas. Desative automações que não precisam processar conteúdo de desconhecidos. A Wiz recomenda tratar esses eventos como entrada não confiável.
- Encolha o token. Conceda leitura apenas no repositório e nos diretórios indispensáveis. Não use uma credencial ampla para dar contexto entre projetos quando uma cópia controlada de dados resolveria a tarefa.
- Separe leitura e publicação. O agente pode preparar um rascunho, mas a publicação em área pública deve exigir aprovação de uma pessoa. Não permita que o mesmo fluxo consulte dados privados e publique sem revisão.
- Retire segredos do ambiente. Não coloque chaves, arquivos de configuração ou credenciais no mesmo ambiente de execução de um agente que processa texto externo. A arquitetura do GitHub alerta que agentes comprometidos podem tentar ler arquivos e registros do fluxo. Veja as recomendações de isolamento do GitHub.
- Monitore saídas anormais. Procure comentários com blocos extensos, nomes de arquivos privados, codificações, chamadas de rede incomuns e respostas que não correspondem à tarefa. Preserve registros para reconstruir o que o agente leu e fez.
- Teste com segurança. Crie um repositório de laboratório com dados falsos e tente inserir instruções adversariais. O objetivo é descobrir se o agente atravessa a fronteira entre conteúdo público, arquivos privados e saída pública antes de colocar a automação em produção.
O que equipes brasileiras devem fazer
Empresas que mantêm código no GitHub devem tratar agentes autônomos como identidades privilegiadas, não como simples extensões do editor. O inventário precisa registrar qual fluxo usa IA, qual modelo o executa, quais eventos o acionam, quais repositórios ele consulta e onde publica resultados.
Para equipes pequenas, a medida mais eficaz é simples: não ativar uma automação que lê issues públicas e possui acesso transversal a repositórios privados. Para organizações maiores, a prioridade é criar políticas de menor privilégio, aprovação humana para escrita e alertas sobre leitura e publicação fora do padrão. A regra vale tanto para código próprio quanto para projetos de clientes.
Também convém revisar integrações de terceiros. A Wiz identificou que ações de IA podem aplicar verificações insuficientes para distinguir aplicativos internos de atores externos. Configurações que liberam qualquer conta automatizada ou dispensam a validação do autor ampliam a superfície de ataque. A pesquisa da Wiz lista esses padrões de configuração perigosa.
Leia também
- IA de código vira arma e abre um shell no computador
- Falhas de CI/CD expõem milhões de repositórios
- Firewall que isola agentes de IA da rede