ZCode lastet opp kode uten tydelig samtykke – Z.ai beklager

Hvis du gir en AI-kodeagent tilgang til et privat prosjekt, skal den ikke pakke sammen kildekoden og Git-historikken din for opplasting uten at du har sagt tydelig ja. ZCode lastet opp kode uten tydelig samtykke. Klienten fra Z.ai pakket hele arbeidsområder, inkludert Git-historikk, i krypterte filer og kunne sende dem til Alibaba Cloud.

Z.ai har beklaget, fjernet funksjonen, slettet de lagrede dataene og lagt ZCode ut som åpen kildekode. Det er riktige tiltak. Men dette er ikke en liten feil i et hjørne av brukergrensesnittet. Når en kodeagent får lese forretningslogikk, nøkler, historiske commits og interne konfigurasjoner, er stilltiende opplasting et grovt tillitsbrudd.

Jeg liker kodeagenter og bruker gjerne nye modeller og verktøy. Nettopp derfor må dommen være enkel: Dette er ikke greit. En beklagelse og et ryddet repository er starten på oppryddingen, ikke et bevis på at alt som skjedde før rettingen nå kan kontrolleres i ettertid.

Hva gjorde ZCode med kildekoden?

ZCode opprettet krypterte øyeblikksbilder av arbeidsområdet, inkludert deler av .git-mappen, og hentet opplastingsinformasjon fra Z.ai før filene ble sendt direkte til Alibaba Cloud Object Storage Service. The Register beskriver hendelsen som en opplasting av komplette arbeidsområder og prosjekthistorikk uten en fungerende av-knapp eller tydelig omtale i personvernerklæringen.

Sikkerhetsforskeren Ferstar oppdaget dette da mappen ~/.zcode hadde vokst til mer enn 700 MB. I den tekniske gjennomgangen dokumenterer han en snapshot på 313 MB fra et kommersielt prosjekt, med 564 mislykkede opplastingsforsøk. Den store filen ble liggende lokalt og kom ikke ut av nettverket, men en separat snapshot av et lite offentlig repository ble ifølge serverstatusen godtatt: 538 filer og omtrent 15 KB etter komprimering og kryptering.

Det skillet er viktig. Det finnes ikke grunnlag for å hevde at akkurat det store kommersielle prosjektet ble lastet opp. Samtidig viser den mindre testen at kjeden faktisk kunne sende data ut av maskinen. Dette var altså ikke bare død kode eller en teoretisk mulighet.

Ferstar fant at 86,6 prosent av den store pakken besto av .git. Det omfattet Git-objekter, LFS-filer og reflogs. En slik pakke kan inneholde langt mer enn filene du ser i arbeidsmappen akkurat nå: slettede hemmeligheter i gamle commits, upubliserte grener, interne vertsnavn og hele utviklingshistorikken.

Hvorfor hjalp ikke krypteringen?

Kryptering beskyttet ikke brukeren mot Z.ai. Klienten krypterte innholdet med AES-256-CTR, pakket nøkkelen med RSA-OAEP-SHA256 og brukte en offentlig RSA-nøkkel som kom fra Z.ai-serveren. Den tilhørende private nøkkelen lå ikke på brukerens maskin.

Det betyr at brukeren ikke kunne åpne sin egen krypterte snapshot, mens servere under selskapets kontroll hadde nøkkelen som kunne gjøre det. Krypteringen kunne beskytte transporten og lagringsfilen mot tilfeldige tredjeparter, men den fjernet ikke selskapets mulighet til å dekryptere koden. Det er en vesentlig forskjell.

Z.ai forklarte først opplastingen med kodeindeksering, Repo Wiki og gjenoppretting av økter. Den berørte versjonen 3.12.3 hadde imidlertid en opplastingsprosess som kunne trigges før forespørsler og ved oppdatering av Repo Wiki. Forskerens tester viste også at innstillingene «Optimize Experience» og «Repo Snapshot Indexing» ikke stoppet pakkingen og opplastingsforsøkene.

Den åpne koden gjør forklaringen enda vanskeligere. Checkpoint-funksjonen som ligger der nå bruker lokale Git-kommandoer som git diff --name-status og git diff --numstat, mens metadata lagres lokalt som JSON. Vanlig gjenoppretting av endringer krevde altså ikke at hele repositoryet ble pakket og sendt til en skytjeneste med en nøkkel brukeren ikke hadde.

Dette er et godt eksempel på hvorfor tillit til en kodeagent ikke kan bygges på en pen personvernknapp alene. En agent kjører med bred tilgang fordi den skal forstå prosjektet og hjelpe deg. Når det samme tilgangsnivået brukes til en skjult skykopi, har du i praksis gitt fra deg mer enn du ble bedt om å godkjenne.

Hva har Z.ai gjort etter avsløringen?

Z.ai sier at opplastede data aldri ble brukt til modelltrening. Selskapet opplyser også at snapshot-funksjonen og Repo Wiki er fjernet, at lagrede data er slettet, og at eksterne vurderinger fra China Academy of Information and Communications Technology og sikkerhetsselskapet NSFOCUS ikke fant gjenværende opplastingsvei etter rettingen.

