Przesyłanie historii Git przez ZCode zmienia wygodę programowania w problem zaufania

ZCode miał rzekomo przesłać całe środowisko pracy programisty o wielkości 345 MB, w tym historię Git, mimo ustawień, które pozornie ograniczały zbieranie danych. Zgłoszone przesyłanie historii Git przez ZCode nie ograniczało się do plików wybranych dla promptu AI. Obejmowało obiekty repozytorium, reflogi i duże pliki z pamięci podręcznej, które mogą zachowywać lata prywatnej pracy inżynieryjnej.

Analiza techniczna opublikowana 18 września prześledziła to zachowanie w zamkniętej aplikacji desktopowej ZCode. Według tej analizy klient tworzył zaszyfrowane punkty kontrolne przestrzeni roboczej i przesyłał je do Alibaba Cloud Object Storage Service, gdy użytkownik był zalogowany.

Ustalenie pozostaje twierdzeniem zewnętrznej analizy inżynierii wstecznej, a nie niezależnie audytowanym ujawnieniem ze strony Z.ai. W chwili publikacji dostępne oficjalne materiały nie wyjaśniały jasno zgłaszanego zakresu przesyłania, okresu przechowywania punktów kontrolnych ani sposobu, w jaki użytkownicy mogliby mu zapobiec.

Ta luka w weryfikacji jest częścią tej historii. ZCode promuje modele GLM z agentem zaprojektowanym do rozumienia przestrzeni roboczej, wykonywania poleceń i wznawiania długotrwałych zadań. Model o otwartych wagach nie czyni jednak przejrzystą otaczającej go aplikacji desktopowej.

Główny konflikt nie dotyczy więc ZCode kontra inny asystent programistyczny. Dotyczy widocznych mechanizmów kontroli prywatności produktu oraz zachowania przypisywanego jego ukrytemu systemowi punktów kontrolnych.

Co wykazał raport o przesyłaniu historii Git przez ZCode

Analiza twierdzi, że ZCode przechwycił archiwum repozytorium, a nie tylko kod potrzebny do pojedynczego żądania modelu.

Badacz zbadał prywatną komercyjną przestrzeń roboczą zawierającą 42 411 plików. Oryginalny katalog zajmował około 345 MB, podczas gdy zaszyfrowany punkt kontrolny ZCode miał około 313 MB.

Zgłoszona zawartość była szczególnie wymowna. Około 196,1 MB pochodziło z katalogu .git/lfs, w którym Git Large File Storage może buforować duże zasoby projektu. Kolejne 102,2 MB pochodziło z .git/objects, bazowej bazy danych Git zawierającej treść plików, drzewa katalogów i commity.

Reflogi dodały około 0,6 MB. Bieżące pliki źródłowe, konfiguracja i dokumentacja stanowiły około 46,2 MB, czyli 13,4 procent zmierzonego materiału.

W tym pojedynczym zrzucie katalog .git odpowiadał za 86,6 procent zarchiwizowanych danych. Nie dowodzi to średniej dla wszystkich instalacji ZCode. Pokazuje jednak, dlaczego określanie zdarzenia jako rutynowego przesłania kodu zaniża zgłaszany zakres.

Oryginalna relacja mówi, że ZCode utworzył punkt kontrolny w lokalnych danych aplikacji i pozostawił manifest w postaci zwykłego tekstu obok zaszyfrowanego archiwum. Manifest miał ujawniać bezwzględną ścieżkę do dotkniętej problemem przestrzeni roboczej.

Według analizy inżynierii wstecznej ZCode zażądał poświadczeń do przesyłania od usługi Z.ai. Odpowiedź zawierała klucz obiektu, podpisany formularz przesyłania, limit rozmiaru i publiczny klucz RSA.

Klient miał rzekomo kompresować przestrzeń roboczą, szyfrować ją za pomocą AES-256-CTR i zabezpieczać klucz symetryczny z użyciem RSA-OAEP-SHA256. Następnie przesyłał zaszyfrowany obiekt bezpośrednio do punktu końcowego pamięci masowej Aliyun.

Po zakończeniu transferu wywołanie zwrotne miało informować backend Z.ai. Jeśli ta rekonstrukcja jest prawidłowa, przesyłanie było zaprojektowanym przepływem działania aplikacji, a nie przypadkowym żądaniem modelu zawierającym zbyt dużo kontekstu.

