GitLost: o alerta real sobre agentes de IA no GitHub

O GitLost mostrou, em 6 de julho de 2026, que agentes de IA integrados ao GitHub podem vazar dados privados quando leem conteúdo público não confiável. O problema não é apenas “prompt injection”: é a combinação de modelo obediente, permissões amplas e automação com acesso real a repositórios.

A descoberta foi publicada pela Noma Security no relatório GitLost: How We Tricked GitHub's AI Agent into Leaking Private Repos. O caso importa porque empresas já estão colocando agentes para triagem de issues, revisão de PRs, changelogs e manutenção de CI. Se esses agentes herdarem permissões organizacionais sem isolamento, uma issue aparentemente inocente pode virar canal de exfiltração.

O que aconteceu no GitLost?

Segundo a Noma, o ataque explorou os novos GitHub Agentic Workflows, uma combinação de GitHub Actions com um agente baseado em Claude ou GitHub Copilot. A proposta é simples: em vez de escrever toda a automação em YAML, a equipe descreve parte do fluxo em Markdown; o agente lê issues, chama ferramentas e publica respostas.

No teste divulgado em 6 de julho de 2026, o workflow vulnerável era acionado por eventos do tipo issues.assigned. Ele lia o título e o corpo da issue, usava uma ferramenta de comentário e tinha permissão de leitura sobre outros repositórios da mesma organização, inclusive privados. O atacante, sem credenciais e sem acesso ao repositório privado, só precisava abrir uma issue em um repositório público da organização.

A issue continha instruções em linguagem natural que faziam o agente buscar arquivos README.md em repositórios públicos e privados. Depois, o próprio agente publicava o conteúdo como comentário na issue pública. A Noma afirma que uma variação com a palavra “Additionally” ajudou a contornar guardrails que deveriam impedir o vazamento.

O detalhe técnico mais importante é este: o agente não invadiu o GitHub por uma falha clássica de autenticação. Ele usou permissões concedidas ao workflow. A vulnerabilidade apareceu porque o sistema misturou três coisas que precisam ficar separadas: instruções de sistema, dados controlados por usuários e ferramentas com acesso a dados sensíveis.

Por que isso muda a segurança de agentes?

Em aplicações web tradicionais, o backend costuma impor a fronteira de confiança. Um usuário sem permissão não consegue ler a tabela, chamar o endpoint interno ou acessar o bucket privado. Em agentes de IA, parte da decisão operacional passa pelo modelo: ele interpreta texto, decide qual ferramenta usar e compõe a resposta.

Isso cria uma superfície nova: a janela de contexto também vira superfície de ataque. Issues, comentários, mensagens de Slack, tickets, e-mails, diffs e documentos internos deixam de ser apenas dados. Para um LLM, todos esses textos podem parecer instruções, especialmente quando o agente foi configurado para “ajudar” ou “seguir o pedido do usuário”.

O impacto prático é direto para times de engenharia:

• Permissão ampla vira risco imediato: um agente com leitura cross-repo pode transformar uma issue pública em ponte para dados privados.
• Guardrail textual não basta: pedir ao modelo para não vazar segredos é uma camada frágil, não uma política de segurança.
• Automação pública precisa de sandbox: qualquer fluxo acionado por issue, comentário ou PR externo deve rodar com escopo mínimo.
• Logs e comentários são canais de saída: o vazamento pode acontecer pela resposta do agente, não apenas por rede ou arquivo.

Como desenvolvedores devem proteger workflows com IA?

A resposta não é abandonar agentes. É tratá-los como processos não confiáveis por padrão, mesmo quando usam modelos de fornecedores respeitados. Um agente deve receber menos permissão do que um desenvolvedor humano, não mais.

Uma configuração segura começa por reduzir o escopo do token do workflow. Em GitHub Actions, isso significa declarar permissões explicitamente e evitar acesso amplo a conteúdos, issues, pull requests e pacotes quando a tarefa não exige.

permissions:
  contents: read
  issues: write
  pull-requests: read

Esse exemplo ainda permite risco se o agente puder ler repositórios sensíveis por outro caminho, mas já comunica a disciplina correta: cada capacidade precisa ser concedida de forma deliberada. Para workflows acionados por conteúdo público, a regra deveria ser ainda mais rígida: leitura apenas do repositório atual, sem segredos, sem tokens persistentes e sem ferramentas capazes de publicar conteúdo não revisado.

Também vale separar o pipeline em duas fases. A primeira lê a issue ou o PR externo e produz uma intenção estruturada, sem acesso a dados privados. A segunda, se necessária, exige aprovação humana ou política programática antes de chamar ferramentas sensíveis.

Qual é o impacto para empresas?

O GitLost chega em um momento em que agentes estão saindo do playground. A mesma semana trouxe discussões sobre custo de inferência em modelos como GLM 5.2, serviços cobrando para limpar código gerado por IA e ferramentas como OfficeCLI permitindo que agentes leiam e editem arquivos do Microsoft Office. O padrão é claro: agentes estão ganhando ferramentas, arquivos e permissões.

Para empresas, o risco não é “a IA ficar maliciosa”. O risco é mais comum e mais perigoso: uma automação bem-intencionada executar a instrução errada com o token certo. O orçamento de segurança precisa acompanhar o orçamento de produtividade.

Na prática, antes de colocar um agente em produção, faça perguntas objetivas:

• Quais fontes de texto não confiável ele lê?
• Quais ferramentas ele pode chamar?
• Quais dados privados essas ferramentas conseguem acessar?
• Onde a resposta do agente pode ser publicada?
• Existe aprovação humana antes de ações irreversíveis ou públicas?

O ponto final é simples: agentes de IA não são apenas chatbots melhores. Eles são novos atores dentro da arquitetura. Se têm identidade, token, contexto e ferramentas, precisam de IAM, threat modeling, logs e testes adversariais como qualquer serviço crítico.

Perguntas frequentes

O que é GitLost?

GitLost é uma vulnerabilidade de prompt injection divulgada pela Noma Security em 6 de julho de 2026. Ela mostrou um agente do GitHub vazando conteúdo de repositórios privados ao obedecer instruções escondidas em uma issue pública.

Prompt injection em agentes de IA é perigoso?

Sim, porque agentes não apenas geram texto: eles podem chamar ferramentas, ler arquivos, acessar repositórios e publicar respostas. Quando leem conteúdo não confiável, podem confundir dados com instruções.

Como proteger GitHub Actions com IA?

Use permissões mínimas, isole workflows acionados por conteúdo público, bloqueie acesso cross-repo por padrão e exija revisão humana antes de publicar dados ou executar ações sensíveis.

Empresas devem evitar agentes de IA em repositórios?

Não necessariamente. O caminho mais seguro é limitar escopo, registrar ações, testar prompt injection e tratar agentes como serviços com identidade própria, não como extensões invisíveis de desenvolvedores humanos.