ZCode-Git-Verlauf-Upload macht aus einer Coding-Annehmlichkeit ein Vertrauensproblem

ZCode soll einen vollständigen 345-MB-Entwickler-Workspace einschließlich seines Git-Verlaufs hochgeladen haben – trotz Einstellungen, die die Datenerhebung offenbar begrenzen sollten. Der gemeldete Upload des ZCode-Git-Verlaufs beschränkte sich nicht auf Dateien, die für einen KI-Prompt ausgewählt wurden. Er umfasste Repository-Objekte, Reflogs und zwischengespeicherte große Dateien, die jahrelange private Entwicklungsarbeit enthalten können.

Eine am 18. September veröffentlichte technische Untersuchung führte das Verhalten auf die geschlossene Desktop-Anwendung von ZCode zurück. Laut dieser Analyse erstellte der Client verschlüsselte Workspace-Checkpoints und übertrug sie an den Alibaba Cloud Object Storage Service, während der Nutzer angemeldet war.

Der Befund bleibt eine Behauptung aus Reverse Engineering durch Dritte und keine unabhängig geprüfte Offenlegung von Z.ai. Zum Veröffentlichungszeitpunkt erklärten die verfügbaren offiziellen Materialien weder den gemeldeten Umfang des Uploads noch die Aufbewahrung der Checkpoints oder die Möglichkeiten für Nutzer, ihn zu verhindern, eindeutig.

Diese Verifikationslücke ist Teil der Geschichte. ZCode bewirbt GLM-Modelle mit einem Agenten, der einen Workspace verstehen, Befehle ausführen und langlaufende Aufgaben wiederaufnehmen soll. Ein Modell mit offenen Gewichten macht die umgebende Desktop-Anwendung jedoch nicht transparent.

Der zentrale Konflikt besteht daher nicht zwischen ZCode und einem anderen Coding-Assistenten. Es geht um die sichtbaren Datenschutzkontrollen des Produkts im Vergleich zu dem Verhalten, das seinem verborgenen Checkpoint-System zugeschrieben wird.

Was der Bericht zum ZCode-Git-Verlauf-Upload herausfand

Die Untersuchung behauptet, ZCode habe ein Repository-Archiv erfasst, nicht lediglich den für eine einzelne Modellanfrage benötigten Code.

Der Forscher untersuchte einen privaten kommerziellen Workspace mit 42.411 Dateien. Das ursprüngliche Verzeichnis belegte rund 345 MB, während der verschlüsselte Checkpoint von ZCode etwa 313 MB groß war.

Die gemeldeten Inhalte waren besonders aufschlussreich. Rund 196,1 MB stammten aus dem Verzeichnis .git/lfs, in dem Git Large File Storage große Projekt-Assets zwischenspeichern kann. Weitere 102,2 MB entfielen auf .git/objects, Gits zugrunde liegende Datenbank für Dateiinhalte, Verzeichnisbäume und Commits.

Reflogs fügten etwa 0,6 MB hinzu. Aktuelle Quelldateien, Konfigurationen und Dokumentation machten etwa 46,2 MB oder 13,4 Prozent des gemessenen Materials aus.

In diesem einzelnen Snapshot entfiel auf das Verzeichnis .git ein Anteil von 86,6 Prozent der archivierten Daten. Das belegt keinen Durchschnitt über alle ZCode-Installationen hinweg. Es zeigt jedoch, warum die Beschreibung des Ereignisses als routinemäßiger Code-Upload den gemeldeten Umfang verharmlost.

Der ursprüngliche Bericht besagt, dass ZCode den Checkpoint in seinen lokalen Anwendungsdaten erstellte und neben dem verschlüsselten Archiv ein Klartext-Manifest hinterließ. Dieses Manifest soll den absoluten Pfad des betroffenen Workspaces offengelegt haben.

Dem Reverse Engineering zufolge forderte ZCode Upload-Zugangsdaten bei einem Z.ai-Dienst an. Die Antwort enthielt einen Objektschlüssel, ein signiertes Upload-Formular, eine Größenbegrenzung und einen öffentlichen RSA-Schlüssel.

