Incidente dello snapshot Git di ZCode: cosa possono vedere, caricare e ricordare gli agenti di codifica AI

L'incidente del caricamento del repository di ZCode va oltre un singolo strumento di codifica. Espone una questione di sicurezza a cui gli sviluppatori devono sempre più spesso rispondere prima di concedere a un agente IA l'accesso a un progetto: “accesso al repository” significa il file attuale, l'albero di lavoro o anni di cronologia Git?

Questa distinzione è importante perché .git può contenere informazioni non più visibili nella codebase attuale, inclusi segreti eliminati, vecchie versioni del codice sorgente, reflog, risorse LFS e cronologia dei branch locali. ZCode afferma che il comportamento di caricamento interessato è stato corretto, ma l'incidente lascia una lezione duratura: gli agenti di codifica IA hanno bisogno di confini espliciti per i dati, non solo dell'autorizzazione ad “accedere al repository”.

Che cosa è successo realmente con ZCode?

Il 18 settembre 2026, lo sviluppatore ferstar ha pubblicato un'indagine di reverse engineering su ZCode 3.12.3 dopo aver notato file insolitamente grandi nella directory dei dati locali dell'applicazione.

Secondo l'indagine originale, il client creava snapshot crittografati dell'area di lavoro che potevano includere i file sorgente nonché .git, gli oggetti Git LFS, i reflog e i metadati del repository. Il client conteneva inoltre una pipeline per ottenere le credenziali di caricamento e inviare archivi crittografati ad Alibaba Cloud OSS.

Successivamente, ZCode ha riconosciuto i caricamenti di dati dei repository associati all'indicizzazione delle codebase e a Repo Wiki, si è scusato, ha dichiarato che il comportamento era stato corretto e ha annunciato l'intenzione di sottoporsi a una revisione open source e da parte di terze parti. La copertura contemporanea ha riprodotto i punti principali della risposta di ZCode.

Questa è la prima importante lacuna informativa da colmare: l'incidente è stato reale, ma alcuni riepiloghi diventati virali hanno sovrastimato ciò che è stato trasferito con successo.

Il repository privato da 313 MB è stato effettivamente caricato?

No.

Lo snapshot del progetto commerciale conteneva circa 42.000 file e ha prodotto un archivio crittografato di circa 313 MB. Secondo l'aggiornamento del ricercatore del 19 settembre, è rimasto in locale in attesa stato dopo 564 tentativi falliti perché superava il limite di caricamento. ([blog.ferstar.org](https://blog.ferstar.org/en/posts/zcode-silent-workspace-snapshot-upload/))

Un altro repository pubblico più piccolo è stato effettivamente trasmesso al servizio. Conteneva 538 file e ha prodotto un payload crittografato molto più piccolo.

La conclusione corretta non è quindi “è stato caricato ogni repository ZCode”. È che il vecchio client conteneva un meccanismo funzionale di caricamento dei repository, il cui successo effettivo dipendeva dallo snapshot.

Perché la directory `.git` è la parte più importante di questo incidente

Nello snapshot di grandi dimensioni del ricercatore, la maggior parte del payload non era costituita dal codice sorgente corrente.

Ciò significa che circa l'86,6% dello snapshot proveniva da .git. ([blog.ferstar.org](https://blog.ferstar.org/en/posts/zcode-silent-workspace-snapshot-upload/))

Questo cambia completamente l'interpretazione della sicurezza.

Un agente IA che legge l'albero dei sorgenti corrente può vedere ciò che lo sviluppatore sceglie intenzionalmente di mantenere oggi. Accedere alla cronologia Git può rivelare ciò che lo sviluppatore pensava di aver già rimosso.

La possibile esposizione storica include:

• file sorgente eliminati
• vecchie chiavi API o token
• endpoint interni precedenti
• funzionalità abbandonate
• configurazione storica
• attività dei branch locali
• stati presenti solo nel reflog
• asset LFS storici di grandi dimensioni

La documentazione di Git sul reflog spiega che i reflog registrano i valori precedenti dei riferimenti locali. Questi record possono esistere localmente anche quando la cronologia corrispondente non è mai stata inviata a un repository remoto.

Questo ci fornisce una regola di sicurezza utile:

“Leggi il mio progetto” e “leggi la mia cronologia Git” dovrebbero essere permessi distinti.

Perché i segreti eliminati possono ancora esistere dopo la loro rimozione dal codice

Eliminare una credenziale dal file più recente non significa necessariamente eliminarla da Git.

Uno sviluppatore può includere accidentalmente una chiave API in un commit, rimuoverla nel commit successivo e vedere un file corrente completamente pulito. Il blob precedente può comunque rimanere raggiungibile attraverso la cronologia del repository.

