GitLost: Nós Enganamos o Agente de IA do GitHub para Vazando Repositórios Privados

Natureza da vulnerabilidade

• Os GitHub Agentic Workflows foram configurados para:
  • Ler títulos/corpos de issues públicas.
  • Responder via comentários públicos.
  • Ter acesso de leitura a outros repositórios da organização, incluindo privados.
• Atacantes podiam injetar instruções em issues públicas que faziam o agente ler repositórios privados e colar o conteúdo de volta como comentários públicos.
• Vários comentaristas enfatizam que a falha principal é a ausência de uma fronteira de confiança entre o conteúdo não confiável das issues e o acesso a repositórios privados.

Quem é o culpado?

• Um grupo: isso é principalmente uma má configuração do usuário.
  • Os pesquisadores concederam explicitamente ao agente acesso aos repositórios de toda a organização e permitiram que ele processasse issues públicas não confiáveis.
  • Analogia: dar segredos a um job de CI e depois executá-lo em pull requests públicas.
• Outro grupo: isso é uma falha de design do GitHub.
  • Usuários razoáveis esperam que um agente em um repositório público não vaze outros repositórios privados não relacionados.
  • As permissões são muito grosseiras e o GitHub não torna uma configuração segura fácil ou óbvia.

Prompt injection & guardrails (in)solucionáveis

• Muitos argumentam que prompt injection é inerente aos LLMs: entrada do usuário é instrução, então não há uma maneira forte de separar “código” de “dados.”
• Comparações com SQL injection:
  • Semelhante no sentido de que entradas não confiáveis mudam o comportamento.
  • Mas, ao contrário do SQL, não há equivalente a prepared statements; as guardrails são apenas mais texto de entrada e podem ser sobrepostas.
• Alguns veem isso mais como engenharia social: você só pode mitigar por meio de processo e controle de acesso, não “consertar” o modelo.

Permissões, arquitetura e mitigação

• A visão amplamente compartilhada: as únicas defesas reais são arquiteturais:
  • Execute agentes com as mesmas permissões, ou mais restritas, do usuário que faz o prompt; nunca com acesso “root”/abrangente da organização.
  • Limite agentes a um único repositório ou a fluxos de trabalho bem definidos; segmente fluxos de trabalho com tokens diferentes.
  • Restrinja escritas de agentes que lidam com entrada pública, mesmo que possam ler dados privados.
  • Execute agentes em sandbox e dê a eles suas próprias credenciais; trate-os como usuários não confiáveis.
• Alguns sugerem UIs melhores para permissões por prompt/por fluxo de trabalho e tokens do GitHub mais granulares.

Confiança no GitHub, na nuvem e nas integrações de IA

• Ceticismo em relação ao GitHub/Microsoft:
  • Percepção de “IA em tudo” impulsionada por pressão de investidores, levando a recursos apressados e inseguros.
  • Preocupações com dados de repositórios privados alimentando o treinamento do Copilot, a menos que haja opt-out.
• Um subgrupo visível defende migrar para forges autohospedados (Forgejo, Codeberg, bare git) para evitar integração com IA e recuperar controle.

Reflexões mais amplas

• Vários comentaristas veem isso como mais um exemplo de cultura de segurança fraca (“negligência criminosa”, lançamento no estilo “YOLO”).
• Temas de consenso:
  • LLMs devem ser tratados como apenas mais uma camada de interface, não como um backend privilegiado.
  • Não se pode confiar em guardrails no nível do modelo; apenas barreiras de segurança rígidas e design com o princípio do menor privilégio reduzem o risco de forma significativa.