Szyfrowanie nie rozwiązuje problemu ujawnienia. Chroni dane przed obserwatorami między komputerem a usługą przechowywania, zakładając prawidłową implementację. Nie uniemożliwia jednak zamierzonemu operatorowi usługi dostępu do informacji.

Raport podaje, że odpowiadający klucz prywatny RSA pozostawał pod kontrolą serwera. W konsekwencji użytkownik, który dostarczył repozytorium, nie mógł odszyfrować i sprawdzić punktu kontrolnego przechowywanego na tym samym komputerze.

To rozróżnienie ma znaczenie. „Zaszyfrowane” może brzmieć jak „niedostępne dla dostawcy”, ale te stwierdzenia nie są równoważne. Szyfrowanie chroni dane zależnie od tego, kto kontroluje odpowiednie klucze.

Raport twierdzi również, że dwa widoczne ustawienia prywatności nie zatrzymały tworzenia ani przesyłania punktów kontrolnych. Zarzut ten nie został potwierdzony przez niezależny audyt produktu, a jeden z uczestników Hacker News zgłosił, że nie znalazł odpowiadającego katalogu punktów kontrolnych.

Różnica może wynikać z wersji produktu, systemów operacyjnych, stanów kont, etapowego wdrażania lub użycia określonych funkcji. Może też wskazywać, że pierwotny przypadek nie dotyczy każdego użytkownika.

Z.ai musi wyjaśnić te warunki. Do tego czasu najbezpieczniejszy opis brzmi: badacze udokumentowali to zachowanie w co najmniej jednym testowanym środowisku, podczas gdy jego pełna skala pozostaje nieznana.

Dlaczego pełny katalog .git jest bardziej wrażliwy niż dzisiejszy kod

Repozytorium Git zawiera pamięć projektu, w tym informacje, które nie pojawiają się już w jego bieżących plikach.

Programiści często opisują .git jako „historię”, lecz zawiera on więcej niż wynik git log. Przechowuje obiekty, referencje, informacje o gałęziach, konfigurację, reflogi i inne metadane repozytorium.

Git jest zasadniczo bazą danych adresowaną zawartością. Jego obiekty blob zachowują treść plików, obiekty tree opisują stany katalogów, a obiekty commit łączą zrzuty w historię.

Oficjalny model obiektowy Git wyjaśnia, jak te elementy pozostają w .git/objects. Aplikacja kopiująca ten katalog może otrzymać znacznie więcej niż pliki widoczne w drzewie roboczym.

Wyobraźmy sobie programistę, który przypadkowo zapisuje poświadczenia API w commicie w poniedziałek i usuwa je we wtorek. Bieżący plik nie wyświetla już poświadczeń, ale wcześniejszy obiekt może pozostać osiągalny poprzez historię repozytorium.

Usunięcie najnowszej kopii nie wystarczy. Wytyczne GitHub dotyczące usuwania danych wrażliwych zalecają programistom najpierw unieważnić ujawnione poświadczenia, a następnie rozważyć skoordynowane przepisanie historii.

Ten sam problem dotyczy prywatnych certyfikatów, wewnętrznych nazw hostów, identyfikatorów klientów, plików środowiskowych i poświadczeń osadzonych w fixture’ach testowych. Repozytorium może również zachowywać porzuconą architekturę, poprawki bezpieczeństwa, niewydane produkty i materiały licencyjne.

Reflogi rozszerzają ryzyko. Rejestrują sposób przemieszczania się lokalnych referencji i mogą zachowywać ścieżki dostępu do commitów, które nie są już widoczne na współdzielonej gałęzi.

Lokalne gałęzie mogą ujawniać inicjatywy, które nigdy nie zostały wypchnięte. Wiadomości commitów mogą wskazywać klientów, podatności, pracowników lub wewnętrzne incydenty. Konfiguracja repozytorium może identyfikować prywatne zdalne repozytoria i domeny infrastruktury.

Git LFS wprowadza kolejną kategorię. Jego pamięć podręczna może zawierać pliki projektowe, zestawy danych, multimedia, spakowane modele lub inne pliki binarne, które programiści rozsądnie uznają za znajdujące się poza bezpośrednim kontekstem asystenta.

