O Que o Agente da Wiz Realmente Invadiu

A Wiz construiu um agente de IA autónomo chamado Red Agent para procurar falhas exploráveis como faria um testador de intrusão humano, e depois agir com base no que encontra. Direcionado aos repositórios públicos do GitHub da Snowflake, encontrou uma falha de injeção de script num ficheiro de workflow do GitHub Actions chamado jira_issue.yml dentro de snowflakedb/snowflake-connector-net, o conector .NET de código aberto da Snowflake. A falha permitia a qualquer pessoa abrir uma issue do GitHub com um título especialmente preparado e fazer com que a própria automação da Snowflake executasse parte desse título como comando de shell, sem necessidade de sessão iniciada.

A primeira tentativa do Red Agent falhou. O runner devolveu um erro de sintaxe em vez de executar a carga útil. Em vez de parar aí, o agente leu o erro, reescreveu sozinho o título manipulado da issue e tentou novamente. A segunda tentativa saiu da cadeia de shell e alcançou um domínio controlado pelo atacante, exfiltrando no processo um token de API do Jira codificado em base64. Deteção, ajuste, exploração e verificação do acesso obtido ocorreram tudo numa única sessão, sem que nenhum humano decidisse o passo seguinte.

O token roubado era válido e estava autenticado como uma conta de serviço da Snowflake, concedendo acesso de leitura a uma instância interna do Jira que abrangia projetos de engenharia, conformidade de segurança e acompanhamento de recompensas por bugs. O código vulnerável estava ativo desde a fusão do PR #1218 a 18 de junho de 2026, que substituiu um padrão de análise seguro por interpolação direta de variáveis num comando de shell. A Snowflake corrigiu-o a 23 de junho de 2026, restaurando o padrão seguro, e revogou e renovou o token exposto; uma auditoria dos registos não encontrou provas de que alguma parte externa o tivesse usado durante a janela de exposição de cinco dias.

A Wiz Nomeou o Copilot Coautor do Bug

O relatório original da Wiz apontou o commit que introduziu a falha e notou que o GitHub Copilot Autofix aparecia nele como coautor. A narrativa escreveu-se sozinha: um assistente de programação com IA parecia ter ajudado a escrever exatamente o bug que um agente de segurança com IA depois encontrou e explorou de forma autónoma, em ambos os extremos.

A linha de coautoria era real, e as fusões squash fazem esse tipo de prova parecer mais sólida do que é. Um pull request pode conter muitos commits individuais de muitos colaboradores, mas uma fusão squash reúne-os todos num único commit no ramo principal, e cada linha de coautoria de cada um desses commits viaja com ele até ao resultado combinado. Um nome nessa linha regista participação nalgum ponto do pull request, não autoria de uma linha específica. Quando a Wiz atualizou a sua publicação a 17 de agosto de 2026, a sua própria linguagem já se tinha suavizado até admitir que não estava claro se o Copilot tinha sequer contribuído para as linhas vulneráveis.

O Histórico de Commits do GitHub Diz Que Foi Um Humano a Escrevê-lo

O GitHub conduziu a sua própria revisão interna do mesmo repositório e chegou a uma conclusão diferente. Segundo o GitHub, um engenheiro humano da Snowflake escreveu a reformulação insegura, num commit separado datado de 25 de agosto de 2025, cerca de dez meses antes de o pull request vulnerável ser fundido, e o Copilot Autofix não reviu nem contribuiu para essas linhas específicas.

O commit real de coautoria do Copilot dentro do pull request #1218 alterou um ficheiro diferente, jira_close.yml, sem relação com as linhas vulneráveis de jira_issue.yml que o Red Agent explorou. Quando o pull request foi comprimido num único commit de fusão, a linha de coautoria do Copilot viajou na mesma assim, associada a uma alteração que nunca tinha tocado.

O litígio está agora público, com dois relatos incompatíveis e nenhum árbitro independente. A Wiz aponta para uma linha de coautoria no histórico de commits ativo; o GitHub aponta para uma revisão interna do mesmo repositório que interpreta a autoria de forma diferente. Ninguém fora das duas empresas tem o acesso necessário para determinar qual das leituras está correta.

A Lacuna de Governação Que Toda Equipa Apoiada em IA Deve Notar

Executar um assistente de programação com IA e um scanner de segurança com IA no mesmo pipeline está rapidamente a tornar-se a configuração predefinida, não a exceção. Quando algo corre mal nessa configuração, tanto a parte que encontra o bug como a ferramenta acusada de o ter escrito podem ser ambas sistemas de IA, e a única prova a que qualquer das partes pode recorrer é o histórico de commits de um repositório. Esse histórico é apenas tão fiável quanto as práticas que o produziram, e uma fusão squash de rotina acabou de provar que pode associar o nome de um colaborador ao erro de outro sem que ninguém o tenha pretendido.

O bug em si esteve exposto durante cinco dias e precisou de mais cinco dias para ser corrigido. A discussão sobre quem o escreveu durou mais tempo do que a própria vulnerabilidade, e decorreu entre dois fornecedores com os recursos e o acesso ao repositório para investigar como deve ser. Uma empresa com menos disciplina na preservação do histórico de commits dos seus próprios ficheiros de workflow, e sem uma resposta estabelecida sobre quem, internamente, está autorizado a publicar uma afirmação de atribuição antes de esta se tornar um litígio público, não resolverá a sua versão com a mesma clareza.

Leia a seguir: Uma posição valia mais do que os três fundos  |  Um modelo de fronteira retirado voltou a estar online