Le téléchargement de l’historique Git de ZCode transforme une commodité de codage en problème de confiance

ZCode aurait téléchargé l’intégralité d’un espace de travail de développeur de 345 Mo, y compris son historique Git, malgré des paramètres qui semblaient limiter la collecte de données. Le téléchargement signalé de l’historique Git de ZCode ne se limitait pas aux fichiers sélectionnés pour une invite IA. Il incluait des objets de dépôt, des reflogs et des fichiers volumineux mis en cache, susceptibles de conserver des années de travail d’ingénierie privé.

Une enquête technique publiée le 18 septembre a retracé ce comportement dans l’application de bureau fermée de ZCode. Selon cette analyse, le client créait des points de contrôle chiffrés de l’espace de travail et les transférait vers Alibaba Cloud Object Storage Service lorsque l’utilisateur était connecté.

Cette découverte reste une affirmation de rétro-ingénierie par un tiers, et non une divulgation auditée de manière indépendante par Z.ai. Au moment de la publication, les documents officiels disponibles n’expliquaient pas clairement la portée signalée du téléchargement, la conservation des points de contrôle ni la manière dont les utilisateurs pouvaient l’empêcher.

Ce déficit de vérification fait partie de l’histoire. ZCode promeut les modèles GLM avec un agent conçu pour comprendre un espace de travail, exécuter des commandes et reprendre des tâches de longue durée. Toutefois, un modèle à poids ouverts ne rend pas transparente l’application de bureau qui l’entoure.

Le conflit central n’oppose donc pas ZCode à un autre assistant de codage. Il concerne les contrôles de confidentialité visibles du produit face au comportement attribué à son système de points de contrôle caché.

Ce que le rapport sur le téléchargement de l’historique Git de ZCode a révélé

L’enquête affirme que ZCode a capturé une archive de dépôt, et pas seulement le code nécessaire à une requête de modèle.

Le chercheur a examiné un espace de travail commercial privé contenant 42 411 fichiers. Le répertoire d’origine occupait environ 345 Mo, tandis que le point de contrôle chiffré de ZCode faisait approximativement 313 Mo.

Le contenu signalé était particulièrement révélateur. Environ 196,1 Mo provenaient du répertoire .git/lfs, où Git Large File Storage peut mettre en cache de volumineux actifs de projet. Quelque 102,2 Mo supplémentaires provenaient de .git/objects, la base de données sous-jacente de Git contenant les contenus de fichiers, les arborescences de répertoires et les commits.

Les reflogs ajoutaient environ 0,6 Mo. Les fichiers source actuels, la configuration et la documentation représentaient environ 46,2 Mo, soit 13,4 % du matériel mesuré.

Dans cet instantané particulier, le répertoire .git représentait 86,6 % des données archivées. Cela n’établit pas une moyenne pour l’ensemble des installations de ZCode. Cela montre toutefois pourquoi qualifier l’événement de simple téléchargement de code minimise la portée signalée.

Le récit original indique que ZCode a créé le point de contrôle dans ses données d’application locales et laissé un manifeste en clair à côté de l’archive chiffrée. Ce manifeste aurait révélé le chemin absolu de l’espace de travail concerné.

Selon la rétro-ingénierie, ZCode a demandé des identifiants de téléchargement à un service Z.ai. La réponse incluait une clé d’objet, un formulaire de téléchargement signé, une limite de taille et une clé publique RSA.

Le client aurait compressé l’espace de travail, l’aurait chiffré avec AES-256-CTR et aurait encapsulé la clé symétrique avec RSA-OAEP-SHA256. Il aurait ensuite publié l’objet chiffré directement sur un point de terminaison de stockage Aliyun.

Un rappel aurait informé le backend de Z.ai après l’achèvement du transfert. Si cette reconstruction est exacte, le téléchargement relevait d’un flux applicatif conçu à cette fin plutôt que d’une requête de modèle contenant accidentellement trop de contexte.

Le chiffrement ne résout pas le problème de divulgation. Il protège les données contre les observateurs entre l’ordinateur et le service de stockage, à condition que l’implémentation soit correcte. Il n’empêche pas l’opérateur de service prévu d’accéder aux informations.

Le rapport indique que la clé privée RSA correspondante est restée sous le contrôle du serveur. Par conséquent, l’utilisateur qui a fourni le dépôt ne pouvait pas déchiffrer et examiner le point de contrôle stocké sur ce même ordinateur.