Zgłoszony komponent LFS o wielkości 196,1 MB nie był więc nieistotnym nadmiarem danych. Mógł reprezentować część najmniej tekstowego i najbardziej wrażliwego komercyjnie materiału projektu.

Agent programistyczny może zasadnie potrzebować szerokiego dostępu lokalnego. Nie jest w stanie refaktoryzować złożonej aplikacji bez odczytywania powiązanych modułów, uruchamiania testów lub rozumienia zależności.

To lokalne uprawnienie nie oznacza automatycznie zgody na utworzenie trwałej kopii w chmurze wszystkiego, do czego proces ma dostęp. Odczyt pliku na potrzeby żądanego zadania, wysłanie wybranego kontekstu do inferencji i archiwizacja całego repozytorium to odrębne operacje.

Dlatego twierdzenie o przesyłaniu historii Git przez ZCode jest poważniejsze niż obserwacja, że asystenci programistyczni w chmurze przetwarzają kod. Spór dotyczy zakresu, trwałości, kontroli i ujawnienia.

Programista może świadomie zatwierdzić żądanie modelu zawierające funkcję i jej zależności. Ten sam programista może odrzucić przesłanie pamięci podręcznej LFS, usuniętych poświadczeń, nieaktywnych gałęzi i lat obiektów commitów.

Użytkownicy korporacyjni mają dodatkowe obawy. Repozytorium może zawierać materiały regulowane umowami z klientami, warunkami depozytu kodu źródłowego, kontrolami eksportowymi, zasadami rezydencji danych lub politykami dostępu pracowników.

Istotne pytanie nie brzmi wyłącznie, czy użyto szyfrowania. Zespoły bezpieczeństwa muszą wiedzieć, co zebrano, gdzie to przechowywano, kto posiadał klucze, jak długo dane pozostawały w systemie i jak działało ich usuwanie.

Mechanizmy kontroli prywatności i punkty kontrolne zdają się opowiadać różne historie

Najpoważniejszym problemem jest zgłaszana luka między tym, co użytkownicy mogli kontrolować, a tym, co aplikacja miała rzekomo robić.

Oficjalna dokumentacja ZCode opisuje agenta rozumiejącego stan przestrzeni roboczej, referencje do plików, zadania i kontekst gałęzi Git. Dokumentacja agenta przedstawia również odzyskiwanie stanu jako element obsługi dłuższych zadań programistycznych.

Tworzenie punktów kontrolnych może służyć uzasadnionemu celowi. Agent edytujący dziesiątki plików potrzebuje sposobu na odzyskanie działania po nieudanej zmianie, porównanie stanów lub przywrócenie pracy przerwanej przez awarię.

Funkcja ta nie wymaga, by tworzenie punktów kontrolnych było niewidoczne. Nie dowodzi też, że każda część .git musi zostać uwzględniona w zdalnym archiwum.

Projekt chroniący prywatność mógłby domyślnie wykluczać obiekty Git i pamięci podręczne LFS. Mógłby publikować dokładny manifest archiwum przed transferem, przechowywać punkty kontrolne lokalnie lub żądać wyraźnej zgody przed synchronizacją z chmurą.

Mógłby też oferować politykę organizacyjną blokującą zdalne zrzuty. Administratorzy mogliby wymuszać wykluczenia na poziomie repozytorium i potwierdzać ich działanie za pomocą dziennika audytu.

Analiza zamiast tego twierdzi, że proces archiwizacji ZCode działał poza widoczną pętlą narzędzi agenta. Wymienione narzędzia agenta miały rzekomo nie zawierać działania tworzenia zrzutu ani przesyłania, które użytkownicy mogliby zatwierdzić.

Taka architektura wyjaśniałaby, dlaczego uprawnienia do poleceń nie zatrzymały transferu. Komponent pomocniczy na poziomie hosta może działać niezależnie od narzędzi modelu, nawet gdy użytkownik ogranicza wykonywanie powłoki lub modyfikację plików.

Ujawnia również martwy punkt w obecnych interfejsach agentów. Monity o uprawnienia zwykle koncentrują się na rzucających się w oczy działaniach, takich jak uruchomienie polecenia, edycja pliku czy otwarcie adresu sieciowego.

