Hvad Wiz' Agent Rent Faktisk Brød Ind I

Wiz byggede en autonom AI-agent kaldet Red Agent til at lede efter udnyttelige fejl, ligesom en menneskelig penetrationstester ville gøre, og derefter handle på det, den finder. Rettet mod Snowflakes offentlige GitHub-repositories fandt den en script-injektionsfejl i en GitHub Actions-workflowfil kaldet jira_issue.yml inde i snowflakedb/snowflake-connector-net, Snowflakes open source .NET-connector. Fejlen gjorde det muligt for hvem som helst at åbne et GitHub-issue med en specialfremstillet titel og få Snowflakes egen automatisering til at udføre en del af den titel som en shell-kommando, uden login.

Red Agents første forsøg mislykkedes. Runneren gav en syntaksfejl tilbage i stedet for at udføre payloaden. I stedet for at stoppe der læste agenten fejlen, omskrev selv den præparerede issue-titel og prøvede igen. Det andet forsøg brød ud af shell-strengen og nåede et domæne kontrolleret af angriberen, hvorved et base64-kodet Jira-API-token blev eksfiltreret. Opdagelse, justering, udnyttelse og verifikation af den opnåede adgang skete alt sammen i en enkelt session, uden at et menneske besluttede det næste skridt.

Det stjålne token var gyldigt og godkendt som en Snowflake-servicekonto, hvilket gav læseadgang til en intern Jira-instans, der dækkede projekter inden for engineering, sikkerhedsoverholdelse og bug bounty-sporing. Den sårbare kode havde været aktiv siden sammenlægningen af PR #1218 den 18. juni 2026, som erstattede et sikkert parsing-mønster med direkte variabelinterpolation i en shell-kommando. Snowflake rettede det den 23. juni 2026, genoprettede det sikre mønster og tilbagekaldte og fornyede det eksponerede token; en gennemgang af loggene fandt ingen beviser for, at en ekstern part havde brugt det i det femdages eksponeringsvindue.

Wiz Navngav Copilot Som Medforfatter til Fejlen

Wiz' oprindelige rapport pegede på den commit, der introducerede fejlen, og bemærkede, at GitHub Copilot Autofix optrådte som medforfatter på den. Fortællingen skrev sig selv: en AI-kodningsassistent syntes at have hjulpet med at skrive netop den fejl, som en AI-sikkerhedsagent bagefter fandt og udnyttede autonomt, i begge ender.

Medforfatterlinjen var ægte, og squash-sammenlægninger får den slags bevis til at fremstå mere solidt, end det er. En pull request kan indeholde mange individuelle commits fra mange bidragydere, men en squash-sammenlægning samler dem alle i en enkelt commit på hovedgrenen, og hver medforfatterlinje fra hver af de commits følger med over i det samlede resultat. Et navn på den linje registrerer deltagelse et sted i pull requesten, ikke forfatterskab til en bestemt linje. Da Wiz opdaterede sit indlæg den 17. august 2026, havde dets eget sprogbrug allerede blødt op til en erkendelse af, at det var uklart, om Copilot overhovedet havde bidraget til de sårbare linjer.

GitHubs Commit-Historik Siger, At Et Menneske Skrev Den

GitHub gennemførte sin egen interne gennemgang af det samme repository og nåede frem til en anden konklusion. Ifølge GitHub skrev en menneskelig Snowflake-ingeniør den usikre omskrivning, i en separat commit dateret 25. august 2025, cirka ti måneder før den sårbare pull request blev sammenlagt, og Copilot Autofix hverken gennemgik eller bidrog til de specifikke linjer.

Copilots faktiske medforfatter-commit inden i pull request #1218 ændrede en anden fil, jira_close.yml, som ikke havde nogen forbindelse til de sårbare jira_issue.yml-linjer, som Red Agent udnyttede. Da pull requesten blev presset sammen til en enkelt merge-commit, fulgte Copilots medforfatterlinje alligevel med, hæftet på en ændring, den aldrig havde rørt.

Striden står nu offentligt med to uforenelige udlægninger og ingen uafhængig dommer. Wiz peger på en medforfatterlinje i den levende commit-historik; GitHub peger på en intern gennemgang af det samme repository, der læser forfatterskabet anderledes. Ingen uden for de to virksomheder har den adgang, der er nødvendig for at afgøre, hvilken læsning der er korrekt.

Governance-Hullet, Ethvert AI-Understøttet Team Bør Bemærke

At køre en AI-kodningsassistent og en AI-sikkerhedsscanner i den samme pipeline er hurtigt ved at blive standardopsætningen, ikke undtagelsen. Når noget går galt under den opsætning, kan både den part, der finder fejlen, og værktøjet, der beskyldes for at have skrevet den, begge være AI-systemer, og det eneste bevis, nogen af parterne kan pege på, er commit-historikken for et repository. Den historik er kun så pålidelig som de praksisser, der har frembragt den, og en rutinemæssig squash-sammenlægning har lige bevist, at den kan hæfte navnet på en bidragyder til en andens fejl, uden at nogen tilsigtede det.

Fejlen selv forblev eksponeret i fem dage og krævede fem dage mere at rette. Diskussionen om, hvem der skrev den, varede længere end selve sårbarheden, og den udspillede sig mellem to leverandører med ressourcerne og repository-adgangen til at undersøge den ordentligt. En virksomhed med mindre disciplin omkring at bevare commit-historikken for sine egne workflow-filer, og uden et fast svar på, hvem i virksomheden der er bemyndiget til at offentliggøre en tilskrivningspåstand, før den bliver en offentlig strid, vil ikke løse sin version lige så pænt.

Læs videre: En enkelt post var mere værd end alle tre fonde  |  En fjernet frontier-model er online igen