Cette distinction est importante. « Chiffré » peut sembler vouloir dire « inaccessible au fournisseur », mais ces affirmations ne sont pas équivalentes. Le chiffrement protège les données selon l’entité qui contrôle les clés concernées.

Le rapport affirme également que deux paramètres de confidentialité visibles n’ont pas empêché la création ou le transfert des points de contrôle. Cette allégation n’a pas été confirmée par un audit indépendant du produit, et un participant à Hacker News a indiqué n’avoir trouvé aucun répertoire de point de contrôle correspondant.

Cette différence pourrait s’expliquer par les versions du produit, les systèmes d’exploitation, les états des comptes, un déploiement progressif ou l’utilisation de fonctions spécifiques. Elle pourrait aussi indiquer que le cas initial ne s’applique pas à tous les utilisateurs.

Z.ai doit clarifier ces conditions. D’ici là, la description la plus prudente est que des chercheurs ont documenté ce comportement dans au moins un environnement testé, tandis que son ampleur réelle demeure inconnue.

Pourquoi un répertoire .git complet est plus sensible que le code actuel

Un dépôt Git contient la mémoire d’un projet, y compris des informations qui n’apparaissent plus dans ses fichiers actuels.

Les développeurs décrivent souvent .git comme « l’historique », mais il contient davantage que le résultat de git log. Il stocke des objets, des références, des informations sur les branches, de la configuration, des reflogs et d’autres métadonnées de dépôt.

Git est fondamentalement une base de données adressable par le contenu. Ses objets blob préservent le contenu des fichiers, ses objets tree décrivent les états des répertoires et ses objets commit relient les instantanés dans un historique.

Le modèle d’objets Git officiel explique comment ces éléments restent dans .git/objects. Une application qui copie ce répertoire peut recevoir bien plus que les fichiers visibles dans l’arborescence de travail.

Prenons le cas d’un développeur qui valide accidentellement un identifiant API le lundi et le supprime le mardi. Le fichier actuel n’affiche plus l’identifiant, mais l’objet antérieur peut rester accessible via l’historique du dépôt.

Supprimer la dernière copie ne suffit pas. Les recommandations de GitHub sur la suppression de données sensibles demandent aux développeurs de révoquer d’abord les identifiants exposés, puis d’envisager une réécriture coordonnée de l’historique.

Le même problème s’applique aux certificats privés, aux noms d’hôtes internes, aux identifiants clients, aux fichiers d’environnement et aux identifiants intégrés dans des fixtures de test. Un dépôt peut également conserver une architecture abandonnée, des correctifs de sécurité, des produits non publiés et des éléments de licence.

Les reflogs étendent le risque. Ils enregistrent les déplacements des références locales et peuvent préserver des chemins d’accès vers des commits qui ne sont plus visibles sur une branche partagée.

Les branches locales peuvent révéler des initiatives qui n’ont jamais été publiées. Les messages de commit peuvent nommer des clients, des vulnérabilités, des employés ou des incidents internes. La configuration du dépôt peut identifier des dépôts distants privés et des domaines d’infrastructure.

Git LFS introduit une autre catégorie. Son cache peut contenir des fichiers de conception, des jeux de données, des médias, des modèles empaquetés ou d’autres binaires que les développeurs considèrent raisonnablement comme extérieurs au contexte immédiat d’un assistant.

La composante LFS signalée de 196,1 Mo n’était donc pas un simple volume sans importance. Elle pouvait représenter certains des éléments les moins textuels et les plus sensibles commercialement du projet.

Un agent de codage peut légitimement nécessiter un large accès local. Il ne peut pas refactoriser une application complexe sans lire les modules associés, exécuter des tests ou comprendre les dépendances.

Cette autorisation locale n’implique pas automatiquement l’autorisation de créer une copie cloud durable de tout ce qui est accessible au processus. Lire un fichier pour une tâche demandée, envoyer un contexte sélectionné pour l’inférence et archiver l’intégralité du dépôt sont des opérations distinctes.

C’est pourquoi l’affirmation concernant le téléchargement de l’historique Git de ZCode est plus grave que le constat selon lequel les assistants de codage cloud traitent du code. Le différend porte sur la portée, la persistance, le contrôle et la divulgation.

Un développeur pourrait approuver sciemment une requête de modèle contenant une fonction et ses dépendances. Ce même développeur pourrait refuser de télécharger un cache LFS, des identifiants supprimés, des branches inactives et des années d’objets de commit.

