Un AI Security Agent hackeó Snowflake. La historia de Copilot era ruido.

Un AI agent entró en el Jira interno de Snowflake en junio, y la parte con la que casi todo el mundo abrió la historia era la equivocada. La primera versión decía que GitHub Copilot había escrito el code vulnerable, una parábola perfecta de AI poisoning AI. Esa versión duró unas horas. Wiz corrigió su propia disclosure ese mismo día, GitHub disputa de plano la attribution, y lo que queda tras la corrección es más raro y más útil: un autonomous agent encontró un flaw live, escribió un exploit, debuggeó su own failed payload y extrajo working credentials, end to end, mientras scanners convencionales sobre el mismo code no vieron nada. Esa es la historia que vale la pena.

Conclusiones clave - Red Agent de Wiz, autonomous offensive security agent, encontró una script injection en un GitHub Actions workflow del repo público snowflake-connector-net de Snowflake y la explotó para robar un Jira token. Ningún human tocó teclado entre discovery y credential exfiltration. - Flaw entró live el 18 junio 2026 y fue encontrado, explotado y reportado el 23 junio, todo vía HackerOne programme de Snowflake. Snowflake patchó ese mismo día y sus audit logs muestran Wiz como único actor en la window. - Initial claim de que Copilot escribió bug se retiró en horas. Vulnerable pattern estaba en human-authored change; contribución documentada de Copilot Autofix era otro file, y co-author label era squash-merge artefact. - GitHub Advanced Security escaneó exact vulnerable revision y la perdió. Pattern-matching scanner vio same code sobre el que agent reasoned, solo uno entendió. - Parte genuinamente agentic fue narrow pero real: diagnosticar failed exploit y reescribirlo. Resto fue good automation con language model dentro.

Qué ocurrió

Timeline, de Wiz disclosure y respuesta Snowflake:

• 18 junio 2026. PR #1218 se mergea en snowflakedb/snowflake-connector-net, repo público .NET connector de Snowflake. Reescribe workflow jira_issue.yml, que auto-crea Jira tickets cuando alguien abre GitHub issue. Rewrite reemplaza safe pattern, issue title vía environment variable a jq --arg, con interpolación directa del title en shell run: block.

• 23 junio. Red Agent, autonomous security research agent de Wiz, flags workflow como injectable mientras escanea GitHub organisation de Snowflake bajo HackerOne. Construye exploit, lo dispara, encuentra shell syntax error en own payload, diagnostica, reescribe payload y logra éxito en second attempt. Azure-hosted GitHub Actions runner llama al listener de Wiz con base64-encoded Jira API token ligado a service account. Wiz lo reporta por HackerOne ese día.

• 23 junio, mismo día. Snowflake patcha workflow, restaura safe pattern.

• 24 junio. Jira token revoked y rotated. Audit-log review no encuentra acceso de nadie salvo Wiz durante five-day exposure window. Wiz dice que borró data del proof of concept.

• 17 agosto. Wiz publica write-up por Gal Nagli, head of threat exposure en Wiz Research, y actualiza 19:57 UTC ese mismo día para aclarar que Copilot fue co-author que había checked merged PR y cleared, y que no está claro si vulnerable change fue AI-assisted.

Token llevaba read access a Jira interno de Snowflake: engineering, security compliance y bug bounty programme. No customer data touched, shipped connector nunca afectado.

El 23 junio 2026, Red Agent autónomo de Wiz encontró y explotó una script injection en GitHub Actions workflow del repository snowflake-connector-net de Snowflake, exfiltrando Jira token con read access a proyectos internos engineering, security compliance y bug bounty, cinco días después de que flaw entrara live y sin human involvement, según Wiz Research disclosure. Snowflake patchó same day y audit logs no mostraron third-party access.

Permission chain, link por link

Exploit enseña cuánto trust guarda CI pipeline. Sigue qué alcanzó un crafted issue title:

1. Trigger. Workflow corría en issues: opened, así que any GitHub account podía dispararlo abriendo issue. Conditional check destinado a gate access siempre evaluaba true en issue-opened events, según technical coverage.

2. Injection. Code hacía TITLE=$(echo '${{ github.event.issue.title }}' | sed ...). GitHub expande ${{ }} template antes shell, así que sed escaping llega tarde. Single quote cierra string y resto del title ejecuta como shell.

3. Environment. Commands corren en GitHub Actions runner, machine llena de credentials by design. Este tenía Jira API token para service account porque crear Jira tickets era su trabajo.

4. Exfiltration. Payload base64-encoded token y lo envió a Wiz listener como out-of-band callback, nada sospechoso apareció workflow logs.

5. Prize. Token autenticaba a internal Atlassian environment de Snowflake con read access a engineering, security compliance, bug bounty.

Cada link es ordinary approved infrastructure: public repo, workflow haciendo trabajo, service account con permissions necesarias. Vulnerability no era one misconfiguration, era composition. Blast radius workflow es todo lo que runner alcanza, y normalmente alcanza más de lo que team recuerda. Es mismo argumento cuando clients preguntan agent governance: pregunta no es qué agent es, sino qué puede tocar.

Exploit encadenó cinco layers de legitimate trust: una GitHub issue no autenticada trigger workflow, single-quote injection escapó shell, runner environment tenía Jira service-account token, out-of-band callback exfiltró, token abrió read access a internal Jira. GitHub template expansion ocurre antes shell escaping, por eso sanitisation llegó tarde, según Wiz write-up.

Qué fue agentic y qué no

Quiero precisión, porque "AI agent hacks Snowflake" invita dos lecturas perezosas: scanner con mejor marketing o Skynet suelto. Detalles desmienten ambas.