La guida di GitHub sulla rimozione dei dati sensibili raccomanda esplicitamente di revocare o ruotare le credenziali esposte prima di riscrivere la cronologia.

L'ordine è importante:

1. Invalida la credenziale.
2. Rimuovi la cronologia sensibile quando opportuno.
3. Impedisci che il segreto venga nuovamente incluso in un commit.

Per gli agenti di programmazione basati sull'IA, ciò significa che una funzionalità consapevole della cronologia può accedere a dati che una normale visualizzazione dell'editor non espone più.

Questo spiega anche perché un agente di sola lettura non è automaticamente a basso rischio. L'accesso in sola lettura può comunque divulgare informazioni preziose se l'ambito del suo filesystem è troppo ampio o se il contenuto recuperato viene inviato a un modello remoto.

Contesto del modello, telemetria, addestramento e caricamenti dei repository non sono la stessa cosa

Un'altra lezione importante è che un singolo interruttore per la “privacy” non può rappresentare ogni tipo di flusso di dati che uno strumento di programmazione IA può avere.

La versione ZCode interessata è importante perché il ricercatore ha riferito che la disattivazione dell'opzione di ottimizzazione/addestramento non disattivava la pipeline separata degli snapshot. Il rapporto sosteneva inoltre che, in quella versione, l'interruttore Repository Snapshot Indexing non impediva i tentativi di impacchettamento e caricamento. ([blog.ferstar.org](https://blog.ferstar.org/en/posts/zcode-silent-workspace-snapshot-upload/))

Questo porta a una regola che si applica ben oltre ZCode:

“Non addestrare sui miei dati” non significa “non trasmettere i miei dati”.

Un modello cloud ha comunque bisogno del contesto per l'inferenza. La telemetria può viaggiare attraverso un altro endpoint. La sincronizzazione può conservare un'altra copia. L'indicizzazione del repository può avere un proprio percorso dati.

La stessa distinzione emerge quando un agente IA locale utilizza strumenti cloud: la privacy dipende dai dati esatti che attraversano il confine, non semplicemente dal luogo in cui viene eseguito il processo principale dell'agente.

La crittografia non risponde alla domanda più importante sulla privacy

Lo snapshot ZCode interessato è stato crittografato prima del caricamento.

Il rapporto di reverse engineering descrive la crittografia AES-256-CTR per l'archivio e l'incapsulamento RSA-OAEP-SHA256 per la chiave simmetrica. La chiave pubblica RSA era fornita dal servizio, mentre la corrispondente chiave privata non era memorizzata localmente. ([blog.ferstar.org](https://blog.ferstar.org/en/posts/zcode-silent-workspace-snapshot-upload/))

Protegge i dati in modo diverso dalla crittografia end-to-end controllata dall'utente.

Quindi “il repository è stato crittografato” è un'affermazione incompleta.

La domanda più importante è:

chi può decrittografarlo?

Questo stesso principio si applica al RAG privato, al backup cloud, alla memoria IA e a qualsiasi sistema che sostenga che i dati siano protetti perché crittografati.

Di quanto accesso al repository ha effettivamente bisogno un agente di programmazione?

Gli agenti di programmazione hanno legittimamente bisogno di più contesto rispetto al completamento automatico tradizionale. Un refactoring che riguarda l'intero repository può richiedere molti file. Un agente di debugging può aver bisogno di test, metadati delle dipendenze, stato di Git e output della build.

Ma “l'agente potrebbe aver bisogno di un contesto ampio” non implica che “ogni funzionalità debba ricevere ogni byte del repository”.

Questo è una versione incentrata sull'accesso ai dati dello stesso principio usato in un confine di fiducia per l'esecuzione degli strumenti: la capacità del modello di richiedere qualcosa non dovrebbe concedere automaticamente l'autorità di accedere o esportare tutto ciò che si trova nelle vicinanze.

Per gli agenti di programmazione, servono due confini indipendenti:

• Confine delle azioni: cosa può modificare o eseguire l'agente?
• Confine dei dati: cosa può leggere o inviare l'agente?

Un agente senza autorizzazioni di scrittura può comunque creare una grave esposizione della privacy se le sue autorizzazioni di lettura e di rete sono senza restrizioni.

Cosa ha cambiato ZCode dopo l'incidente?

L'incidente non dovrebbe essere descritto come se fosse noto che lo stesso comportamento esista nelle versioni attuali di ZCode.

In un'ispezione successiva di ZCode 3.14.0, il ricercatore ha riferito che il precedente file sidecar di upload era stato rimosso e che il vecchio endpoint per le credenziali restituiva 404. Il percorso esaminato manteneva la funzionalità di checkpoint locale senza il precedente meccanismo di upload remoto. ([blog.ferstar.org](https://blog.ferstar.org/en/posts/zcode-silent-workspace-snapshot-upload/))

Anche l'attuale documentazione di Repo Wiki descrive un confine dei dati molto più ristretto.

Indica che il contesto di Wiki esclude:

• .git
• directory delle dipendenze
• output della build
• cache
• stato di runtime locale
• supportato .gitignore esclusioni
• file di configurazione potenzialmente sensibili
• destinazioni dei link simbolici

L'output di Repo Wiki è documentato come dati locali dell'applicazione, anziché come contenuto riscritto nel repository.

Questo è sostanzialmente diverso dal comportamento degli snapshot segnalato nella versione 3.12.3.

L'open source è sufficiente per rendere privato un agente di programmazione?

No.

L'open source può rendere un client più facile da sottoporre ad audit, ma un'applicazione open source può comunque inviare il codice sorgente a modelli cloud, caricare dati di telemetria, sincronizzare lo stato o affidarsi a uno spazio di archiviazione controllato dal provider.

La checklist più utile è:

Per questo una architettura IA privata è definita più dal flusso dei dati che dal fatto che la licenza del software sia open source.

Come dovrebbero verificare gli sviluppatori un nuovo agente di programmazione IA?

Gli sviluppatori non devono sottoporre a reverse engineering ogni app, ma un nuovo agente non dovrebbe ricevere come primo ambiente di test un repository commerciale sensibile.

1. Leggere la documentazione sulla gestione dei dati. Distinguere tra inferenza, telemetria, addestramento, indicizzazione, sincronizzazione e backup.
2. Controllare le regole di esclusione. Cercare in particolare .git, .env, file ignorati, dipendenze, credenziali e link simbolici.
3. Iniziare con un repository usa e getta. Usare prima codice non sensibile.
4. Ispezionare lo spazio di archiviazione dell'app locale. Cache o snapshot insolitamente grandi possono rivelare un ambito nascosto dei dati.
5. Monitorare il traffico in uscita. I log del firewall, del DNS, del proxy o del router possono identificare i servizi remoti.
6. Usare file canary innocui. Verificare se file non correlati entrano nel contesto del modello o del caricamento.
7. Concedere prima le autorizzazioni più limitate. Ampliarle solo quando un'attività specifica lo richiede.

È anche qui che la progettazione degli agenti con privilegi minimi è utile, purché “sola lettura” sia combinata con percorsi ristretti e dati in uscita controllati, anziché con una visibilità illimitata sul repository.

Cosa dovrebbe fare diversamente un agente di programmazione local-first

Local-first non significa che ogni attività debba essere eseguita offline.

Significa che, per impostazione predefinita, i dati locali rimangono all'interno del perimetro di fiducia locale e la trasmissione esterna è deliberata, non incidentale.

Questo principio è più ampio della programmazione. Un flusso di lavoro IA veramente locale deve mantenere localmente il percorso dei dati critici dall'inizio alla fine; un modello installato localmente non basta se embedding, indicizzazione, autenticazione o elaborazione dei file dipendono silenziosamente da un servizio remoto.

Per i sistemi ibridi, l'approccio più solido consiste nel mantenere i file privati dietro un servizio locale ed esporre agli strumenti remoti approvati solo il contesto minimo necessario. È lo stesso approccio usato nella progettazione di un agente che usa i servizi cloud senza esporre l'intero file system locale.

La lezione più importante: l'accesso al repository è un'autorizzazione di sicurezza

La lezione duratura di ZCode non è «non usare mai gli agenti di coding cloud». È che l'accesso ai repository è diventato di per sé un'autorizzazione di sicurezza.

Un moderno agente di coding può combinare:

• lettura dell'intero progetto
• consapevolezza di Git
• esecuzione nel terminale
• accesso al browser
• modelli remoti
• attività in background
• memoria a lungo termine
• modifica autonoma dei file

Ciò significa che gli sviluppatori devono esaminare più di quali comandi un agente può eseguire.

Devono anche chiedersi:

• Quali file può osservare?
• Quanto indietro nella cronologia può vedere?
• Quali di questi dati lasciano il dispositivo?
• Quale servizio lo riceve?
• Per quanto tempo viene conservato?
• Chi può decrittografarlo?

Per gli agenti di coding basati sull'IA, la privacy non riguarda più semplicemente il fatto che il modello venga addestrato sul tuo codice. Riguarda il fatto che il perimetro dei dati dell'agente corrisponda effettivamente all'attività che gli hai chiesto di svolgere.