Les utilisateurs en entreprise font face à des préoccupations supplémentaires. Un dépôt peut contenir des éléments régis par des contrats clients, des conditions de séquestre de code source, des contrôles à l’exportation, des règles de résidence des données ou des politiques d’accès des employés.

La question pertinente n’est pas simplement de savoir si le chiffrement a été utilisé. Les équipes de sécurité doivent savoir ce qui a été collecté, où cela a été stocké, qui détenait les clés, combien de temps cela a été conservé et comment la suppression fonctionnait.

Les contrôles de confidentialité et les points de contrôle semblent raconter des histoires différentes

La préoccupation la plus vive est l’écart signalé entre ce que les utilisateurs pouvaient contrôler et ce que l’application aurait fait.

La documentation officielle de ZCode décrit un agent qui comprend l’état de l’espace de travail, les références de fichiers, les tâches et le contexte des branches Git. Sa documentation sur les agents présente également la récupération d’état comme un élément du soutien aux tâches de développement plus longues.

Les points de contrôle peuvent avoir une finalité légitime. Un agent qui modifie des dizaines de fichiers a besoin d’un moyen de récupérer après une modification échouée, de comparer des états ou de restaurer un travail interrompu par un plantage.

Cette fonction n’exige pas que les points de contrôle soient invisibles. Elle n’établit pas non plus que chaque partie de .git doit être incluse dans une archive distante.

Une conception respectueuse de la confidentialité pourrait exclure par défaut les objets Git et les caches LFS. Elle pourrait publier le manifeste exact de l’archive avant le transfert, conserver les points de contrôle localement ou demander une approbation explicite avant une synchronisation cloud.

Elle pourrait également fournir une politique d’organisation bloquant les instantanés distants. Les administrateurs pourraient appliquer des exclusions au niveau du dépôt et en confirmer l’effet par un journal d’audit.

L’enquête allègue au contraire que le processus d’archivage de ZCode fonctionnait en dehors de la boucle visible des outils de l’agent. Les outils répertoriés de l’agent ne contiendraient aucune action d’instantané ou de téléchargement que les utilisateurs pourraient approuver.

Cette architecture expliquerait pourquoi les autorisations de commande n’ont pas empêché le transfert. Un composant auxiliaire au niveau de l’hôte peut fonctionner indépendamment des outils du modèle, même lorsque l’utilisateur restreint l’exécution de shell ou la modification de fichiers.

Elle révèle également un angle mort dans les interfaces actuelles des agents. Les invites d’autorisation se concentrent généralement sur des actions visibles, telles que l’exécution d’une commande, la modification d’un fichier ou l’ouverture d’une adresse réseau.

Les services en arrière-plan reçoivent moins d’attention. Ils peuvent indexer des dossiers, collecter des diagnostics, synchroniser des sessions ou créer des artefacts de récupération sans apparaître dans la conversation.

La distinction entre inférence et synchronisation devient importante ici. L’envoi de code sélectionné à un modèle cloud est suffisamment visible pour que la plupart des utilisateurs s’y attendent de la part d’un assistant reposant sur le cloud.

Copier la base de données de dépôt sous-jacente pour la restauration ou l’indexation constitue un second flux de données. Il nécessite sa propre explication, des contrôles de portée, des règles de conservation et une interface de suppression.

La politique de confidentialité actuelle de ZCode indique que les données personnelles peuvent être conservées selon les besoins pour fournir les services, respecter des obligations, protéger des intérêts commerciaux légitimes et améliorer la sécurité ou la stabilité. Elle précise également que la conservation varie selon le type de données, leur sensibilité, leur finalité et les exigences légales.

Ces déclarations générales ne répondent pas aux questions soulevées par le rapport. La politique doit préciser si les points de contrôle d’espace de travail sont considérés comme des données saisies par l’utilisateur, des données techniques ou une autre catégorie.

Elle devrait également expliquer quelle région de stockage s’applique, si des sous-traitants traitent les archives et si la suppression d’un compte retire chaque point de contrôle. Les utilisateurs ont besoin de périodes de conservation concrètes ou de critères clairs liés à la fonction concernée.

Plus important encore, Z.ai devrait indiquer si les réglages de confidentialité affectent les téléversements de points de contrôle. Un contrôle présenté comme portant sur la collecte de données peut créer un faux sentiment de sécurité s’il régit l’analytique, mais pas la synchronisation de l’espace de travail.