Der Client soll den Workspace komprimiert, mit AES-256-CTR verschlüsselt und den symmetrischen Schlüssel mithilfe von RSA-OAEP-SHA256 verpackt haben. Anschließend habe er das verschlüsselte Objekt direkt an einen Aliyun-Speicherendpunkt gesendet.

Ein Callback soll das Backend von Z.ai nach Abschluss der Übertragung informiert haben. Falls diese Rekonstruktion zutrifft, war der Upload ein vorgesehener Anwendungsablauf und keine versehentliche Modellanfrage mit zu viel Kontext.

Verschlüsselung löst das Offenlegungsproblem nicht. Sie schützt Daten vor Beobachtern zwischen dem Computer und dem Speicherdienst, sofern die Implementierung korrekt ist. Sie verhindert nicht, dass der vorgesehene Dienstbetreiber auf die Informationen zugreift.

Dem Bericht zufolge blieb der zugehörige private RSA-Schlüssel unter Serverkontrolle. Folglich konnte der Nutzer, der das Repository bereitgestellt hatte, den auf demselben Computer gespeicherten Checkpoint nicht entschlüsseln und prüfen.

Diese Unterscheidung ist wichtig. „Verschlüsselt“ kann wie „für den Anbieter nicht verfügbar“ klingen, doch diese Aussagen sind nicht gleichbedeutend. Verschlüsselung schützt Daten abhängig davon, wer die relevanten Schlüssel kontrolliert.

Der Bericht behauptet außerdem, dass zwei sichtbare Datenschutzeinstellungen weder die Erstellung noch die Übertragung von Checkpoints verhinderten. Dieser Vorwurf wurde nicht durch ein unabhängiges Produktaudit bestätigt, und ein Teilnehmer auf Hacker News berichtete, kein entsprechendes Checkpoint-Verzeichnis gefunden zu haben.

Der Unterschied könnte auf Produktversionen, Betriebssysteme, Kontostatus, gestaffelte Auslieferungen oder die Nutzung bestimmter Funktionen zurückzuführen sein. Er könnte auch darauf hindeuten, dass der ursprüngliche Fall nicht auf jeden Nutzer zutrifft.

Z.ai muss diese Bedingungen klarstellen. Bis dahin lautet die sicherste Beschreibung, dass Forscher das Verhalten in mindestens einer getesteten Umgebung dokumentiert haben, während seine tatsächliche Verbreitung weiterhin unbekannt ist.

Warum ein vollständiges .git-Verzeichnis sensibler ist als der heutige Code

Ein Git-Repository enthält das Gedächtnis eines Projekts, einschließlich Informationen, die in den aktuellen Dateien nicht mehr erscheinen.

Entwickler beschreiben .git oft als „Verlauf“, doch es enthält mehr als die Ausgabe von git log. Es speichert Objekte, Referenzen, Branch-Informationen, Konfigurationen, Reflogs und weitere Repository-Metadaten.

Git ist im Kern eine inhaltsadressierbare Datenbank. Seine Blob-Objekte bewahren Dateiinhalte, Tree-Objekte beschreiben Verzeichniszustände, und Commit-Objekte verbinden Snapshots zu einem Verlauf.

Das offizielle Git-Objektmodell erklärt, wie diese Elemente in .git/objects verbleiben. Eine Anwendung, die dieses Verzeichnis kopiert, kann weit mehr erhalten als die im Arbeitsbaum sichtbaren Dateien.

Man stelle sich einen Entwickler vor, der am Montag versehentlich eine API-Zugangsinformation committet und sie am Dienstag entfernt. Die aktuelle Datei zeigt die Zugangsinformation nicht mehr an, doch das frühere Objekt kann weiterhin über den Repository-Verlauf erreichbar bleiben.

Das Löschen der neuesten Kopie reicht nicht aus. Die GitHub-Anleitung zum Entfernen sensibler Daten rät Entwicklern, zuerst offengelegte Zugangsdaten zu widerrufen und anschließend eine koordinierte Umschreibung des Verlaufs in Betracht zu ziehen.