Usługi działające w tle otrzymują mniej uwagi. Mogą indeksować foldery, zbierać dane diagnostyczne, synchronizować sesje lub tworzyć artefakty odzyskiwania bez pojawiania się w rozmowie.

Rozróżnienie między inferencją a synchronizacją staje się tutaj ważne. Wysyłanie wybranego kodu do modelu chmurowego jest wystarczająco widoczne, by większość użytkowników oczekiwała tego od asystenta działającego w oparciu o chmurę.

Kopiowanie bazowej bazy danych repozytorium na potrzeby wycofywania zmian lub indeksowania jest drugim przepływem danych. Wymaga własnego wyjaśnienia, kontroli zakresu, zasad przechowywania i interfejsu usuwania.

Obecna polityka prywatności ZCode mówi, że dane osobowe mogą być przechowywane tak długo, jak jest to konieczne do świadczenia usług, spełniania obowiązków, ochrony uzasadnionych interesów biznesowych oraz poprawy bezpieczeństwa lub stabilności. Stwierdza również, że okres przechowywania różni się w zależności od typu danych, ich wrażliwości, celu i wymogów prawnych.

Te ogólne stwierdzenia nie odpowiadają na pytania podniesione w raporcie. Polityka powinna określać, czy punkty kontrolne przestrzeni roboczej są traktowane jako dane wejściowe użytkownika, dane techniczne czy inna kategoria.

Powinna także wyjaśniać, który region przechowywania ma zastosowanie, czy podwykonawcy przetwarzają archiwa oraz czy usunięcie konta usuwa każdy punkt kontrolny. Użytkownicy potrzebują konkretnych okresów przechowywania lub jasnych kryteriów powiązanych z odpowiednią funkcją.

Co najważniejsze, Z.ai powinno udokumentować, czy przełączniki prywatności wpływają na przesyłanie punktów kontrolnych. Kontrola opisana jako dotycząca zbierania danych może tworzyć fałszywe poczucie bezpieczeństwa, jeśli reguluje analitykę, ale nie synchronizację przestrzeni roboczej.

Język i umiejscowienie kontroli mają równie duże znaczenie jak jej wewnętrzna implementacja. Deweloperzy nie mogą podejmować świadomych decyzji, gdy istotnie różne przepływy danych są ukryte pod niejasnymi terminami.

Najsilniejsza możliwa odpowiedź Z.ai miałaby charakter techniczny, a nie retoryczny. Powinna zawierać listę dotkniętych wersji, warunków aktywacji, wykluczeń z archiwum, punktów końcowych, ról szyfrowania, okresów retencji i procedur usuwania.

Powinna również wyjaśnić, czy zachowanie zmieniło się po publikacji raportu. Bez tych szczegółów użytkownicy nie mogą ustalić, czy aktualizacja naprawiła problem, czy jedynie usunęła lokalne dowody.

Otwarte wagi nie czynią zamkniętego agenta programistycznego lokalnym

Incydent oddziela model od oprogramowania, które decyduje o tym, co model może zobaczyć i co opuszcza urządzenie.

Modele GLM są centralnym elementem strategii Z.ai dla deweloperów, a niektóre wydania zostały udostępnione z otwartymi wagami. Deweloperzy mogą analizować te pliki modeli, uruchamiać zgodne wersje we własnej infrastrukturze i unikać hostowanego punktu końcowego inferencji.

ZCode to inna warstwa. To framework, który wybiera kontekst, wywołuje narzędzia, przechowuje sesje, zarządza punktami kontrolnymi, łączy się z usługami chmurowymi i sam się aktualizuje.

Framework może decydować o rezultatach dotyczących prywatności, nawet gdy podstawowy model działa lokalnie. Lokalny model nie powstrzymuje otaczającej go aplikacji przed wysyłaniem telemetrii, indeksów, historii sesji lub migawek odzyskiwania w inne miejsca.

Podobnie otwarty model nie może ujawnić, co zamknięta aplikacja Electron robi w procesie działającym w tle. Badacze muszą obserwować ruch sieciowy, analizować pakiety aplikacji i rekonstruować zachowanie po wydaniu.

To jest główny konflikt zaufania. Doświadczenie produktowe ZCode podkreśla lokalne rozumienie przestrzeni roboczej, podczas gdy raport opisuje mechanizm przechwytywania w chmurze szerszy, niż oczekiwali deweloperzy.

