Um AI Security Agent hackeou a Snowflake. A história do Copilot era ruído.

Um AI agent entrou no Jira interno da Snowflake em junho, e a parte que quase todo mundo destacou primeiro era a errada. Primeira versão: GitHub Copilot tinha escrito o code vulnerável, uma parábola perfeita de AI poisoning AI. Durou poucas horas. Wiz corrigiu própria disclosure no mesmo dia, GitHub contesta attribution diretamente, e o que sobra é mais estranho e útil: autonomous agent encontrou live flaw, escreveu exploit, debugged own failed payload e puxou working credentials, end to end, enquanto scanners convencionais no same code viram nada. Essa é a história.

Principais conclusões - Red Agent da Wiz, autonomous offensive security agent, encontrou script injection em GitHub Actions workflow do repo público snowflake-connector-net e explorou para roubar Jira token. Nenhum human tocou teclado entre discovery e credential exfiltration. - Flaw live 18 junho 2026, encontrado/explorado/reportado 23 junho via HackerOne. Snowflake patch same day, audit logs mostram Wiz único actor. - Claim inicial de Copilot wrote bug recuado em horas. Vulnerable pattern human-authored; documented Copilot Autofix contribution different file; co-author label squash-merge artefact. - GitHub Advanced Security escaneou exact vulnerable revision e perdeu. Pattern scanner e agent viram same code, só um entendeu. - Parte genuinely agentic foi narrow mas real: diagnosticar failed exploit e reescrever. Resto good automation com language model.

O que aconteceu

Timeline de Wiz disclosure e Snowflake response:

• 18 junho 2026. PR #1218 merged em snowflakedb/snowflake-connector-net, repo público .NET connector. Reescreve jira_issue.yml, auto-criando Jira tickets ao abrir GitHub issue. Safe env + jq --arg substituído por direct title interpolation em shell run:.

• 23 junho. Red Agent flags injectable sob HackerOne, constrói exploit, first payload shell syntax error, diagnostica, reescreve e succeeds second attempt. Azure-hosted runner callback a Wiz com base64 Jira API token de service account. Report same day.

• 23 junho. Snowflake patch e restaura safe pattern.

• 24 junho. Token revoked/rotated, audit logs apenas Wiz na five-day window, PoC data deleted.

• 17 agosto. Wiz publica write-up Gal Nagli e update 19:57 UTC: Copilot co-author do merged PR, mas unclear se vulnerable change AI-assisted.

Token read access internal Jira engineering, security compliance, bounty. No customer data, connector unaffected.

Em 23 junho 2026, Red Agent autônomo Wiz encontrou/explorou script injection no GitHub Actions do snowflake-connector-net e exfiltrou Jira token com internal read access, cinco dias depois flaw live e sem human involvement, segundo Wiz disclosure. Snowflake patch same day e logs não mostraram third-party access.

Permission Chain, link a link

O exploit é uma aula limpa de quanto trust uma CI pipeline guarda silenciosamente. Siga até onde um único crafted issue title conseguia chegar:

1. Trigger. issues: opened, any GitHub account podia trigger. Conditional gate sempre true, segundo technical coverage.

2. Injection. TITLE=$(echo '${{ github.event.issue.title }}' | sed ...); template expansion antes shell escaping, single quote fecha string, rest executes.

3. Environment. Runner cheio credentials, incluindo Jira service token.

4. Exfiltration. Base64 token via out-of-band callback, nada suspicious logs.

5. Prize. Internal Atlassian read access engineering/security/bounty.

Tudo ordinary infrastructure. Vulnerability = composition. Blast radius = tudo runner alcança. Same agent governance principle: não o que agent é, mas o que toca.

Cinco layers legitimate trust chained, template expansion before escaping foi root cause, segundo Wiz write-up.

O que foi agentic e o que não

Quero ser preciso aqui, porque "AI agent hacks Snowflake" convida duas leituras preguiçosas: era apenas um scanner com marketing melhor, ou Skynet está solta. Os detalhes não sustentam nenhuma.

Ordinary automation com model. Crawl/flag reconhecível por static rule.