La formulation et l’emplacement d’un contrôle comptent autant que son implémentation interne. Les développeurs ne peuvent pas prendre de décisions éclairées lorsque des flux de données substantiellement différents sont regroupés sous des termes vagues.

La réponse la plus solide possible de Z.ai serait technique, non rhétorique. Elle listerait les versions concernées, les conditions d’activation, les exclusions d’archive, les endpoints, les rôles de chiffrement, les durées de conservation et les procédures de suppression.

Elle préciserait aussi si le comportement a changé après le signalement. Sans ce détail, les utilisateurs ne peuvent pas déterminer si une mise à jour a corrigé le problème ou s’est simplement contentée de supprimer les traces locales.

Des poids ouverts ne rendent pas local un agent de programmation fermé

L’incident distingue le modèle du logiciel qui décide de ce que le modèle peut voir et de ce qui quitte la machine.

Les modèles GLM sont au cœur de la stratégie de Z.ai destinée aux développeurs, et certaines versions ont été distribuées avec des poids ouverts. Les développeurs peuvent examiner ces fichiers de modèle, exécuter des versions compatibles sur leur propre infrastructure et éviter un endpoint d’inférence hébergé.

ZCode constitue une couche différente. C’est le harnais qui choisit le contexte, invoque les outils, stocke les sessions, gère les points de contrôle, se connecte aux services cloud et se met à jour.

Le harnais peut déterminer les conséquences en matière de confidentialité même lorsque le modèle sous-jacent s’exécute localement. Un modèle local n’empêche pas une application qui l’entoure d’envoyer ailleurs des données de télémétrie, des index, l’historique des sessions ou des instantanés de récupération.

De même, un modèle ouvert ne peut pas révéler ce qu’une application Electron fermée fait dans un processus d’arrière-plan. Les chercheurs doivent observer le trafic réseau, inspecter les bundles d’application et reconstituer le comportement après la publication.

C’est le principal conflit de confiance. L’expérience produit de ZCode met en avant la compréhension locale de l’espace de travail, tandis que le signalement décrit un mécanisme de capture cloud plus étendu que ce que les développeurs attendaient.

Les concurrents traitent eux aussi des données de développeurs ; la bonne comparaison n’est donc pas « ZCode téléverse du code tandis que tous les autres agents restent locaux ». Ce serait inexact.

Claude Code, GitHub Copilot, Codex, Cursor et d’autres outils connectés au cloud envoient certains éléments saisis par les utilisateurs et certains contextes de code à des services distants. Les index de dépôt, les sessions d’agent et les environnements de tâches cloud peuvent créer des copies supplémentaires.

Les différences se situent dans la transparence et le contrôle. GitHub, par exemple, documente ses politiques d’exclusion de contenu et explique que certaines surfaces Copilot ne prennent pas en charge ces exclusions.

GitHub indique également quand l’indexation sémantique de dépôts externes à GitHub téléverse des données et précise que les administrateurs d’entreprise doivent activer cette fonctionnalité. Ces contrôles présentent encore des limites, mais les utilisateurs peuvent identifier le flux de données et l’évaluer.

C’est désormais la norme à laquelle Z.ai est confrontée. Un fournisseur n’a pas besoin de promettre qu’aucun code ne quitte jamais un ordinateur si son produit dépend de l’inférence cloud.

Il doit décrire chaque transfert avec précision. Il doit distinguer un contexte de prompt temporaire d’un instantané persistant de dépôt et offrir aux administrateurs un contrôle réellement applicable.

Les harnais open source offrent une réponse possible. Leur code peut révéler les exclusions d’archive, les endpoints réseau et le comportement de mise à jour, tandis que des évaluateurs indépendants peuvent vérifier si les réglages documentés correspondent à l’implémentation.

L’open source ne constitue pas une garantie de sécurité complète. Peu d’utilisateurs inspectent chaque dépendance, les binaires signés peuvent différer du code publié et des mises à jour compromises peuvent toujours causer des dommages.

Les outils fermés ne sont pas non plus automatiquement malveillants. Ils peuvent faire l’objet d’évaluations indépendantes, fournir des cartes détaillées des données, appliquer des contrôles par tenant et publier un comportement réseau vérifiable.

Cependant, l’opacité augmente le coût de la vérification. Lorsqu’une application dispose de larges permissions sur le système de fichiers et d’une exécution autonome, ce coût devient une considération de sécurité importante.

La discussion sur Hacker News a reflété les deux positions. Plusieurs commentateurs ont considéré tout harnais de programmation fermé comme un risque inacceptable, tandis que d’autres ont souligné que les agents cloud reçoivent intrinsèquement le contexte des projets.