Dasselbe gilt für private Zertifikate, interne Hostnamen, Kundenkennungen, Umgebungsdateien und Zugangsdaten in Test-Fixtures. Ein Repository kann außerdem verworfene Architekturansätze, Sicherheitskorrekturen, unveröffentlichte Produkte und Lizenzmaterial bewahren.

Reflogs erweitern das Risiko. Sie zeichnen auf, wie sich lokale Referenzen bewegt haben, und können Zugriffspfade zu Commits bewahren, die in einem gemeinsam genutzten Branch nicht mehr sichtbar sind.

Lokale Branches können Initiativen offenlegen, die nie gepusht wurden. Commit-Nachrichten können Kunden, Schwachstellen, Mitarbeiter oder interne Vorfälle benennen. Die Repository-Konfiguration kann private Remotes und Infrastruktur-Domains identifizieren.

Git LFS fügt eine weitere Kategorie hinzu. Sein Cache kann Designdateien, Datensätze, Medien, paketierte Modelle oder andere Binärdateien enthalten, die Entwickler vernünftigerweise außerhalb des unmittelbaren Kontexts eines Assistenten vermuten.

Die gemeldete LFS-Komponente von 196,1 MB war daher keine unwichtige Datenmenge. Sie könnte einige der am wenigsten textartigen und wirtschaftlich sensibelsten Materialien des Projekts repräsentieren.

Ein Coding-Agent kann berechtigterweise breiten lokalen Zugriff benötigen. Er kann eine komplexe Anwendung nicht umgestalten, ohne verwandte Module zu lesen, Tests auszuführen oder Abhängigkeiten zu verstehen.

Diese lokale Berechtigung impliziert jedoch nicht automatisch die Erlaubnis, eine dauerhafte Cloud-Kopie von allem zu erstellen, worauf der Prozess zugreifen kann. Das Lesen einer Datei für eine angeforderte Aufgabe, das Senden ausgewählten Kontexts für die Inferenz und die Archivierung des vollständigen Repositorys sind getrennte Vorgänge.

Deshalb ist die Behauptung zum Upload des ZCode-Git-Verlaufs schwerwiegender als die Feststellung, dass Cloud-Coding-Assistenten Code verarbeiten. Der Streit betrifft Umfang, Dauerhaftigkeit, Kontrolle und Offenlegung.

Ein Entwickler könnte einer Modellanfrage, die eine Funktion und ihre Abhängigkeiten enthält, bewusst zustimmen. Derselbe Entwickler könnte das Hochladen eines LFS-Caches, gelöschter Zugangsdaten, ruhender Branches und jahrelanger Commit-Objekte ablehnen.

Unternehmenskunden stehen vor zusätzlichen Bedenken. Ein Repository kann Material enthalten, das Kundenverträgen, Source-Code-Escrow-Klauseln, Exportkontrollen, Vorschriften zur Datenresidenz oder Richtlinien zum Mitarbeiterzugriff unterliegt.

Die relevante Frage ist nicht einfach, ob Verschlüsselung verwendet wurde. Sicherheitsteams müssen wissen, was erfasst wurde, wo es gespeichert wurde, wer die Schlüssel hielt, wie lange es erhalten blieb und wie die Löschung funktionierte.

Datenschutzkontrollen und Checkpoints scheinen unterschiedliche Geschichten zu erzählen

Die größte Sorge ist die gemeldete Lücke zwischen dem, was Nutzer kontrollieren konnten, und dem, was die Anwendung angeblich tat.

Die offizielle Dokumentation von ZCode beschreibt einen Agenten, der den Workspace-Zustand, Dateireferenzen, Aufgaben und den Git-Branch-Kontext versteht. Seine Agent-Dokumentation stellt die Wiederherstellung des Zustands zudem als Teil der Unterstützung längerer Entwicklungsaufgaben dar.