Konkurenci również przetwarzają dane deweloperów, dlatego właściwe porównanie nie brzmi: „ZCode przesyła kod, podczas gdy każdy inny agent pozostaje lokalny”. Byłoby to nieprecyzyjne.

Claude Code, GitHub Copilot, Codex, Cursor i inne narzędzia połączone z chmurą wysyłają część danych wejściowych użytkowników i kontekstu kodu do usług zdalnych. Indeksy repozytoriów, sesje agentów i środowiska zadań w chmurze mogą tworzyć dodatkowe kopie.

Różnice dotyczą ujawniania informacji i kontroli. GitHub na przykład dokumentuje zasady wykluczania treści i wyjaśnia, że niektóre powierzchnie Copilot nie obsługują tych wykluczeń.

GitHub dokumentuje również, kiedy indeksowanie semantyczne repozytoriów poza GitHub przesyła dane, i stwierdza, że administratorzy przedsiębiorstw muszą włączyć tę funkcję. Te kontrole nadal mają ograniczenia, ale użytkownicy mogą zidentyfikować przepływ danych i go ocenić.

To standard, przed którym stoi teraz Z.ai. Dostawca nie musi obiecywać, że żaden kod nigdy nie opuści komputera, jeśli produkt zależy od inferencji w chmurze.

Musi dokładnie opisać każdy transfer. Musi odróżniać tymczasowy kontekst promptu od trwałej migawki repozytorium i zapewnić administratorom egzekwowalną kontrolę.

Frameworki open source oferują jedną z odpowiedzi. Ich kod może ujawniać wykluczenia archiwów, punkty końcowe sieci i zachowanie aktualizacji, a niezależni recenzenci mogą testować, czy udokumentowane ustawienia odpowiadają implementacji.

Open source nie jest pełną gwarancją bezpieczeństwa. Niewielu użytkowników analizuje każdą zależność, podpisane binaria mogą różnić się od opublikowanego kodu, a skompromitowane aktualizacje nadal mogą wyrządzić szkody.

Narzędzia o zamkniętym kodzie źródłowym również nie są automatycznie złośliwe. Mogą przechodzić niezależne oceny, zapewniać szczegółowe mapy danych, egzekwować kontrole tenantów i publikować weryfikowalne zachowanie sieciowe.

Nieprzejrzystość podnosi jednak koszt weryfikacji. Gdy aplikacja ma szerokie uprawnienia do systemu plików i autonomicznego wykonywania działań, koszt ten staje się istotnym czynnikiem bezpieczeństwa.

Dyskusja na Hacker News odzwierciedlała obie strony. Kilku komentujących uznało każdy zamknięty framework programistyczny za niedopuszczalne ryzyko, podczas gdy inni zauważyli, że agenci chmurowi z natury otrzymują kontekst projektu.

Jeden użytkownik stwierdził, że nie potrafił odtworzyć zgłoszonego katalogu punktów kontrolnych mimo korzystania z ZCode. Inni argumentowali, że sandbox powinien ograniczać każde zastrzeżone narzędzie deweloperskie, niezależnie od dostawcy lub kraju.

Te reakcje wskazują na dwa różne obowiązki. Dostawcy muszą ujawniać przepływy danych, a zespoły programistyczne muszą ograniczać zasięg agenta.

Żaden z tych obowiązków nie znosi drugiego. Sandboxowanie nie jest zgodą, a kontrola prywatności nie jest skutecznym ograniczeniem.

Bezpośrednie ryzyko zależy od zawartości repozytorium i wersji produktu

Dowody uzasadniają pilny przegląd, ale nie dowodzą, że każdy użytkownik ZCode przesłał takie same dane.

Udokumentowany przykład dotyczył jednej przestrzeni roboczej i jednej zaobserwowanej konfiguracji aplikacji. Publiczne doniesienia nie ustaliły, ile instalacji tworzyło punkty kontrolne, kiedy rozpoczęło się to zachowanie ani czy każdy system operacyjny stosował tę samą ścieżkę.

Nie jest też jasne, czy użytkownicy musieli włączyć konkretną funkcję odzyskiwania lub indeksowania. Stan uwierzytelnienia może mieć znaczenie, ponieważ raport wiąże transfery z zalogowaniem.