Un utilisateur a déclaré ne pas pouvoir reproduire le répertoire de points de contrôle signalé malgré son utilisation de ZCode. D’autres ont soutenu qu’un sandbox devrait contraindre tout outil propriétaire destiné aux développeurs, quel que soit le fournisseur ou le pays.

Ces réactions mettent en évidence deux responsabilités distinctes. Les fournisseurs doivent divulguer leurs flux de données, et les équipes de développement doivent limiter ce qu’un agent peut atteindre.

Aucune de ces responsabilités n’annule l’autre. Le sandboxing n’est pas un consentement, et un contrôle de confidentialité n’est pas un confinement efficace.

Le risque immédiat dépend du contenu du dépôt et de la version du produit

Les éléments disponibles justifient un examen urgent, mais ne prouvent pas que chaque utilisateur de ZCode a vu les mêmes données téléversées.

L’exemple documenté concernait un espace de travail et une configuration d’application observée. Les informations publiques n’ont pas établi combien d’installations créaient des points de contrôle, quand ce comportement a commencé, ni si chaque système d’exploitation suivait le même chemin.

Il reste également incertain que les utilisateurs aient dû activer une fonctionnalité particulière de récupération ou d’indexation. L’état d’authentification peut avoir son importance, puisque le signalement associe les transferts à une session ouverte.

L’historique des versions compte aussi. Une version ultérieure pourrait modifier le répertoire, l’endpoint, les exclusions ou le comportement de planification sans invalider l’observation antérieure.

Cette incertitude doit restreindre les affirmations, non étouffer l’enquête. Les équipes ayant utilisé ZCode avec des dépôts privés disposent de suffisamment d’éléments pour mener un examen d’incident.

Elles devraient commencer par délimiter le périmètre. Identifiez quels développeurs ont installé ZCode, quelles versions ils ont exécutées, à quel moment ils se sont connectés et quels dépôts étaient accessibles pendant ces périodes.

Examinez ensuite les journaux des endpoints, des proxys, du DNS, des pare-feu et de la détection sur endpoint afin d’identifier les communications avec les services Z.ai et Aliyun. Les fichiers locaux de point de contrôle peuvent être utiles, mais leur absence n’établit pas de manière concluante qu’aucun transfert n’a eu lieu.

Les organisations devraient préserver les éléments de preuve avant de désinstaller ou de mettre à jour l’application. Une mise à jour peut modifier les journaux, les chemins de stockage ou les binaires qui aideraient autrement les enquêteurs à reconstituer l’activité.

Les équipes de sécurité devraient considérer que tout identifiant commité dans l’historique d’un dépôt exposé nécessite un examen. GitHub recommande de faire tourner un identifiant divulgué, car le supprimer des derniers fichiers ne le neutralise pas.

Cette réponse doit rester proportionnée. Ne faites pas tourner tous les identifiants de l’entreprise uniquement parce qu’un développeur a installé ZCode. Cartographiez d’abord les dépôts, puis recherchez dans leurs historiques et vérifiez quels secrets sont restés actifs.

Les propriétaires de dépôts devraient également examiner les éléments sensibles qui ne sont pas des secrets. D’anciens commits peuvent contenir des données clients, des détails de vulnérabilités, des endpoints internes, des actifs sous licence ou des négociations nécessitant un examen juridique.

Si le dépôt contenait des données réglementées ou soumises à des restrictions contractuelles, les équipes juridiques et de conformité devraient évaluer les obligations de notification. La réponse dépend de la juridiction, du libellé du contrat, des preuves de transfert confirmées et des données concernées.

Les développeurs qui continuent à tester ZCode devraient l’isoler. Une machine virtuelle ou un conteneur dédié peut limiter le système de fichiers visible, même si la configuration du réseau et des répertoires montés exige toujours une grande attention.

Utilisez un dépôt jetable ne contenant aucun véritable identifiant ni historique commercial. Évitez de monter un répertoire personnel, un dossier SSH, une configuration cloud, des identifiants de packages ou des arborescences de code source non liées.

Les restrictions du système de fichiers peuvent bloquer les répertoires de points de contrôle, mais constituent une défense fragile. Les chemins et les processus peuvent changer au fil des mises à jour, et refuser les écritures peut désactiver le comportement de récupération ou rendre l’application inutilisable.