Genuinely agentic. First exploit falhou, agent leu bash error, diagnosticou malformed payload, reescreveu, succeeded second attempt, validou token e blast radius. Attempt-observe-correct = agentic architecture loop. Fortune 500, unsupervised, notable.

Não agent. Scope/ethics/disclosure foram humans. HackerOne authorised sandbox. Wiz launched Red Agent março, GA late July, partly Claude Opus. Capability agora rentable product.

Agentic core foi failed exploit diagnosis/rewrite e second-attempt success, sem human help, segundo Wiz disclosure.

Copilot Row é menos interessante

Copilot didn't write bug on current evidence. Documented contribution different file jira_close.yml; vulnerable lines human attributed; co-author label squash merge artefact. GitHub internal review says neither wrote nor reviewed. Wiz corrected.

Mas Advanced Security scanned vulnerable final revision e missed injection, undisputed. Então AI review limit story real, AI authored bug story unsupported. CSO destaca attribution complexity com multiple agents.

Wiz corrected authorship implication; GitHub says human engineer wrote flaw. Undisputed scanner miss, segundo Wiz update e CSO.

O que fazer agora

Se você roda GitHub Actions com qualquer secret, faça isto nesta semana:

1. Grep ${{ github.event.* }} em run:. Move untrusted values a env: + quote ou jq --arg.

2. Runner = credential store. Minimum scopes, OIDC, untrusted triggers (issues, pull_request_target, comments) internet-facing.

3. AI review não last line. Layer independent checks.

4. Five days é slow. Update attacker dwell assumptions e credential rotation same-day.

FAQ

Copilot escreveu vulnerability?

Não. Co-author artefact, different-file contribution. Scanner missed, isso sim.

Como entrou em Jira?

Crafted issue title -> shell command -> runner Jira token -> out-of-band exfil -> internal read.

Foi attack real?

Sanctioned HackerOne. Wiz único actor, no customer data.

O que significa para AI security agents?

Offensive agent-speed discovery é baseline. Defensive scanners podem ficar atrás.

Resumo

Expensive scanner cleared same code; autonomous agent weaponised e corrected own errors. Five-day merge-to-machine exploit gap é número relevante. Offensive agents são product e não tiram weekends. Copilot row passa, capability fica.

Se está definindo autonomy em security pipelines, converso regularmente com clients. Entre em contato.

Fontes

• Wiz Research (Gal Nagli), "Wiz Red Agent Finds Its Way Into Snowflake's Internal Jira Through a Flaw in a GitHub Copilot-Assisted PR": https://www.wiz.io/blog/red-agent-snowflake-copilot-cicd-bug (publicado 2026-08-17, atualizado 2026-08-17 19:57 UTC, consultado 2026-08-29)

• Wiz, "Introducing the Wiz Red Agent - AI-Powered Attacker": https://www.wiz.io/blog/introducing-the-wiz-red-agent (publicado 2026-03-23, consultado 2026-08-29)

• Cybersecurity News, "AI Agent Hacks Snowflake GitHub Workflow": https://cybersecuritynews.com/ai-agent-hacks-snowflake-github-workflow/ (publicado 2026-08-20, consultado 2026-08-29)

• CSO Online, "Snowflake flaw slips past AI checks, gets exploited by another AI": https://www.csoonline.com/article/4211501/snowflake-flaw-slips-past-ai-checks-gets-exploited-by-another-ai.html (publicado 2026-08-19, consultado 2026-08-29)

• Infosecurity Magazine, "Wiz AI Agent Finds Critical Snowflake GitHub Repo Flaw": https://www.infosecurity-magazine.com/news/wiz-ai-agent-finds-snowflake/ (publicado 2026-08-18, consultado 2026-08-29)

• daily.dev (from The Next Web), "GitHub disputes Wiz's claim that Copilot Autofix wrote a Snowflake flaw": https://daily.dev/posts/github-disputes-wiz-s-claim-that-copilot-autofix-wrote-a-snowflake-flaw-ybruxnh95 (publicado 2026-08-18, consultado 2026-08-29)

• snowflakedb/snowflake-connector-net repository: https://github.com/snowflakedb/snowflake-connector-net (consultado 2026-08-29)