ZCode Git Snapshot-incidenten: Vad AI-kodningsagenter kan se, ladda upp och komma ihåg

Incidenten med ZCodes uppladdning av arkiv är större än ett enda kodningsverktyg. Den blottlägger en säkerhetsfråga som utvecklare i allt högre grad behöver besvara innan de ger en AI-agent åtkomst till ett projekt: betyder ”åtkomst till arkivet” den aktuella filen, arbetsträdet eller åratal av Git-historik?

Den skillnaden är viktig eftersom .git kan innehålla information som inte längre syns i den aktuella kodbasen, inklusive borttagna hemligheter, gamla källkodsversioner, reflogar, LFS-resurser och lokal grenhistorik. ZCode uppger att det berörda uppladdningsbeteendet har åtgärdats, men incidenten lämnar efter sig en viktig lärdom: AI-kodningsagenter behöver tydliga datagränser, inte bara tillåtelse att “komma åt arkivet”.

Vad hände egentligen med ZCode?

Den 18 september 2026 publicerade utvecklaren ferstar en reverse-engineering-undersökning av ZCode 3.12.3 efter att ha upptäckt oväntat stora filer i programmets lokala datakatalog.

Enligt den ursprungliga undersökningen skapade klienten krypterade ögonblicksbilder av arbetsytan som kunde innehålla källfiler samt .git, Git LFS-objekt, reflogar och metadata för arkiv. Klienten innehöll också en pipeline för att hämta uppladdningsuppgifter och skicka krypterade arkiv till Alibaba Cloud OSS.

ZCode bekräftade därefter uppladdningar av arkivdata kopplade till indexering av kodbasen och Repo Wiki, bad om ursäkt, uppgav att beteendet hade åtgärdats och meddelade planer på granskning av öppen källkod och tredje part. Samtida rapportering återgav huvudpunkterna i ZCodes svar.

Detta är den första viktiga informationsluckan att täppa till: incidenten var verklig, men vissa virala sammanfattningar överdrev vad som faktiskt överfördes.

Laddades det privata arkivet på 313 MB faktiskt upp?

Nej.