Istotna jest również historia wersji. Późniejsze wydanie mogło zmienić katalog, punkt końcowy, wykluczenia lub harmonogram działania, nie podważając wcześniejszej obserwacji.

Ta niepewność powinna zawężać twierdzenia, a nie tłumić dochodzenie. Zespoły, które korzystały z ZCode z prywatnymi repozytoriami, mają wystarczające dowody, aby przeprowadzić przegląd incydentu.

Powinny zacząć od zakresu. Należy zidentyfikować, którzy deweloperzy zainstalowali ZCode, z których wersji korzystali, kiedy się logowali i które repozytoria były dostępne w tych okresach.

Następnie należy sprawdzić logi punktów końcowych, proxy, DNS, zapór sieciowych i wykrywania na urządzeniach pod kątem komunikacji z usługami Z.ai i Aliyun. Lokalne pliki punktów kontrolnych mogą pomóc, ale ich brak nie dowodzi jednoznacznie, że żaden transfer nie nastąpił.

Organizacje powinny zachować dowody przed odinstalowaniem lub aktualizacją aplikacji. Aktualizacja może zmodyfikować logi, ścieżki przechowywania lub binaria, które w przeciwnym razie pomogłyby badaczom zrekonstruować aktywność.

Zespoły bezpieczeństwa powinny zakładać, że każde poświadczenie zapisane w historii potencjalnie ujawnionego repozytorium wymaga przeglądu. GitHub zaleca rotację ujawnionego poświadczenia, ponieważ usunięcie go z najnowszych plików nie neutralizuje go.

Reakcja powinna pozostać proporcjonalna. Nie należy rotować każdego firmowego poświadczenia wyłącznie dlatego, że jeden deweloper zainstalował ZCode. Najpierw należy zmapować repozytoria, a następnie przeszukać ich historię i zweryfikować, które sekrety pozostały aktywne.

Właściciele repozytoriów powinni również sprawdzić wrażliwe materiały niebędące sekretami. Stare commity mogą zawierać dane klientów, szczegóły luk, wewnętrzne punkty końcowe, licencjonowane zasoby lub negocjacje wymagające przeglądu prawnego.

Jeśli repozytorium zawierało dane regulowane lub ograniczone umownie, zespoły prawne i zgodności powinny ocenić obowiązki dotyczące powiadomień. Odpowiedź zależy od jurysdykcji, języka umowy, potwierdzonych dowodów transferu i rodzaju danych.

Deweloperzy, którzy nadal testują ZCode, powinni je izolować. Dedykowana maszyna wirtualna lub kontener może ograniczyć widoczny system plików, choć sieć i montowane katalogi nadal wymagają starannej konfiguracji.

Używaj jednorazowego repozytorium niezawierającego prawdziwych poświadczeń ani historii handlowej. Unikaj montowania katalogu domowego, folderu SSH, konfiguracji chmury, poświadczeń pakietów lub niezwiązanych drzew źródłowych.

Ograniczenia systemu plików mogą blokować katalogi punktów kontrolnych, ale stanowią kruchą ochronę. Ścieżki i procesy mogą zmieniać się między aktualizacjami, a odmowa zapisu może wyłączyć mechanizm odzyskiwania lub zakłócić działanie aplikacji.

Kontrole sieciowe oferują kolejną warstwę. Zespoły mogą ograniczać docelowe połączenia wychodzące i rejestrować próby połączeń, choć blokowanie wymaganych usług może uczynić produkt bezużytecznym.

Bezpieczniejszy model długoterminowy wykorzystuje jawne listy dozwolonych elementów. Agent otrzymuje ograniczoną kopię projektu, tymczasowe poświadczenia i wyłącznie usługi wymagane do realizacji zadania.

Takie podejście jest przydatne w różnych procesach inżynieryjnych, nie tylko w przypadku ZCode. Każdy autonomiczny asystent z dostępem do systemu plików i powłoki powinien być traktowany jako uprzywilejowana zależność w procesie wytwarzania oprogramowania.

Celem nie jest udowodnienie złośliwego zamiaru na podstawie niepełnych dowodów. Chodzi o ograniczenie konsekwencji nieudokumentowanego zachowania.

Trzy sygnały pokażą, czy Z.ai rozwiązało lukę zaufania