Den 21. september publiserte selskapet en offentlig beklagelse fra ZCode. Der lover det en varig prosess for sårbarhetsrapportering, belønning etter alvorlighetsgrad og en full sikkerhetsrapport. Selskapet åpnet samtidig hele ZCode-prosjektet under Apache-2.0-lisens.

Det er bra. Åpen kildekode gjør det mulig for utviklere å kontrollere hva dagens klient gjør, bygge den selv og følge nye endringer. ZCode 3.14.0 skal ha fjernet snapshot-kjeden fysisk, og den publiserte koden bruker lokale Git-differ for checkpoints med metadata lagret under ~/.zcode/checkpoints/.

Men en vurdering etter at bøtten er tømt, kan ikke rekonstruere hele livsløpet til data som eventuelt lå der tidligere. Påstanden om at historiske data er slettet kommer fortsatt fra selskapet og de valgte kontrollørene. Det kan være sant, men det er ikke det samme som at en utenforstående kan bevise hvert tidligere steg.

Den varslede fullrapporten blir derfor viktigere enn selve beklagelsen. Den bør beskrive hvilke klientversjoner som var berørt, når funksjonen var aktiv, hvor mange opplastinger som lyktes, hvor lenge objektene kunne eksistere, hvem som hadde tilgang til privatnøkkelen og hvordan slettingen ble verifisert. Uten slike svar blir «dataene er borte» et løfte fra den samme parten som unnlot å fortelle tydelig at dataene ble sendt.

Er den åpne kildekoden nok til å gjenopprette tilliten?

Nei, ikke alene. Det offisielle ZCode-repositoryet på GitHub inneholder klienter, backend-tjenester, delt brukergrensesnitt og kildekoden til agentens CLI og kjøremiljø. Det er reell og nyttig kode, ikke bare en tom demonstrasjon.

Problemet er historikken. Repositoryet ble opprettet 20. september og har to commits: en tom start og én stor «feat: open source»-commit. Dermed finnes det ingen offentlig diff som viser når opplastingskoden kom inn, hvordan den utviklet seg eller nøyaktig hvordan den ble fjernet. Den problematiske snapshot-kjeden er borte fra den versjonen selskapet valgte å publisere.

Åpen kildekode lar oss kontrollere nåtilstanden. En flatet historikk lar oss ikke kontrollere fortiden. Den forskjellen må ikke forsvinne i jubelen over at ZCode nå har en Apache-2.0-fil.

Dette gjelder ikke bare Z.ai. Jeg har tidligere skrevet om hvorfor valg av kodeagent og åpenhet rundt verktøyet betyr noe. Kodeagenter sitter midt i den mest verdifulle delen av mange bedrifter. De bør behandles som utviklingsinfrastruktur med høy tillit, ikke som en vanlig skriveapp som tilfeldigvis kan se noen filer.

Hva bør ZCode-brukere gjøre nå?

Oppdater først til en versjon der snapshot-opplastingen er fjernet. Den tekniske gjennomgangen bekrefter at 3.14.0 fjernet opplastingskoden. Ikke fortsett på 3.12.3 eller en annen eldre klient bare fordi den fremdeles starter.

Deretter bør du kontrollere ~/.zcode/v2/checkpoints/ før du sletter noe. Ta vare på metadata dersom du trenger dokumentasjon, og se etter store .enc-filer, pending-status og registrerte feilforsøk. På en jobbmaskin bør funn håndteres sammen med den som har ansvar for sikkerhet og kildekode, ikke ryddes bort i stillhet.

Har ZCode hatt tilgang til private repositories, bør du vurdere Git-historikken som en del av eksponeringen. Roter API-nøkler, tokens og andre hemmeligheter som finnes i nåværende eller eldre commits. Det holder ikke å se på dagens .env-fil dersom en gammel nøkkel fortsatt ligger i Git-objektene som ble pakket.

Til slutt ville jeg unngått å åpne de mest sensitive prosjektene i ZCode til du selv er fornøyd med kildekoden, nettverkstrafikken og selskapets fullstendige sikkerhetsrapport. Det er et strengere råd enn «oppdater og gå videre», men tillit er ikke en automatisk programvareoppdatering. Den må fortjenes på nytt.

Beklagelsen er starten, ikke slutten

Z.ai har fjernet funksjonen, opplyst at lagringen er slettet, hentet inn to eksterne aktører og publisert kildekoden. Det er riktige og nødvendige tiltak.

Men tiltakene gjør ikke den opprinnelige beslutningen mindre alvorlig. ZCode pakket kode og Git-historikk uten en reell av-knapp og uten den tydeligheten en slik behandling krever. For et verktøy som ber om tilgang til hele arbeidsområdet, er det vanskelig å tenke seg en raskere måte å brenne opp tillit på.

Jeg er allerede skeptisk til kinesiske AI-modeller når dataflyten er uklar. Denne saken gjør ikke den skepsisen mindre. Åpen kildekode er et godt steg, men den viktigste lærdommen gjelder alle kodeagenter: Se på nettverkstrafikk, les hva klienten faktisk gjør og hold hemmeligheter utenfor Git-historikken. «Agenten trenger tilgang» er ikke det samme som at leverandøren skal få en kopi.

Ofte stilte spørsmål