Incident lié à un instantané Git de ZCode : ce que les agents de codage IA peuvent voir, téléverser et mémoriser
L'incident d'importation de dépôt de ZCode dépasse le cadre d'un seul outil de codage. Il met en lumière une question de sécurité à laquelle les développeurs doivent de plus en plus répondre avant d'autoriser un agent IA à accéder à un projet : « l'accès au dépôt » désigne-t-il le fichier actuel, l'arborescence de travail ou des années d'historique Git ?
Cette distinction est importante, car .git peut contenir des informations qui ne sont plus visibles dans la base de code actuelle, notamment des secrets supprimés, d'anciennes versions des sources, des reflogs, des ressources LFS et l'historique des branches locales. ZCode affirme que le comportement d'importation concerné a été corrigé, mais l'incident laisse une leçon durable : les agents de codage IA ont besoin de limites explicites concernant les données, et pas seulement de l'autorisation d'« accéder au dépôt ».
Que s'est-il réellement passé avec ZCode ?
Le 18 septembre 2026, le développeur ferstar a publié une enquête de rétro-ingénierie sur ZCode 3.12.3 après avoir remarqué des fichiers inhabituellement volumineux dans le répertoire de données local de l'application.
Selon l'enquête originale, le client créait des instantanés chiffrés de l'espace de travail pouvant inclure les fichiers sources ainsi que .git, les objets Git LFS, les reflogs et les métadonnées du dépôt. Le client contenait également un pipeline permettant d'obtenir des identifiants d'importation et d'envoyer des archives chiffrées vers Alibaba Cloud OSS.
ZCode a ensuite reconnu les importations de données de dépôt associées à l'indexation des bases de code et à Repo Wiki, s'est excusé, a déclaré que le comportement avait été corrigé et a annoncé des projets d'examen par la communauté open source et des tiers. La couverture contemporaine a repris les principaux éléments de la réponse de ZCode.
| Affirmation | Preuves |
|---|---|
| Les anciennes versions de ZCode créaient de vastes instantanés des dépôts | Étayé par la rétro-ingénierie et les preuves issues de l'instantané local |
| Un pipeline d'importation existait | Étayé par le comportement du client, reconstitué par rétro-ingénierie |
| Un petit dépôt a bien atteint le service | Vérifié par le test de suivi du chercheur |
| Le dépôt commercial de 313 Mo a bien été importé | Non — cet import a échoué |
| La version actuelle de ZCode utilise toujours le même pipeline | Aucune preuve ; le chercheur indique que l'ancien chemin a été supprimé |
C'est la première lacune importante à combler : l'incident était réel, mais certains résumés viraux ont exagéré ce qui avait effectivement été transféré.
Le dépôt privé de 313 Mo a-t-il réellement été importé ?
Non.
L'instantané du projet commercial contenait environ 42 000 fichiers et a produit une archive chiffrée d'environ 313 Mo. Selon la mise à jour du chercheur du 19 septembre, il était toujours stocké localement en attente état après 564 tentatives échouées, car la limite d'importation avait été dépassée. ([blog.ferstar.org](https://blog.ferstar.org/en/posts/zcode-silent-workspace-snapshot-upload/))
Un autre dépôt public plus petit a bien atteint le service. Il contenait 538 fichiers et a produit une charge utile chiffrée bien plus petite.
| Dépôt | Résultat observé |
|---|---|
| Dépôt commercial de 313 Mo | Empaqueté localement, tentatives répétées, téléversement échoué |
| Petit dépôt public | Accepté avec succès par le service distant |
La conclusion correcte n'est donc pas que « chaque dépôt ZCode a été téléversé ». C'est que l'ancien client contenait un mécanisme fonctionnel de téléversement de dépôts, dont la réussite effective dépendait de l'instantané.
Pourquoi le répertoire `.git` est l'élément le plus important de cet incident
Dans le vaste instantané du chercheur, la majeure partie de la charge utile n'était pas constituée du code source actuel.
| Contenu de l'instantané | Part approximative |
|---|---|
.git/lfs/ |
56.8% |
.git/objects/ |
29.6% |
.git/logs/ |
0.2% |
| Code source et documentation actuels | 13.4% |
Cela signifie qu'environ 86.6 % de l'instantané provenait de .git. ([blog.ferstar.org](https://blog.ferstar.org/en/posts/zcode-silent-workspace-snapshot-upload/))
Cela change complètement l'interprétation en matière de sécurité.
Un agent IA lisant l'arborescence source actuelle peut voir ce que le développeur choisit intentionnellement de conserver aujourd'hui. L'accès à l'historique Git peut révéler ce que le développeur pensait avoir déjà supprimé.
L'exposition historique possible comprend :
- fichiers source supprimés
- anciennes clés API ou anciens jetons
- anciens points de terminaison internes
- fonctionnalités abandonnées
- configuration historique
- activité des branches locales
- états uniquement présents dans le reflog
- ressources LFS historiques volumineuses
La documentation du reflog Git explique que les reflogs enregistrent les valeurs précédentes des références locales. Ces enregistrements peuvent exister localement même lorsque l'historique correspondant n'a jamais été envoyé vers un dépôt distant.
Cela nous donne une règle de sécurité utile :
« Lire mon projet » et « lire mon historique Git » devraient être des autorisations distinctes.
Pourquoi des secrets supprimés peuvent encore exister après leur suppression du code
Supprimer un identifiant du dernier fichier ne signifie pas nécessairement le supprimer de Git.
Un développeur peut valider accidentellement une clé API, la supprimer dans la validation suivante et constater que le fichier actuel est parfaitement propre. Le blob précédent peut toutefois rester accessible dans l'historique du dépôt.
Les recommandations de GitHub concernant la suppression des données sensibles préconisent explicitement de révoquer ou de renouveler les identifiants exposés avant de réécrire l'historique.
Cet ordre est important :
- Invalidez l'identifiant d'authentification.
- Supprimez l'historique sensible lorsque cela est nécessaire.
- Empêchez que le secret soit de nouveau validé.
Pour les agents de codage IA, cela signifie qu'une fonctionnalité tenant compte de l'historique peut accéder à des données qu'une vue d'éditeur normale n'expose plus.
Cela explique également pourquoi un agent en lecture seule ne présente pas automatiquement un faible risque. Un accès en lecture seule peut tout de même divulguer des informations précieuses si la portée de son système de fichiers est trop large ou si le contenu récupéré est envoyé à un modèle distant.
Le contexte du modèle, la télémétrie, l'entraînement et les téléversements de dépôts ne sont pas la même chose
Une autre leçon importante est qu'un simple bouton « confidentialité » ne peut pas représenter tous les types de flux de données qu'un outil de programmation assistée par IA peut avoir.
| Flux de données | Objectif typique |
|---|---|
| Contexte d'inférence | Envoyer le code nécessaire pour répondre à la tâche actuelle |
| Télémétrie | Mesurer les plantages, la fiabilité et l'utilisation |
| Données d'entraînement du modèle | Améliorer les futurs modèles ou le comportement du produit |
| Index du dépôt | Rechercher un projet et le comprendre plus efficacement |
| Snapshot cloud | Préserver l'état plus large de l'espace de travail |
| Synchronisation / sauvegarde | Restaurer les données entre les sessions ou les appareils |
La version concernée de ZCode est importante, car le chercheur a signalé que la désactivation de son option d'optimisation/d'entraînement ne désactivait pas le pipeline séparé de snapshots. Le rapport affirmait également que, dans cette version, l'option d'indexation des snapshots du dépôt n'empêchait pas les tentatives de mise en paquet et de téléversement. ([blog.ferstar.org](https://blog.ferstar.org/en/posts/zcode-silent-workspace-snapshot-upload/))
Cela conduit à une règle qui s'applique bien au-delà de ZCode :
« Ne pas entraîner le modèle sur mes données » ne signifie pas « ne pas transmettre mes données ».
Un modèle cloud a toujours besoin du contexte d'inférence. La télémétrie peut transiter par un autre point de terminaison. La synchronisation peut conserver une autre copie. L'indexation du dépôt peut avoir son propre chemin de données.
La même distinction apparaît lorsqu'un agent IA local utilise des outils cloud : la confidentialité dépend des données exactes qui franchissent la frontière, et pas simplement de l'endroit où s'exécute le processus principal de l'agent.
Le chiffrement ne répond pas à la question la plus importante en matière de confidentialité
Le snapshot ZCode concerné a été chiffré avant son téléversement.
Le rapport de rétro-ingénierie décrit un chiffrement AES-256-CTR pour l'archive et un encapsulage RSA-OAEP-SHA256 pour la clé symétrique. La clé publique RSA était fournie par le service, tandis que la clé privée correspondante n'était pas stockée localement. ([blog.ferstar.org](https://blog.ferstar.org/en/posts/zcode-silent-workspace-snapshot-upload/))
Cela protège les données différemment d'un chiffrement de bout en bout contrôlé par l'utilisateur.
| Protection | Ce que cela signifie |
|---|---|
| TLS / chiffrement du transport | Protège les données lors de leur transmission sur le réseau |
| Chiffrement cloud au repos | Protège les octets stockés contre certaines menaces liées à l'infrastructure |
| Clé contrôlée par le fournisseur | Le service peut conserver la capacité technique de déchiffrer |
| Clé de bout en bout contrôlée par l'utilisateur | Le service ne possède pas la clé de déchiffrement requise |
Ainsi, dire que « le dépôt a été chiffré » est incomplet.
La question la plus pertinente est :
qui peut le déchiffrer ?
Ce même principe s’applique au RAG privé, à la sauvegarde cloud, à la mémoire d’IA et à tout système qui prétend protéger les données parce qu’elles sont chiffrées.
De quel accès au dépôt un agent de programmation a-t-il réellement besoin ?
Les agents de programmation ont légitimement besoin de plus de contexte que l’autocomplétion traditionnelle. Une refactorisation à l’échelle du dépôt peut nécessiter de nombreux fichiers. Un agent de débogage peut avoir besoin des tests, des métadonnées des dépendances, de l’état Git et de la sortie de compilation.
Mais « l’agent peut avoir besoin d’un contexte étendu » n’implique pas que « chaque fonctionnalité devrait recevoir chaque octet du dépôt ».
| Portée des données | Valeur par défaut raisonnable |
|---|---|
| Fichier actuel | Autoriser pour les tâches pertinentes |
| Fichiers source référencés | Autoriser |
| Arborescence complète du code source | Dépendant de la tâche |
.gitignore-fichiers exclus |
Exclure |
.env / identifiants |
Bloquer |
.git objets |
Exclure sauf nécessité explicite |
| Reflogs | Exclure par défaut |
| Cache Git LFS | Exclure sauf si nécessaire |
| Identifiants SSH / cloud | Bloquer |
| Instantané distant complet | Consentement explicite |
Il s’agit d’une version axée sur l’accès aux données du même principe que celui utilisé dans une limite de confiance pour l’exécution d’outils : la capacité du modèle à demander quelque chose ne devrait pas automatiquement lui accorder le droit d’accéder à tout ce qui se trouve à proximité ou de tout exporter.
Pour les agents de programmation, nous avons besoin de deux limites indépendantes :
- Limite des actions : que peut modifier ou exécuter l’agent ?
- Limite des données : que peut lire ou envoyer l’agent ?
Un agent sans permission d’écriture peut tout de même créer une grave exposition de la vie privée si ses permissions de lecture et de réseau sont illimitées.
Qu’a changé ZCode après l’incident ?
L’incident ne doit pas être décrit comme si le même comportement était avéré dans les versions actuelles de ZCode.
Lors d’une inspection de suivi de ZCode 3.14.0, le chercheur a signalé que l’ancien fichier auxiliaire de téléversement avait été supprimé et que l’ancien point de terminaison d’identifiants renvoyait une erreur 404. Le chemin inspecté conservait la fonctionnalité de point de contrôle local sans l’ancien mécanisme de téléversement distant. ([blog.ferstar.org](https://blog.ferstar.org/en/posts/zcode-silent-workspace-snapshot-upload/))
La documentation actuelle de Repo Wiki décrit également une limite de données bien plus étroite.
Il indique que le contexte Wiki exclut :
.git- répertoires de dépendances
- sortie de compilation
- caches
- état d’exécution local
- pris en charge
.gitignoreexclusions - fichiers de configuration potentiellement sensibles
- cibles des liens symboliques
La sortie de Repo Wiki est documentée comme des données d’application locales plutôt que comme du contenu réécrit dans le dépôt.
Cela diffère sensiblement du comportement de capture instantanée signalé dans la version 3.12.3.
L’open source suffit-il à rendre un agent de programmation privé ?
Non.
L’open source peut rendre un client plus facile à auditer, mais une application open source peut tout de même envoyer du code source à des modèles cloud, téléverser des données de télémétrie, synchroniser son état ou dépendre d’un stockage contrôlé par un fournisseur.
La liste de contrôle la plus utile est :
| Question | Propriété de sécurité |
|---|---|
| Que peut lire l’agent ? | Portée des données locales |
| Que peut quitter la machine ? | Limite de sortie |
| Pourquoi ces données sont-elles transmises ? | Limitation des finalités |
| Combien de temps est-il conservé ? | Persistance |
| Qui contrôle les clés de chiffrement ? | Autorité de déchiffrement |
| Le comportement peut-il être désactivé ? | Contrôle utilisateur |
| Des personnes externes peuvent-elles le vérifier ? | Auditabilité |
C’est pourquoi une architecture d’IA privée se définit davantage par son flux de données que par le fait que sa licence logicielle soit open source.
Comment les développeurs doivent-ils auditer un nouvel agent de programmation doté d’IA ?
Les développeurs n’ont pas besoin de rétroconcevoir chaque application, mais un nouvel agent ne devrait pas recevoir un dépôt commercial sensible comme premier environnement de test.
- Lisez la documentation relative au traitement des données. Distinguez l’inférence, la télémétrie, l’entraînement, l’indexation, la synchronisation et la sauvegarde.
-
Vérifiez les règles d’exclusion. Recherchez notamment
.git,.env, les fichiers ignorés, les dépendances, les identifiants et les liens symboliques. - Commencez par un dépôt jetable. Utilisez d’abord du code non sensible.
- Inspectez le stockage local de l’application. Des caches ou instantanés volumineux inattendus peuvent révéler une portée cachée des données.
- Surveillez le trafic sortant. Les journaux du pare-feu, du DNS, du proxy ou du routeur peuvent identifier les services distants.
- Utilisez des fichiers canaris inoffensifs. Vérifiez si des fichiers sans rapport entrent dans le contexte du modèle ou du téléversement.
- Accordez d’abord les autorisations les plus limitées. Élargissez-les uniquement lorsqu’une tâche précise l’exige.
C’est également là que la conception d’agents selon le principe du moindre privilège est utile, à condition de combiner la « lecture seule » avec des chemins restreints et des données sortantes contrôlées, plutôt qu’avec une visibilité illimitée sur le dépôt.
Ce qu’un agent de programmation axé sur le local devrait faire différemment
Le local par défaut ne signifie pas que chaque tâche doit s’exécuter hors ligne.
Cela signifie que les données locales restent par défaut à l’intérieur de la limite de confiance locale, et que toute transmission externe est délibérée plutôt qu’accessoire.
| Principe du local par défaut | Comportement recommandé |
|---|---|
| Indexation du dépôt | Conservez localement, lorsque cela est possible, les symboles, les représentations vectorielles et les métadonnées |
| Contexte du modèle distant | N’envoyez que le code pertinent pour la tâche |
| Historique Git | Excluez-les sauf si la tâche nécessite explicitement l’historique |
| Secrets | Filtrez avant de construire le contexte |
| Téléversement distant | Indiquez la portée et demandez un consentement explicite |
| Consentement à l’entraînement | Séparez cela des autorisations d’inférence |
| Dépôts sensibles | Proposez des voies entièrement locales pour le modèle et l’indexation |
| Dépendance au réseau | Documentez ce qui cesse de fonctionner hors ligne |
Ce principe dépasse largement le simple codage. Un flux de travail d’IA véritablement local doit conserver son chemin de données critique en local de bout en bout ; l’installation locale d’un modèle ne suffit pas si les représentations vectorielles, l’indexation, l’authentification ou le traitement des fichiers dépendent discrètement d’un service distant.
Pour les systèmes hybrides, la meilleure approche consiste à conserver les fichiers privés derrière un service local et à n’exposer aux outils distants approuvés que le contexte minimal requis. C’est la même approche que celle utilisée lors de la conception d’un agent qui utilise des services cloud sans exposer l’intégralité de votre système de fichiers local.
La leçon principale : l’accès aux dépôts est une autorisation de sécurité
La leçon durable de ZCode n’est pas de « ne jamais utiliser d’agents de codage cloud ». C’est que l’accès aux dépôts est devenu une autorisation de sécurité à part entière.
Un agent de codage moderne peut combiner :
- lecture de l’intégralité du projet
- prise en charge de Git
- exécution dans le terminal
- accès au navigateur
- modèles distants
- tâches en arrière-plan
- mémoire à long terme
- édition autonome des fichiers
Cela signifie que les développeurs doivent examiner plus que les commandes qu’un agent peut exécuter.
Ils doivent également se demander :
- Quels fichiers peut-il observer ?
- Jusqu’à quelle profondeur de l’historique peut-il remonter ?
- Laquelle de ces données quitte la machine ?
- Quel service le reçoit ?
- Combien de temps est-il conservé ?
- Qui peut le déchiffrer ?
Pour les agents de codage IA, la confidentialité ne consiste plus simplement à déterminer si le modèle s’entraîne sur votre code. Il s’agit de savoir si la frontière de données de l’agent correspond réellement à la tâche que vous lui avez demandé d’effectuer.
Foire aux questions sur l’incident de téléversement du dépôt ZCode
ZCode a-t-il téléversé l’intégralité du dépôt privé de 313 Mo du chercheur ?
Non. Le chercheur a indiqué que la capture volumineuse d’un projet commercial avait été empaquetée et placée à plusieurs reprises dans la file d’attente de téléversement, mais que l’opération avait échoué en raison de sa taille. Un dépôt public distinct, plus petit, a été accepté par le service.
`.git` peut-il contenir des secrets qui ne figurent plus dans le code actuel ?
Oui. Les objets Git et les commits historiques peuvent conserver d’anciennes versions des fichiers après la suppression de contenu sensible de l’arborescence de travail. Les reflogs peuvent également contenir un historique local des références qui n’a peut-être jamais été envoyé vers un dépôt distant.
La désactivation de l’entraînement de l’IA empêche-t-elle un agent de codage de téléverser du code ?
Pas nécessairement. L’entraînement, l’inférence, l’indexation du dépôt, la télémétrie, la synchronisation cloud et la sauvegarde sont des flux de données distincts. Désactiver le consentement à l’entraînement des modèles ne désactive pas automatiquement les transferts de données requis par une autre fonctionnalité cloud.
ZCode a-t-il corrigé le problème de capture du dépôt ?
ZCode affirme que le problème a été corrigé. Le chercheur initial a signalé que l’ancien mécanisme de téléversement distant était absent de la version 3.14.0, tandis que la documentation actuelle de Repo Wiki exclut explicitement .git, des dépendances, des sorties de compilation, des caches et de plusieurs catégories de fichiers sensibles du contexte du modèle Wiki.
Un agent de codage IA open source est-il automatiquement privé ?
Non. L’open source améliore l’auditabilité, mais la confidentialité dépend toujours des fichiers lus par l’outil, des données qui quittent l’appareil, des services cloud qui les reçoivent, de la durée de leur conservation et de la personne qui contrôle les clés de chiffrement.
Produits recommandés
Centre Tech & IA
Plus à lire
Pourquoi la prise en charge des embeddings multilingues améliore-t-elle la recherche privée à domicile en 2026 ?
Découvrez comment les espaces partagés permettent la recherche multilingue, pourquoi l’équilibre de l’entraînement est important et dans quels cas les termes exacts et les...
Pourquoi la compression des bases de données vectorielles devient-elle plus importante pour l’IA domestique en 2026 ?
Découvrez comment la quantification réduit la taille des vecteurs, pourquoi la localité mémoire peut accélérer la recherche, et où la compression diminue le rappel...
Pourquoi la récupération de l’IA à domicile s’oriente-t-elle vers des points de contrôle coordonnés des modèles et des index en 2026 ?
Découvrez pourquoi les sauvegardes créent un état d’IA composé de versions différentes, comment les points de contrôle coordonnés rétablissent la cohérence et quand une...