Checkpointing kann einem legitimen Zweck dienen. Ein Agent, der Dutzende Dateien bearbeitet, benötigt eine Möglichkeit, sich nach einer fehlgeschlagenen Änderung zu erholen, Zustände zu vergleichen oder durch einen Absturz unterbrochene Arbeit wiederherzustellen.

Diese Funktion erfordert nicht, dass Checkpointing unsichtbar ist. Sie belegt auch nicht, dass jeder Teil von .git in ein Remote-Archiv aufgenommen werden muss.

Ein datenschutzfreundliches Design könnte Git-Objekte und LFS-Caches standardmäßig ausschließen. Es könnte vor der Übertragung das exakte Archiv-Manifest veröffentlichen, Checkpoints lokal speichern oder vor einer Cloud-Synchronisierung eine ausdrückliche Zustimmung einholen.

Es könnte außerdem eine Organisationsrichtlinie bereitstellen, die Remote-Snapshots blockiert. Administratoren könnten Ausschlüsse auf Repository-Ebene durchsetzen und deren Wirkung über ein Audit-Protokoll bestätigen.

Die Untersuchung behauptet stattdessen, der Archivierungsprozess von ZCode sei außerhalb der sichtbaren Tool-Schleife des Agenten abgelaufen. Die aufgeführten Tools des Agenten hätten Berichten zufolge keine Snapshot- oder Upload-Aktion enthalten, die Nutzer genehmigen konnten.

Diese Architektur würde erklären, weshalb Befehlsberechtigungen die Übertragung nicht stoppen konnten. Ein Sidecar auf Host-Ebene kann unabhängig von den Tools des Modells laufen, selbst wenn der Nutzer die Shell-Ausführung oder Dateimodifikation einschränkt.

Sie legt zudem einen blinden Fleck in heutigen Agentenoberflächen offen. Berechtigungsabfragen konzentrieren sich üblicherweise auf auffällige Aktionen wie das Ausführen eines Befehls, das Bearbeiten einer Datei oder das Öffnen einer Netzwerkadresse.

Hintergrunddienste erhalten weniger Aufmerksamkeit. Sie können Ordner indexieren, Diagnosedaten erfassen, Sitzungen synchronisieren oder Wiederherstellungsartefakte erstellen, ohne im Gespräch aufzutauchen.

Die Unterscheidung zwischen Inferenz und Synchronisierung wird hier wichtig. Das Senden ausgewählten Codes an ein Cloud-Modell ist ausreichend sichtbar, sodass die meisten Nutzer dies von einem cloudgestützten Assistenten erwarten.

Das Kopieren der zugrunde liegenden Repository-Datenbank für Rollback oder Indexierung ist ein zweiter Datenfluss. Er benötigt eine eigene Erklärung, Umfangskontrollen, Aufbewahrungsregeln und eine Löschschnittstelle.

Die aktuelle Datenschutzrichtlinie von ZCode besagt, dass personenbezogene Daten so lange aufbewahrt werden können, wie dies für die Bereitstellung von Diensten, die Erfüllung von Verpflichtungen, den Schutz berechtigter Geschäftsinteressen sowie die Verbesserung von Sicherheit oder Stabilität erforderlich ist. Sie erklärt außerdem, dass die Aufbewahrung je nach Datentyp, Sensibilität, Zweck und rechtlichen Anforderungen variiert.

Diese allgemeinen Aussagen beantworten die durch den Bericht aufgeworfenen Fragen nicht. Die Richtlinie muss identifizieren, ob Workspace-Checkpoints als Nutzereingaben, technische Daten oder eine andere Kategorie gelten.

Sie sollte außerdem erklären, welche Speicherregion gilt, ob Subunternehmer die Archive verarbeiten und ob das Löschen eines Kontos jeden Checkpoint entfernt. Nutzer benötigen konkrete Aufbewahrungszeiträume oder klare Kriterien, die an die jeweilige Funktion gebunden sind.

Am wichtigsten ist, dass Z.ai dokumentieren sollte, ob Datenschutzschalter Checkpoint-Uploads beeinflussen. Ein Steuerelement, das mit Datenerfassung beschriftet ist, kann falsche Sicherheit vermitteln, wenn es Analysen regelt, aber nicht die Synchronisierung des Arbeitsbereichs.