Automation ordinaria con model dentro. Scanning y flagging. CI/CD capability de Red Agent crawlea GitHub organisations buscando workflow files que interpolan untrusted input en run: blocks. Vulnerability class bien entendida, recognisable shape, flaggear jira_issue.yml podría hacerlo good static rule. Elegir target, leer workflow, juzgar exploitable: skilled, pero cerca de continuous attack-surface management que Wiz ya vende.

Genuinamente agentic. Exploit loop. First payload usó comment character que rompió shell syntax y falló. Agent leyó bash error, entendió por qué payload malformed, lo reescribió para cerrar script correctamente y tuvo éxito second attempt. Después validó stolen token contra Jira y assessed blast radius. Diagnosticar novel runtime failure en own attack y adaptarse unprompted no es signature matching. Loop attempt, observe, correct separa agent de scanner, same loop de agentic architecture. Verlo ofensivamente contra Fortune 500 target, unsupervised, merece nota.

No agent at all. Scope, ethics, disclosure. Red Agent operó en HackerOne programme Snowflake, sandbox elegida y authorised por human Wiz. Autonomy real pero bounded, sanctioned, monitored. Wiz launched Red Agent en marzo y generally available late July, built partly on Anthropic Claude Opus. Capability ahora product que any security team puede rent, así que offensive loop será común.

Scanning y triage de Red Agent fueron automation con model dentro; agentic core fue exploit loop: first payload lanzó shell syntax error, agent diagnosticó bash failure, reescribió payload y succeeded second attempt, luego validó token y mapped blast radius, todo sin human help, según Wiz disclosure.

Copilot row es la parte menos interesante

First headlines dijeron Copilot escribió bug. Record dice no. Documented contribution de Copilot Autofix a PR #1218 fue separate fix en file diferente, jira_close.yml. Vulnerable interpolation estaba en commit attributed a named Snowflake engineer, y GitHub dijo a reporters internal review mostró que Copilot Autofix neither wrote nor reviewed esas lines. "Co-authored by Copilot" label en merged PR era artefact de squash merge arrastrando trailer. Wiz amended post same day; The Register corrected story. Comment de Wiz CTO Ami Luttwak a CSO es takeaway honesto: con multiple agents en every PR, "just looking at co-authors of the PR is not enough" para establecer authorship.

Dos cosas pueden ser true. GitHub Advanced Security, que usa Copilot Autofix, escaneó final revision incluyendo vulnerable workflow y no flaggeó injection; Wiz lo dice, GitHub no lo disputa. Y specific claim de que Copilot authored flaw es unsupported. AI-assisted review perdió critical bug en code cleared fine. Historia real sobre limits AI review, no sobre AI writing bug. Conflar ambas no ayuda a decidir trust.

Wiz primero implicó que Copilot ayudó a escribir vulnerable code, luego aclaró same day que documented Copilot Autofix contribution era different file y co-author label squash-merge artefact. GitHub dice human engineer escribió flawed refactor y Copilot nunca reviewed esas lines. Undisputed: GitHub Advanced Security escaneó vulnerable revision y flaggeó nothing, según updated Wiz post y CSO reporting.

Qué hacer ahora

Si GitHub Actions tiene secrets, esta semana:

1. Grep workflows por ${{ github.event.* }} dentro de run: blocks. Interpolación issue titles, PR titles, branch names, comment bodies en shell es injectable. Mueve value a env: variable con quoting o jq --arg. Pattern Snowflake restored.

2. Asume runners son credential stores. Scope workflow tokens minimum, prefer short-lived OIDC versus long-lived service tokens, trata untrusted-event workflows (issues, pull_request_target, comments) como internet-facing code.

3. No dejes AI review como last line. Scanner GitHub miró exact code y passed. Layer checks, sospecha workflows donde review, authorship, scanning delegados a one vendor models.

4. Cinco días ya es lento. Agent pasó zero knowledge a working credentials en under week. Si disclosure assumes months dwell time, update. Ten credential-rotation runbook same-day.

FAQ

¿GitHub Copilot escribió vulnerability Snowflake?

No según current evidence. Copilot Autofix co-author en merged PR, pero documented change fue different file, label squash-merge artefact, GitHub dice human engineer escribió vulnerable code. True: GitHub Advanced Security escaneó vulnerable revision y perdió injection.

¿Cómo entró Wiz agent a Jira Snowflake?

Encontró workflow interpolando issue titles en shell. Crafted title ejecutó arbitrary commands en runner que tenía Jira service token. Agent exfiltró token por out-of-band callback y leyó internal Jira. Snowflake patchó report day y rotó token día siguiente.

¿Fue real attack?

Sanctioned. Red Agent operó bajo HackerOne, Wiz disclosed inmediato, audit logs Snowflake confirmaron Wiz único actor durante five days. No customer data. Technique funcionaría igual unsanctioned.

¿Qué significa para AI security agents?

Offensive ones ahead defensive. Autonomous agent found/exploited/scoped real flaw días después ship, automated scanner vio nada. Defenders deben asumir agent-speed discovery como baseline.

En resumen

Quita Copilot drama y quedan dos facts. Conventional expensive scanner reviewed code y cleared. Autonomous agent leyó same code, entendió suficiente para weaponise y corrigió propios errores. Five-day gap merged a exploited by machine es número clave. Offensive agents ahora product, no research demo, no weekends. Attribution row se olvidará; capability no.

Si decides cuánta autonomy dar a agents ofensivos/defensivos en tus pipelines, es conversación regular con clients. Ponte en contacto.

Fuentes

• 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, actualizado 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)