Ögonblicksbilden av det kommersiella projektet innehöll ungefär 42 000 filer och resulterade i ett krypterat arkiv på cirka 313 MB. Enligt forskarens uppdatering den 19 september fanns det fortfarande lokalt väntande status after 564 failed attempts because it exceeded the upload limit. ([blog.ferstar.org](https://blog.ferstar.org/en/posts/zcode-silent-workspace-snapshot-upload/))

Ett separat mindre offentligt repository nådde faktiskt tjänsten. Det innehöll 538 filer och genererade en mycket mindre krypterad nyttolast.

Den korrekta slutsatsen är därför inte att ”varje ZCode-repository laddades upp”. Det är att den gamla klienten innehöll en fungerande mekanism för att ladda upp repositoryn, vars faktiska framgång berodde på ögonblicksbilden.

Varför katalogen `.git` är den viktigaste delen av denna incident

I forskarens stora ögonblicksbild var det mesta av nyttolasten inte aktuell källkod.

Det innebär att ungefär 86,6% av ögonblicksbilden kom från .git. ([blog.ferstar.org](https://blog.ferstar.org/en/posts/zcode-silent-workspace-snapshot-upload/))

Detta förändrar säkerhetsbedömningen helt.

En AI-agent som läser det aktuella källkodsträdet kan se det som utvecklaren avsiktligt behåller i dag. Åtkomst till Git-historiken kan avslöja sådant som utvecklaren trodde att de redan hade tagit bort.

Möjlig historisk exponering omfattar:

• borttagna källkodsfiler
• gamla API-nycklar eller token
• tidigare interna slutpunkter
• övergivna funktioner
• historisk konfiguration
• aktivitet i lokala grenar
• tillstånd som endast finns i refloggen
• stora historiska LFS-tillgångar

I Git-dokumentationen för reflog förklaras att reflogar registrerar tidigare värden för lokala referenser. Dessa poster kan finnas lokalt även när motsvarande historik aldrig skickades till ett fjärrrepository.

Detta ger oss en användbar säkerhetsregel:

”Läs mitt projekt” och ”läs min Git-historik” bör vara separata behörigheter.

Varför borttagna hemligheter fortfarande kan finnas kvar efter att du tagit bort dem från koden

Att ta bort en autentiseringsuppgift från den senaste filen innebär inte nödvändigtvis att den tas bort från Git.

En utvecklare kan råka checka in en API-nyckel, ta bort den i nästa commit och se en helt ren aktuell fil. Det tidigare blob-objektet kan fortfarande vara nåbart via repositoryhistoriken.

GitHubs vägledning om borttagning av känsliga data rekommenderar uttryckligen att exponerade autentiseringsuppgifter återkallas eller roteras innan historiken skrivs om.

Ordningen spelar roll:

1. Ogiltigförklara autentiseringsuppgiften.
2. Ta bort känslig historik där det är lämpligt.
3. Förhindra att hemligheten checkas in igen.

För AI-kodningsagenter innebär detta att en historikmedveten funktion kan komma åt data som en vanlig redigerarvy inte längre visar.

Det förklarar också varför en skrivskyddad agent inte automatiskt innebär låg risk. Skrivskyddad åtkomst kan fortfarande läcka värdefull information om dess filsystemsomfattning är för bred eller om hämtat innehåll skickas till en fjärrmodell.

Modellkontext, telemetri, träning och uppladdningar av kodarkiv är inte samma sak

En annan viktig lärdom är att en enda ”integritetsväxel” inte kan representera alla typer av dataflöden som ett AI-kodverktyg kan ha.

Den berörda ZCode-versionen är viktig eftersom forskaren rapporterade att inaktivering av dess optimerings-/träningsalternativ inte inaktiverade den separata ögonblicksbildspipelinen. Rapporten hävdade också att växlingsknappen Repo Snapshot Indexing inte förhindrade försök att paketera och ladda upp data i den versionen. ([blog.ferstar.org](https://blog.ferstar.org/en/posts/zcode-silent-workspace-snapshot-upload/))

Detta leder till en regel som gäller långt utanför ZCode:

”Träna inte på mina data” betyder inte ”skicka inte mina data”.

En molnmodell behöver fortfarande inferenskontext. Telemetri kan skickas via en annan slutpunkt. Synkronisering kan behålla en annan kopia. Indexering av kodarkivet kan ha en egen dataström.

Samma skillnad framträder när en lokal AI-agent använder molnverktyg: integriteten beror på exakt vilken data som passerar gränsen, inte bara på var huvudagentprocessen körs.

Kryptering besvarar inte den viktigaste integritetsfrågan

Den berörda ZCode-ögonblicksbilden krypterades före uppladdningen.

Rapporten om reverse engineering beskriver AES-256-CTR-kryptering för arkivet och RSA-OAEP-SHA256-inbäddning av den symmetriska nyckeln. RSA-publiknyckeln tillhandahölls av tjänsten, medan motsvarande privata nyckel inte lagrades lokalt. ([blog.ferstar.org](https://blog.ferstar.org/en/posts/zcode-silent-workspace-snapshot-upload/))

Det skyddar data på ett annat sätt än användarkontrollerad end-to-end-kryptering.

Så ”arkivet var krypterat” är ofullständigt.

Den viktigare frågan är:

vem kan dekryptera det?

Samma princip gäller för privat RAG, molnbackup, AI-minne och alla system som hävdar att data är skyddade eftersom de är krypterade.

Hur mycket åtkomst till kodarkivet behöver en kodningsagent egentligen?

Kodningsagenter behöver legitimt mer kontext än traditionell autokomplettering. En omstrukturering som omfattar hela kodarkivet kan kräva många filer. En felsökningsagent kan behöva tester, beroendemetadata, Git-tillstånd och byggutdata.

Men ”agenten kan behöva bred kontext” innebär inte ”varje funktion bör få varje byte i kodarkivet”.

Samma princip gäller för en förtroendegräns för verktygskörning: modellens möjlighet att begära något bör inte automatiskt ge den behörighet att komma åt eller exportera allt i närheten.

För kodningsagenter behöver vi två oberoende gränser:

• Åtgärdsgräns: vad kan agenten ändra eller köra?
• Datagräns: vad kan agenten läsa eller skicka?

En agent utan skrivbehörighet kan fortfarande skapa ett allvarligt integritetshot om dess läs- och nätverksbehörigheter är obegränsade.

Vad ändrade ZCode efter incidenten?

Incidenten bör inte beskrivas som om samma beteende är känt att finnas i aktuella ZCode-versioner.

Vid en uppföljande granskning av ZCode 3.14.0 rapporterade forskaren att den tidigare uppladdningssidofilen hade tagits bort och att den gamla autentiseringsslutpunkten returnerade 404. Den granskade sökvägen hade kvar lokal checkpoint-funktionalitet utan den tidigare mekanismen för fjärruppladdning. ([blog.ferstar.org](https://blog.ferstar.org/en/posts/zcode-silent-workspace-snapshot-upload/))

Aktuell Repo Wiki-dokumentation beskriver också en mycket snävare datagräns.

Det står att Wiki-kontext utesluter:

• .git
• beroendekataloger
• byggutdata
• cachar
• lokalt körtidsläge
• stöds .gitignore undantag
• misstänkta känsliga konfigurationsfiler
• symboliska länkmål

Repo Wiki-utdata dokumenteras som lokala applikationsdata snarare än innehåll som skrivs tillbaka till kodarkivet.

Detta skiljer sig väsentligt från det snapshot-beteende som rapporterades i version 3.12.3.

Räcker öppen källkod för att göra en kodningsagent privat?

Nej.

Öppen källkod kan göra en klient enklare att granska, men en applikation med öppen källkod kan fortfarande skicka källkod till molnmodeller, ladda upp telemetri, synkronisera tillstånd eller förlita sig på lagring som kontrolleras av leverantören.

Den mer användbara checklistan är:

Det är därför en privat AI-arkitektur definieras mer av sitt dataflöde än av huruvida dess programvarulicens råkar vara öppen källkod.

Hur bör utvecklare granska en ny AI-kodningsagent?

Utvecklare behöver inte bakåtkompilera varje app, men en ny agent bör inte få ett känsligt kommersiellt arkiv som sin första testmiljö.

1. Läs dokumentationen om datahantering. Håll isär inferens, telemetri, träning, indexering, synkronisering och säkerhetskopiering.
2. Kontrollera uteslutningsreglerna. Leta särskilt efter .git, .env, ignorerade filer, beroenden, autentiseringsuppgifter och symboliska länkar.
3. Börja med ett tillfälligt arkiv. Använd icke-känslig kod först.
4. Inspektera den lokala appens lagring. Oväntat stora cacheminnen eller ögonblicksbilder kan avslöja en dold datamängd.
5. Övervaka utgående trafik. Brandväggs-, DNS-, proxy- eller routerloggar kan identifiera fjärrtjänster.
6. Använd ofarliga kanariefiler. Testa om orelaterade filer hamnar i modellens kontext eller uppladdningskontexten.
7. Ge de snävaste behörigheterna först. Utöka dem endast när en specifik uppgift kräver det.

Det är också här principen om minsta privilegium i agentdesign hjälper, så länge ”skrivskyddad” kombineras med begränsade sökvägar och kontrollerade utgående data i stället för obegränsad insyn i arkivet.

Vad en kodningsagent med lokal först-principen bör göra annorlunda

Lokal först innebär inte att varje uppgift måste köras offline.

Det innebär att lokal data som standard stannar inom den lokala förtroendegränsen och att extern överföring sker medvetet snarare än av en tillfällighet.

Denna princip är bredare än kodning. Ett verkligt lokalt AI-arbetsflöde måste hålla sin kritiska datasökväg lokal från början till slut; en lokalt installerad modell räcker inte om embeddingar, indexering, autentisering eller filbearbetning i det tysta är beroende av en fjärrtjänst.

För hybridsystem är det bättre att hålla privata filer bakom en lokal tjänst och endast exponera det minsta nödvändiga sammanhanget för godkända fjärrverktyg. Det är samma metod som används vid utformningen av en agent som använder molntjänster utan att exponera hela det lokala filsystemet.

Den större lärdomen: åtkomst till kodarkiv är en säkerhetsbehörighet

Den bestående lärdomen från ZCode är inte ”använd aldrig molnbaserade kodningsagenter”. Det är att åtkomst till kodarkiv har blivit en säkerhetsbehörighet i sig.

En modern kodningsagent kan kombinera:

• läsning av hela projekt
• Git-medvetenhet
• terminalkörning
• webbläsaråtkomst
• fjärrmodeller
• bakgrundsuppgifter
• långtidsminne
• autonom filredigering

Det innebär att utvecklare behöver granska mer än vilka kommandon en agent kan köra.

De behöver också fråga:

• Vilka filer kan den observera?
• Hur långt tillbaka i historiken kan den se?
• Vilka av dessa data lämnar maskinen?
• Vilken tjänst tar emot det?
• Hur länge sparas det?
• Vem kan dekryptera det?

För AI-kodningsagenter handlar integritet inte längre bara om huruvida modellen tränas på din kod. Det handlar om huruvida agentens datagräns motsvarar den uppgift du faktiskt bad den att utföra.