Die Formulierung und Platzierung eines Steuerelements sind ebenso wichtig wie seine interne Umsetzung. Entwickler können keine fundierten Entscheidungen treffen, wenn wesentlich unterschiedliche Datenflüsse hinter vagen Begriffen zusammengefasst werden.

Die stärkstmögliche Antwort von Z.ai wäre technisch, nicht rhetorisch. Sie würde betroffene Versionen, Aktivierungsbedingungen, Archiv-Ausschlüsse, Endpunkte, Verschlüsselungsrollen, Aufbewahrungsfristen und Löschverfahren aufführen.

Sie würde außerdem erklären, ob sich das Verhalten nach dem Bericht geändert hat. Ohne dieses Detail können Nutzer nicht feststellen, ob ein Update das Problem behoben oder lediglich lokale Belege entfernt hat.

Offene Gewichte machen einen geschlossenen Coding-Agenten nicht lokal

Der Vorfall trennt das Modell von der Software, die entscheidet, was das Modell sehen kann und was den Rechner verlässt.

GLM-Modelle stehen im Zentrum der Entwicklerstrategie von Z.ai, und einige Veröffentlichungen wurden mit offenen Gewichten verteilt. Entwickler können diese Modelldateien untersuchen, kompatible Versionen auf ihrer eigenen Infrastruktur ausführen und einen gehosteten Inferenzendpunkt vermeiden.

ZCode ist eine andere Ebene. Es ist das Framework, das Kontext auswählt, Tools aufruft, Sitzungen speichert, Checkpoints verwaltet, sich mit Cloud-Diensten verbindet und sich selbst aktualisiert.

Das Framework kann die Datenschutzfolgen bestimmen, selbst wenn das zugrunde liegende Modell lokal läuft. Ein lokales Modell verhindert nicht, dass eine umgebende Anwendung Telemetrie, Indizes, Sitzungsverlauf oder Wiederherstellungs-Snapshots an anderer Stelle sendet.

Ebenso kann ein offenes Modell nicht offenlegen, was eine geschlossene Electron-Anwendung in einem Hintergrundprozess tut. Forscher müssen Netzwerkverkehr beobachten, Anwendungs-Bundles untersuchen und das Verhalten nach einer Veröffentlichung rekonstruieren.

Dies ist der zentrale Vertrauenskonflikt. Das Produkterlebnis von ZCode betont das lokale Verständnis des Arbeitsbereichs, während der Bericht einen Cloud-Erfassungsmechanismus beschreibt, der umfassender ist als von Entwicklern erwartet.

Auch Wettbewerber verarbeiten Entwicklernutzdaten; der richtige Vergleich lautet daher nicht: „ZCode lädt Code hoch, während jeder andere Agent lokal bleibt.“ Das wäre unzutreffend.

Claude Code, GitHub Copilot, Codex, Cursor und andere mit der Cloud verbundene Tools senden einige Nutzereingaben und Code-Kontext an entfernte Dienste. Repository-Indizes, Agent-Sitzungen und Cloud-Aufgabenumgebungen können zusätzliche Kopien erzeugen.

Die Unterschiede liegen offenbar bei Offenlegung und Kontrolle. GitHub dokumentiert beispielsweise Richtlinien zum Ausschluss von Inhalten und erklärt, dass einige Copilot-Oberflächen diese Ausschlüsse nicht unterstützen.

GitHub dokumentiert außerdem, wann semantische Indizierung für Repositories außerhalb von GitHub Daten hochlädt, und erklärt, dass Enterprise-Administratoren diese Funktion aktivieren müssen. Diese Kontrollen haben weiterhin Einschränkungen, aber Nutzer können den Datenfluss identifizieren und bewerten.

Das ist nun der Maßstab, dem Z.ai gegenübersteht. Ein Anbieter muss nicht versprechen, dass niemals Code einen Computer verlässt, wenn das Produkt von Cloud-Inferenz abhängt.