Kolejnym testem będzie to, czy Z.ai przekształci nieudokumentowany przepływ danych w wąską, widoczną i weryfikowalną funkcję produktu.

Pierwszym sygnałem jest szczegółowa publiczna odpowiedź. Z.ai powinno potwierdzić lub zakwestionować zgłoszone przesyłanie historii Git przez ZCode, wskazać dotknięte wersje i wyjaśnić, jaki stan produktu je uruchamiał.

Przydatne oświadczenie powinno bezpośrednio odnieść się do zmierzonej zawartości archiwum. Powinno określić, czy uwzględniono .git/objects, .git/lfs, reflogi, ignorowane pliki i globalną konfigurację.

Jeśli Z.ai opublikuje jedynie ogólne zapewnienie, że dane są szyfrowane, główna obawa pozostanie. Firma podobno kontrolowała klucz deszyfrujący, więc szyfrowanie transmisji nie odpowiada na pytania o dostęp lub retencję.

Drugim sygnałem jest egzekwowalna kontrola punktów kontrolnych. ZCode potrzebuje ustawienia, które zatrzymuje zdalne migawki, może być zarządzane przez organizację i jest niezależne od preferencji dotyczących analityki lub trenowania modeli.

Użytkownicy powinni móc zweryfikować ustawienie za pomocą logów lub udokumentowanego zdarzenia sieciowego. Aplikacja powinna pokazać, co zamierza przesłać przed pierwszym transferem.

Domyślne wykluczenia powinny usuwać .git, pamięci podręczne LFS, ignorowane pliki, poświadczenia i typowe lokalizacje sekretów. Użytkownicy mogliby wyrazić zgodę na dodatkową historię, gdy zadanie rzeczywiście jej wymaga.

Opcja odzyskiwania wyłącznie lokalnego rozwiązałaby dużą część napięcia. Punkty kontrolne mogą wspierać cofanie zmian, nie stając się archiwami w chmurze, zwłaszcza gdy agent i model działają na tej samej maszynie.

Trzecim sygnałem jest niezależne odtworzenie. Badacze muszą przetestować bieżące wydanie na obsługiwanych systemach operacyjnych, z nowymi i istniejącymi kontami oraz różnymi konfiguracjami prywatności.

Praca ta powinna odpowiedzieć, czy pierwotne zachowanie było uniwersalne, warunkowe, czy już się zmieniło. Powinna również zweryfikować, czy usunięcie punktów kontrolnych za pośrednictwem produktu usuwa każdą kopię po stronie serwera.

Ocena przeprowadzona przez stronę trzecią wzmocniłaby odpowiedź Z.ai, zwłaszcza gdyby oceniający opublikował zakres i metody. Odtwarzalne przechwycenia pakietów i manifesty archiwów byłyby cenniejsze niż ogólnikowy język certyfikacji.

Dla zespołów programistycznych lekcja wykracza poza jedną aplikację. Należy inwentaryzować agentów programistycznych jako elementy łańcucha dostaw oprogramowania, dokumentować ich punkty końcowe i przeglądać przepływy danych przed przyznaniem dostępu do prywatnych repozytoriów.

Zadaj pięć bezpośrednich pytań: Co agent może odczytać? Co przesyła? Co pozostaje zdalnie? Kto posiada klucze? Która kontrola zatrzymuje każdy transfer?

Jeśli dostawca nie potrafi odpowiedzieć na te pytania, ogranicz agenta do jednorazowych środowisk, dopóki nie będzie mógł. Jeśli odpowiedź opiera się wyłącznie na słowie „zaszyfrowane”, zapytaj, kto może to odszyfrować.

Zgłoszone przesyłanie historii Git przez ZCode nie ustaliło jeszcze zakresu ekspozycji każdego użytkownika ani nie dowiodło niewłaściwego wykorzystania jakiegokolwiek archiwum. Ustaliło jednak wiarygodną rozbieżność, która wymaga precyzyjnej odpowiedzi.

Z.ai może zmniejszyć tę lukę, publikując mechanizm, poprawiając ustawienia domyślne, oferując rzeczywisty wyłącznik i wspierając niezależną weryfikację. Do tego czasu deweloperzy powinni traktować widoczną dla ZCode przestrzeń roboczą jako minimalną możliwą granicę gromadzenia danych, a nie maksymalną.