Les contrôles réseau offrent une autre couche. Les équipes peuvent restreindre les destinations sortantes et enregistrer les tentatives de connexion, même si le blocage des services requis peut rendre le produit inutilisable.

Un modèle à long terme plus sûr utilise des listes d’autorisation explicites. L’agent reçoit un checkout de projet limité, des identifiants temporaires et uniquement les services nécessaires à la tâche.

Cette approche est utile dans l’ensemble des workflows d’ingénierie, et pas seulement avec ZCode. Tout assistant autonome disposant d’un accès au système de fichiers et au shell doit être traité comme une dépendance de développement privilégiée.

L’objectif n’est pas de prouver une intention malveillante à partir d’éléments incomplets. Il est de réduire les conséquences d’un comportement non documenté.

Trois signaux montreront si Z.ai a comblé le déficit de confiance

Le prochain test consiste à voir si Z.ai transforme un flux de données non documenté en une fonctionnalité produit étroite, visible et vérifiable.

Le premier signal serait une réponse publique détaillée. Z.ai devrait confirmer ou contester le téléversement signalé de l’historique Git de ZCode, identifier les versions concernées et expliquer quel état du produit l’a déclenché.

Une déclaration utile aborderait directement le contenu mesuré des archives. Elle devrait préciser si .git/objects, .git/lfs, les reflogs, les fichiers ignorés et la configuration globale étaient inclus.

Si Z.ai publie seulement une assurance générale selon laquelle les données sont chiffrées, la préoccupation centrale demeure. L’entreprise contrôlait apparemment la clé de déchiffrement ; le chiffrement en transit ne répond donc pas aux questions d’accès ou de conservation.

Le deuxième signal serait un contrôle de point de contrôle applicable. ZCode a besoin d’un réglage qui arrête les instantanés distants, qui peut être géré par une organisation et qui est indépendant des préférences d’analytique ou d’entraînement des modèles.

Les utilisateurs devraient pouvoir vérifier ce réglage au moyen de journaux ou d’un événement réseau documenté. L’application devrait afficher ce qu’elle prévoit de téléverser avant le premier transfert.

Les exclusions par défaut devraient retirer .git, les caches LFS, les fichiers ignorés, les identifiants et les emplacements courants de secrets. Les utilisateurs pourraient choisir d’inclure de l’historique supplémentaire lorsqu’une tâche l’exige réellement.

Une option de récupération uniquement locale résoudrait une grande partie de la tension. Les points de contrôle peuvent prendre en charge le retour arrière sans devenir des archives cloud, en particulier lorsque l’agent et le modèle s’exécutent sur la même machine.

Le troisième signal serait une reproduction indépendante. Les chercheurs doivent tester une version actuelle sur les systèmes d’exploitation pris en charge, avec des comptes nouveaux et existants, et avec différentes configurations de confidentialité.

Ce travail devrait déterminer si le comportement d’origine était universel, conditionnel ou déjà modifié. Il devrait aussi vérifier si la suppression des points de contrôle via le produit supprime chaque copie côté serveur.

Une évaluation par un tiers renforcerait la réponse de Z.ai, en particulier si l’évaluateur publie le périmètre et les méthodes. Des captures de paquets reproductibles et des manifestes d’archive auraient plus de valeur qu’un langage général de certification.

Pour les équipes de développement, la leçon dépasse une seule application. Inventoriez les agents de programmation comme des composants de la chaîne d’approvisionnement logicielle, documentez leurs endpoints et examinez leurs flux de données avant de leur accorder l’accès à des dépôts privés.

Posez cinq questions directes : Que peut lire l’agent ? Que transmet-il ? Que conserve-t-il à distance ? Qui détient les clés ? Quel contrôle arrête chaque transfert ?

Si un fournisseur ne peut pas répondre à ces questions, limitez l’agent à des environnements jetables jusqu’à ce qu’il le puisse. Si une réponse repose uniquement sur le terme « chiffré », demandez qui peut le déchiffrer.

Le téléversement signalé de l’historique Git de ZCode n’a pas encore établi l’exposition de chaque utilisateur ni prouvé une utilisation abusive d’une archive. Il a établi un décalage crédible qui exige une réponse précise.

Z.ai peut réduire cet écart en publiant le mécanisme, en corrigeant les paramètres par défaut, en proposant un véritable interrupteur d’arrêt et en soutenant une vérification indépendante. D’ici là, les développeurs devraient considérer l’espace de travail visible de ZCode comme la limite minimale possible de collecte, et non la limite maximale.