Er muss jeden Transfer präzise beschreiben. Er muss temporären Prompt-Kontext von einem dauerhaften Repository-Snapshot unterscheiden und Administratoren durchsetzbare Kontrolle geben.

Open-Source-Frameworks bieten eine Antwort. Ihr Code kann Archiv-Ausschlüsse, Netzwerkendpunkte und Update-Verhalten offenlegen, während unabhängige Prüfer testen können, ob dokumentierte Einstellungen der Implementierung entsprechen.

Open Source ist keine vollständige Sicherheitsgarantie. Nur wenige Nutzer prüfen jede Abhängigkeit, signierte Binärdateien können vom veröffentlichten Code abweichen, und kompromittierte Updates können weiterhin Schaden verursachen.

Auch Closed-Source-Tools sind nicht automatisch böswillig. Sie können unabhängige Prüfungen durchlaufen, detaillierte Datenkarten bereitstellen, Mandantenkontrollen durchsetzen und überprüfbares Netzwerkverhalten veröffentlichen.

Undurchsichtigkeit erhöht jedoch die Kosten der Verifizierung. Wenn eine Anwendung umfassende Dateisystemberechtigungen und autonome Ausführung besitzt, werden diese Kosten zu einem wesentlichen Sicherheitsaspekt.

Die Diskussion auf Hacker News spiegelte beide Seiten wider. Mehrere Kommentatoren betrachteten jedes geschlossene Coding-Framework als inakzeptables Risiko, während andere darauf hinwiesen, dass Cloud-Agenten zwangsläufig Projektkontext erhalten.

Ein Nutzer sagte, er habe das gemeldete Checkpoint-Verzeichnis trotz der Nutzung von ZCode nicht reproduzieren können. Andere argumentierten, dass eine Sandbox jedes proprietäre Entwicklertool einschränken sollte, unabhängig von Anbieter oder Land.

Diese Reaktionen benennen zwei unterschiedliche Verantwortlichkeiten. Anbieter müssen ihre Datenflüsse offenlegen, und Entwicklungsteams müssen begrenzen, worauf ein Agent zugreifen kann.

Keine dieser Verantwortlichkeiten hebt die andere auf. Sandboxing ist keine Einwilligung, und eine Datenschutzeinstellung ist keine wirksame Eindämmung.

Das unmittelbare Risiko hängt vom Repository-Inhalt und der Produktversion ab

Die Belege stützen eine dringende Überprüfung, beweisen jedoch nicht, dass bei jedem ZCode-Nutzer dieselben Daten hochgeladen wurden.

Das dokumentierte Beispiel betraf einen Arbeitsbereich und eine beobachtete Anwendungskonfiguration. Öffentliche Berichte haben nicht festgestellt, wie viele Installationen Checkpoints erstellten, wann das Verhalten begann oder ob jedes Betriebssystem demselben Pfad folgte.

Es ist auch unklar, ob Nutzer eine bestimmte Wiederherstellungs- oder Indizierungsfunktion aktivieren mussten. Der Authentifizierungsstatus könnte relevant sein, da der Bericht die Übertragungen mit einem angemeldeten Zustand verknüpft.

Auch der Versionsverlauf ist wichtig. Eine spätere Version könnte Verzeichnis, Endpunkt, Ausschlüsse oder Zeitplanverhalten ändern, ohne die frühere Beobachtung ungültig zu machen.

Diese Unsicherheit sollte Behauptungen eingrenzen, nicht Untersuchungen unterdrücken. Teams, die ZCode mit privaten Repositories verwendet haben, verfügen über genügend Belege, um eine Vorfallsprüfung durchzuführen.

Sie sollten mit der Eingrenzung beginnen. Ermitteln Sie, welche Entwickler ZCode installiert haben, welche Versionen sie nutzten, wann sie sich anmeldeten und welche Repositories in diesen Zeiträumen zugänglich waren.

Untersuchen Sie anschließend Endpunkt-, Proxy-, DNS-, Firewall- und Endpoint-Detection-Protokolle auf Kommunikation mit Z.ai- und Aliyun-Diensten. Lokale Checkpoint-Dateien können helfen, doch ihr Fehlen belegt nicht abschließend, dass keine Übertragung stattgefunden hat.

