O Copilot Aprovou. O Scanner Passou. Um Atacante de IA Explorou em Cinco Dias.
Cinco dias. Foi quanto tempo uma vulnerabilidade crítica de injeção de script viveu em um repositório da Snowflake antes de um atacante autônomo de IA encontrá-la e explorá-la. O pull request que a introduziu, o PR #1218, foi mergeado em 18 de junho de 2026, com o GitHub Copilot listado como coautor e revisor. O Copilot deu o aval. O GitHub Advanced Security escaneou a revisão final e ficou em silêncio. Em 23 de junho, o Red Agent autônomo da Wiz identificou a falha, escreveu um exploit e extraiu credenciais do runner de CI. A Snowflake corrigiu no mesmo dia. A Wiz divulgou o incidente em 17 de agosto.
Um único arquivo de workflow. IA dos dois lados. A IA defensiva aprovou a vulnerabilidade; a IA ofensiva a transformou em arma. Este é o incidente que tira a assimetria de segurança da IA do terreno do argumento de tendência e a coloca no terreno do caso documentado, com data e número.
O Que Aconteceu
A vulnerabilidade vivia no jira_issue.yml, um workflow do GitHub Actions no repositório da Snowflake. O workflow interpolava o título da issue do GitHub dentro de um echo de shell. Título de issue é entrada controlada pelo atacante: qualquer pessoa que consiga abrir uma issue contra o repositório controla aquela string. Uma aspa simples no título escapava da string do echo e transformava o resto do título em comandos arbitrários executados no runner do Actions.
Essa classe de vulnerabilidade é conhecida, e a própria documentação de hardening do GitHub alerta contra interpolar dados de evento diretamente em blocos run. É exatamente o tipo de falha que uma camada de revisão de segurança existe para pegar.
Duas camadas tiveram a chance. O Copilot participou do PR como coautor e revisor, e aprovou. O GitHub Advanced Security, produto de scanning construído pela mesma empresa que publica aquela documentação de hardening, processou a revisão final sem levantar alerta. A Wiz observa que segue incerto se a mudança vulnerável em si foi escrita com assistência de IA; o papel confirmado do Copilot é o de revisor, não necessariamente o de autor. A ressalva importa menos do que parece. Quem quer que tenha digitado a linha, a camada de revisão por IA olhou para uma injeção de manual e disse sim.
O Atacante Se Adaptou em Segundos
Cinco dias depois do merge, o Red Agent da Wiz, um sistema autônomo de segurança ofensiva, foi apontado para o repositório. Ele identificou a injeção, construiu um payload e o entregou pelo título da issue.
O primeiro payload falhou com um erro de sintaxe de bash.
O que veio depois é o detalhe que merece atenção. O agente leu a falha, adaptou o payload de forma autônoma e recebeu as credenciais em segundos. Nenhum operador humano depurou o exploit. O ciclo entre payload quebrado e exploit funcional se fechou em velocidade de máquina.
O prêmio foi um token de API do Jira com acesso de leitura aos projetos de engenharia, de compliance de segurança e de bug bounty da Snowflake. Pense no que um projeto de bug bounty contém: uma lista curada de vulnerabilidades conhecidas, às vezes ainda sem correção, nos sistemas do próprio alvo. O exploit vazou uma credencial que abria um mapa de outras portas.
Escrevemos em IA ofensiva reescreve o open source que a descoberta autônoma vinha comprimindo o intervalo entre vulnerabilidade e exploração em todo o ecossistema. Aquilo era a tendência. Isto é a instância: repositório nomeado, arquivo de workflow nomeado, janela de cinco dias e um atacante que se recuperou do próprio bug sem ajuda.
Por Que a Camada de Revisão Perdeu
A resposta instintiva a esse incidente é adicionar um revisor melhor. Se o Copilot deixou passar, use um modelo mais forte. Se uma revisão de IA aprovou, exija duas. Essa resposta erra a estrutura do problema.
Revisão é probabilística. Todo revisor, humano ou máquina, pega uma fração das falhas e deixa passar o resto. Empilhar revisores aumenta a fração e nunca chega a um, e a economia degrada conforme a pilha cresce: cada camada adicional custa atenção e latência enquanto pega uma fatia cada vez mais fina do que as camadas anteriores perderam. Vimos a mesma forma no portão de verificação para patches gerados por IA: saída de IA com aparência de correta atravessa verificações desenhadas para padrões de falha humanos.
A ofensa opera sob outra aritmética. Um atacante precisa que a pilha de revisão falhe uma vez, em um arquivo, em um repositório. A revisão do defensor precisa acertar em todo merge, para sempre. Quando os dois lados rodam IA, a taxa de erro do defensor se compõe a cada PR mergeado enquanto o agente do atacante tenta de novo, se adapta e só precisa de um acerto. O primeiro payload falho do Red Agent ilustra o ponto: os erros dele custaram segundos. O único erro da defesa custou uma credencial viva.
Existe um segundo problema, mais silencioso. Um revisor de IA que aprova um PR faz mais do que deixar de pegar a falha. Ele fabrica confiança. Um check verde do Copilot e um scan limpo do Advanced Security são sinais que humanos a jusante tratam como evidência de segurança. A camada de revisão que perde uma vulnerabilidade é pior do que camada nenhuma, porque converte um risco desconhecido em um risco certificado.
O Controle Que Funciona É Estrutural
A classe de vulnerabilidade do jira_issue.yml desaparece diante de controles estruturais, e nenhum deles envolve um revisor mais inteligente.
Padrões de workflow imunes a injeção eliminam a classe. Valores de contexto não confiáveis (títulos de issue, nomes de branch, corpos de PR, comentários) jamais entram em um bloco run por interpolação direta. Passado por uma variável de ambiente intermediária e devidamente citado, o mesmo título de issue vira dado inerte. Essa é uma propriedade mecânica e greppável de um arquivo de workflow. Um linter a impõe de forma determinística. Sem julgamento, sem taxa probabilística de acerto, sem upgrade de modelo.
Escopo de segredos limita o raio de dano quando um workflow é comprometido mesmo assim. O token que o Red Agent obteve podia ler os projetos de compliance de segurança e de bug bounty. Um workflow que abre issues no Jira precisa de escrita em projetos específicos e de pouco mais. A distância entre o que o workflow precisava e o que a credencial dele podia fazer é a diferença entre um incidente e um vazamento. Credenciais de vida curta e escopo estreito transformam uma injeção bem-sucedida em um evento pequeno.
O lado defensivo vem convergindo para a mesma conclusão pelo caminho oposto. O time de agentes defensivos da Ramp trata IA como ferramenta que opera dentro de guardrails estruturais, com humanos donos das fronteiras. As duas direções concordam na lição: IA pertence ao interior da estrutura de controle, executando sob restrições. Ela sozinha nunca sustenta a estrutura.
Faça Isso Agora
Audite seus workflows do GitHub Actions em busca de interpolação não confiável ainda esta semana. A checagem é concreta: rode grep em todo workflow procurando expressões ${{ dentro de blocos run e marque as que referenciam campos de github.event que alguém de fora pode influenciar, incluindo títulos de issue, títulos e corpos de PR, comentários e nomes de branch. Reescreva cada ocorrência para passar o valor por variável de ambiente. Depois liste as credenciais que seus workflows carregam e responda uma pergunta por segredo: se isso vazasse hoje, o que o portador conseguiria ler? Reduza o escopo de tudo cuja resposta surpreender.
Faça isso antes de adicionar qualquer nova ferramenta de revisão por IA. A janela de cinco dias deste incidente foi fechada por um patch, e a próxima vai se abrir em um arquivo de workflow em outro lugar. Uma camada de revisão talvez pegue. Um controle estrutural torna o evento um não-evento. Entre uma defesa que costuma funcionar e uma defesa que funciona mecanicamente, a escolha é curta.
Fontes
- Wiz Research (Gal Nagli et al.). “Wiz Red Agent identifies and exploits vulnerability in Snowflake CI/CD pipeline.” Agosto de 2026.
A Victorino ajuda organizações de engenharia a substituir revisão probabilística por IA por controles estruturais de pipeline que resistem a ataque autônomo: contato@victorino.com.br | www.victorino.com.br
Todos os artigos do The Thinking Wire são escritos com o auxílio do modelo LLM Opus da Anthropic. Cada publicação passa por pesquisa multi-agente para verificar fatos e identificar contradições, seguida de revisão e aprovação humana antes da publicação. Se você encontrar alguma informação imprecisa ou deseja entrar em contato com o editorial, escreva para editorial@victorino.com.br . Sobre o The Thinking Wire →
Se isso faz sentido, vamos conversar
Ajudamos empresas a implementar IA sem perder o controle.
Agendar uma Conversa