Organisationen sollten Beweise sichern, bevor sie die Anwendung deinstallieren oder aktualisieren. Ein Update kann Protokolle, Speicherpfade oder Binärdateien verändern, die Ermittlern andernfalls bei der Rekonstruktion der Aktivität helfen würden.

Sicherheitsteams sollten davon ausgehen, dass jedes Zugangsdatenpaar, das in der Historie eines exponierten Repositorys eingecheckt wurde, überprüft werden muss. GitHub empfiehlt, ein offengelegtes Zugangsdatenpaar zu rotieren, da das Entfernen aus den neuesten Dateien es nicht neutralisiert.

Diese Reaktion sollte verhältnismäßig bleiben. Rotieren Sie nicht jede Unternehmenszugangsdatenkombination allein deshalb, weil ein Entwickler ZCode installiert hat. Kartieren Sie zunächst die Repositories, durchsuchen Sie dann deren Historien und prüfen Sie, welche Geheimnisse aktiv geblieben sind.

Repository-Eigentümer sollten auch sensibles Material untersuchen, das keine Geheimnisse enthält. Alte Commits könnten Kundendaten, Details zu Schwachstellen, interne Endpunkte, lizenzierte Assets oder Verhandlungen enthalten, die eine rechtliche Prüfung erfordern.

Wenn das Repository regulierte oder vertraglich eingeschränkte Daten enthielt, sollten Rechtsberatung und Compliance-Teams Benachrichtigungspflichten bewerten. Die Antwort hängt von Rechtsraum, Vertragssprache, bestätigten Übertragungsbelegen und den betroffenen Daten ab.

Entwickler, die ZCode weiter testen, sollten es isolieren. Eine dedizierte virtuelle Maschine oder ein Container kann das sichtbare Dateisystem begrenzen, obwohl Netzwerkzugriff und eingehängte Verzeichnisse weiterhin sorgfältige Konfiguration erfordern.

Verwenden Sie ein wegwerfbares Repository ohne echte Zugangsdaten oder kommerzielle Historie. Vermeiden Sie das Einhängen eines Home-Verzeichnisses, SSH-Ordners, einer Cloud-Konfiguration, Paket-Zugangsdaten oder nicht zugehöriger Quellbäume.

Dateisystembeschränkungen können Checkpoint-Verzeichnisse blockieren, sind jedoch eine fragile Verteidigung. Pfade und Prozesse können sich mit Updates ändern, und das Verweigern von Schreibzugriffen kann Wiederherstellungsverhalten deaktivieren oder die Anwendung beeinträchtigen.

Netzwerkkontrollen bieten eine weitere Ebene. Teams können ausgehende Ziele beschränken und Verbindungsversuche protokollieren, auch wenn das Blockieren benötigter Dienste das Produkt unbrauchbar machen kann.

Ein sichereres langfristiges Modell verwendet explizite Allowlists. Der Agent erhält einen eng begrenzten Projekt-Checkout, temporäre Zugangsdaten und nur die für die Aufgabe erforderlichen Dienste.

Dieser Ansatz ist in allen Engineering-Workflows nützlich, nicht nur mit ZCode. Jeder autonome Assistent mit Dateisystem- und Shell-Zugriff sollte als privilegierte Entwicklungsabhängigkeit behandelt werden.

Das Ziel besteht nicht darin, aus unvollständigen Belegen böswillige Absichten abzuleiten. Es geht darum, die Folgen undokumentierten Verhaltens zu verringern.

Drei Signale zeigen, ob Z.ai die Vertrauenslücke geschlossen hat

Der nächste Test ist, ob Z.ai einen undokumentierten Datenfluss in eine eng begrenzte, sichtbare und überprüfbare Produktfunktion verwandelt.

Das erste Signal ist eine detaillierte öffentliche Stellungnahme. Z.ai sollte den gemeldeten Upload der ZCode-Git-Historie bestätigen oder bestreiten, betroffene Versionen identifizieren und erklären, welcher Produktzustand ihn ausgelöst hat.

Eine hilfreiche Erklärung würde die gemessenen Archivinhalte direkt ansprechen. Sie sollte darlegen, ob .git/objects, .git/lfs, Reflogs, ignorierte Dateien und globale Konfiguration enthalten waren.

Wenn Z.ai nur eine allgemeine Zusicherung veröffentlicht, dass Daten verschlüsselt sind, bleibt die zentrale Sorge bestehen. Das Unternehmen kontrollierte Berichten zufolge den Entschlüsselungsschlüssel; Transportverschlüsselung beantwortet daher keine Fragen zu Zugriff oder Aufbewahrung.

Das zweite Signal ist eine durchsetzbare Checkpoint-Kontrolle. ZCode benötigt eine Einstellung, die Remote-Snapshots stoppt, von einer Organisation verwaltet werden kann und von Analyse- oder Präferenzen für Modelltraining unabhängig ist.

Nutzer sollten die Einstellung über Protokolle oder ein dokumentiertes Netzwerkereignis überprüfen können. Die Anwendung sollte vor der ersten Übertragung anzeigen, was sie hochladen will.

Standardmäßige Ausschlüsse sollten .git, LFS-Caches, ignorierte Dateien, Zugangsdaten und gängige Speicherorte für Geheimnisse entfernen. Nutzer könnten zusätzliche Historie aktivieren, wenn eine Aufgabe sie tatsächlich erfordert.

Eine ausschließlich lokale Wiederherstellungsoption würde einen Großteil der Spannung auflösen. Checkpoints können Rollbacks unterstützen, ohne zu Cloud-Archiven zu werden, insbesondere wenn Agent und Modell auf demselben Rechner laufen.

Das dritte Signal ist eine unabhängige Reproduktion. Forscher müssen eine aktuelle Version über unterstützte Betriebssysteme, neue und bestehende Konten sowie unterschiedliche Datenschutzkonfigurationen hinweg testen.

Diese Arbeit sollte beantworten, ob das ursprüngliche Verhalten universell, bedingt oder bereits verändert war. Sie sollte außerdem prüfen, ob das Löschen von Checkpoints über das Produkt jede serverseitige Kopie entfernt.

Eine Bewertung durch Dritte würde die Antwort von Z.ai stärken, insbesondere wenn der Prüfer Umfang und Methoden veröffentlicht. Reproduzierbare Paketmitschnitte und Archivmanifeste wären wertvoller als breit gefasste Zertifizierungsformulierungen.

Für Entwicklungsteams reicht die Lehre über eine Anwendung hinaus. Erfassen Sie Coding-Agenten als Komponenten der Software-Lieferkette, dokumentieren Sie ihre Endpunkte und überprüfen Sie ihre Datenflüsse, bevor Sie ihnen Zugriff auf private Repositories gewähren.

Stellen Sie fünf direkte Fragen: Was kann der Agent lesen? Was überträgt er? Was bleibt remote gespeichert? Wer hält die Schlüssel? Welche Kontrolle stoppt jede Übertragung?

Wenn ein Anbieter diese Fragen nicht beantworten kann, beschränken Sie den Agenten auf wegwerfbare Umgebungen, bis er es kann. Wenn eine Antwort sich nur auf „verschlüsselt“ stützt, fragen Sie, wer sie entschlüsseln kann.

Der gemeldete Upload der ZCode-Git-Historie hat bislang weder die Exposition jedes Nutzers festgestellt noch einen Missbrauch eines Archivs bewiesen. Er hat eine glaubwürdige Diskrepanz aufgezeigt, die eine präzise Antwort erfordert.

Z.ai kann diese Lücke schließen, indem es den Mechanismus veröffentlicht, die Standardwerte korrigiert, einen echten Ausschalter anbietet und unabhängige Überprüfung unterstützt. Bis dahin sollten Entwickler den sichtbaren Arbeitsbereich von ZCode als minimal mögliche Erfassungsgrenze behandeln, nicht als maximale.