Il caricamento della cronologia Git di ZCode trasforma una comodità di programmazione in un problema di fiducia

Secondo quanto riferito, ZCode ha caricato un intero spazio di lavoro di sviluppo da 345 MB, inclusa la relativa cronologia Git, nonostante impostazioni che sembravano limitare la raccolta di dati. Il segnalato caricamento della cronologia Git di ZCode non era limitato ai file selezionati per un prompt AI. Includeva oggetti del repository, reflog e file di grandi dimensioni memorizzati nella cache che potevano conservare anni di lavoro ingegneristico privato.

Un'indagine tecnica pubblicata il 18 settembre ha ricostruito il comportamento attraverso l'applicazione desktop chiusa di ZCode. Secondo tale analisi, il client creava checkpoint crittografati dello spazio di lavoro e li trasferiva ad Alibaba Cloud Object Storage Service mentre l'utente era autenticato.

La scoperta resta un'affermazione di reverse engineering di terze parti, non una divulgazione verificata in modo indipendente da Z.ai. Al momento della pubblicazione, i materiali ufficiali disponibili non spiegavano chiaramente l'ambito del caricamento segnalato, la conservazione dei checkpoint o il modo in cui gli utenti potessero impedirlo.

Questa lacuna di verifica è parte della vicenda. ZCode promuove i modelli GLM con un agente progettato per comprendere uno spazio di lavoro, eseguire comandi e riprendere attività di lunga durata. Tuttavia, un modello a pesi aperti non rende trasparente l'applicazione desktop che lo circonda.

Il conflitto centrale non è quindi ZCode contro un altro assistente di programmazione. Riguarda i controlli della privacy visibili del prodotto rispetto al comportamento attribuito al suo sistema di checkpoint nascosto.

Cosa ha rilevato il rapporto sul caricamento della cronologia Git di ZCode

L'indagine sostiene che ZCode abbia acquisito un archivio del repository, non soltanto il codice necessario per una singola richiesta al modello.

Il ricercatore ha esaminato uno spazio di lavoro commerciale privato contenente 42.411 file. La directory originale occupava circa 345 MB, mentre il checkpoint crittografato di ZCode era di circa 313 MB.

I contenuti segnalati erano particolarmente rivelatori. Circa 196,1 MB provenivano dalla directory .git/lfs, dove Git Large File Storage può memorizzare nella cache grandi risorse del progetto. Altri 102,2 MB provenivano da .git/objects, il database sottostante di Git relativo a contenuti dei file, alberi delle directory e commit.

I reflog aggiungevano circa 0,6 MB. I file sorgente correnti, la configurazione e la documentazione rappresentavano circa 46,2 MB, ovvero il 13,4 percento del materiale misurato.

In quella singola istantanea, la directory .git rappresentava l'86,6 percento dei dati archiviati. Questo non stabilisce una media per tutte le installazioni di ZCode. Mostra però perché definire l'evento un normale caricamento di codice minimizza l'ambito segnalato.

Il resoconto originale afferma che ZCode ha creato il checkpoint nei propri dati applicativi locali e ha lasciato un manifest in testo semplice accanto all'archivio crittografato. Secondo quanto riferito, tale manifest esponeva il percorso assoluto dello spazio di lavoro interessato.

Secondo il reverse engineering, ZCode ha richiesto credenziali di caricamento a un servizio Z.ai. La risposta includeva una chiave oggetto, un modulo di caricamento firmato, un limite di dimensione e una chiave pubblica RSA.

Il client avrebbe compresso lo spazio di lavoro, crittografato il contenuto con AES-256-CTR e protetto la chiave simmetrica mediante RSA-OAEP-SHA256. Avrebbe quindi inviato direttamente l'oggetto crittografato a un endpoint di archiviazione Aliyun.

Secondo quanto riferito, una callback ha informato il backend di Z.ai dopo il completamento del trasferimento. Se questa ricostruzione è corretta, il caricamento era un flusso applicativo progettato, non una richiesta al modello contenente accidentalmente troppo contesto.

La crittografia non risolve il problema della divulgazione. Protegge i dati dagli osservatori tra il computer e il servizio di archiviazione, ammesso che l'implementazione sia corretta. Non impedisce al gestore del servizio previsto di accedere alle informazioni.

Il rapporto afferma che la corrispondente chiave privata RSA rimaneva sotto il controllo del server. Di conseguenza, l'utente che aveva fornito il repository non poteva decrittografare e ispezionare il checkpoint memorizzato sullo stesso computer.

Questa distinzione è importante. “Crittografato” può sembrare sinonimo di “non disponibile al fornitore”, ma le due affermazioni non sono equivalenti. La crittografia protegge i dati in base a chi controlla le chiavi pertinenti.

Il rapporto sostiene inoltre che due impostazioni di privacy visibili non abbiano fermato la creazione o il trasferimento dei checkpoint. Tale accusa non è stata confermata da un audit indipendente del prodotto, e un partecipante di Hacker News ha riferito di non aver trovato alcuna directory di checkpoint corrispondente.

La differenza potrebbe riflettere versioni del prodotto, sistemi operativi, stati dell'account, distribuzioni graduali o l'uso di specifiche funzionalità. Potrebbe anche indicare che il caso originale non si applica a tutti gli utenti.

Z.ai deve chiarire queste condizioni. Fino ad allora, la descrizione più prudente è che i ricercatori abbiano documentato il comportamento in almeno un ambiente testato, mentre la sua diffusione effettiva resta sconosciuta.

Perché un'intera directory .git è più sensibile del codice attuale

Un repository Git contiene la memoria di un progetto, incluse informazioni che non compaiono più nei suoi file attuali.

Gli sviluppatori descrivono spesso .git come “cronologia”, ma contiene più del risultato di git log. Memorizza oggetti, riferimenti, informazioni sui branch, configurazione, reflog e altri metadati del repository.

Git è fondamentalmente un database indirizzabile tramite contenuto. I suoi oggetti blob conservano il contenuto dei file, gli oggetti tree descrivono gli stati delle directory e gli oggetti commit collegano le istantanee nella cronologia.

Il modello a oggetti di Git ufficiale spiega come questi elementi rimangano all'interno di .git/objects. Un'applicazione che copia quella directory può ricevere molto più dei file visibili nell'albero di lavoro.

Si consideri uno sviluppatore che inserisce per errore una credenziale API in un commit il lunedì e la rimuove il martedì. Il file corrente non mostra più la credenziale, ma l'oggetto precedente può restare raggiungibile tramite la cronologia del repository.

Eliminare l'ultima copia non è sufficiente. Le indicazioni di GitHub sulla rimozione di dati sensibili invitano gli sviluppatori prima a revocare le credenziali esposte, quindi a considerare una riscrittura coordinata della cronologia.

Lo stesso problema riguarda certificati privati, hostname interni, identificativi dei clienti, file di ambiente e credenziali incorporate nelle fixture di test. Un repository può anche conservare architetture abbandonate, correzioni di sicurezza, prodotti non rilasciati e materiale relativo alle licenze.

I reflog estendono il rischio. Registrano gli spostamenti dei riferimenti locali e possono preservare percorsi di accesso a commit che non sono più visibili su un branch condiviso.

I branch locali possono rivelare iniziative che non sono mai state inviate al server. I messaggi di commit possono nominare clienti, vulnerabilità, dipendenti o incidenti interni. La configurazione del repository può identificare remote private e domini dell'infrastruttura.

Git LFS introduce un'altra categoria. La sua cache può contenere file di progettazione, dataset, media, modelli pacchettizzati o altri file binari che gli sviluppatori ragionevolmente ritengono esterni al contesto immediato di un assistente.

La componente LFS segnalata da 196,1 MB non era dunque materiale voluminoso irrilevante. Potrebbe rappresentare parte del materiale meno testuale e più sensibile dal punto di vista commerciale del progetto.

Un agente di programmazione può legittimamente avere bisogno di un ampio accesso locale. Non può effettuare il refactoring di un'applicazione complessa senza leggere moduli correlati, eseguire test o comprendere le dipendenze.

Questa autorizzazione locale non implica automaticamente l'autorizzazione a creare una copia cloud durevole di tutto ciò a cui il processo può accedere. Leggere un file per un'attività richiesta, inviare contesto selezionato per l'inferenza e archiviare l'intero repository sono operazioni distinte.

Ecco perché l'affermazione sul caricamento della cronologia Git di ZCode è più grave della semplice osservazione che gli assistenti cloud di programmazione elaborino codice. La controversia riguarda ambito, persistenza, controllo e divulgazione.

Uno sviluppatore potrebbe approvare consapevolmente una richiesta al modello contenente una funzione e le sue dipendenze. Lo stesso sviluppatore potrebbe rifiutare il caricamento di una cache LFS, credenziali eliminate, branch inattivi e anni di oggetti di commit.

Gli utenti aziendali affrontano ulteriori preoccupazioni. Un repository può contenere materiale disciplinato da contratti con i clienti, termini di escrow del codice sorgente, controlli sulle esportazioni, norme sulla residenza dei dati o policy di accesso dei dipendenti.

La domanda rilevante non è semplicemente se sia stata utilizzata la crittografia. I team di sicurezza devono sapere cosa è stato raccolto, dove è stato archiviato, chi possedeva le chiavi, per quanto tempo è rimasto conservato e come funzionava l'eliminazione.

I controlli della privacy e i checkpoint sembrano raccontare storie diverse

La preoccupazione più acuta è il divario segnalato tra ciò che gli utenti potevano controllare e ciò che l'applicazione avrebbe fatto.

La documentazione ufficiale di ZCode descrive un agente che comprende lo stato dello spazio di lavoro, i riferimenti ai file, le attività e il contesto del branch Git. La sua documentazione sull'agente presenta inoltre il recupero dello stato come parte del supporto alle attività di sviluppo più lunghe.

Il checkpointing può avere uno scopo legittimo. Un agente che modifica decine di file necessita di un modo per recuperare dopo una modifica non riuscita, confrontare stati o ripristinare lavoro interrotto da un arresto anomalo.

Questa funzione non richiede che il checkpointing sia invisibile. Né stabilisce che ogni parte di .git debba essere inclusa in un archivio remoto.

Una progettazione che preservi la privacy potrebbe escludere per impostazione predefinita gli oggetti Git e le cache LFS. Potrebbe pubblicare il manifest esatto dell'archivio prima del trasferimento, mantenere i checkpoint locali o richiedere un'approvazione esplicita prima della sincronizzazione cloud.

Potrebbe anche fornire una policy organizzativa che blocchi le istantanee remote. Gli amministratori potrebbero applicare esclusioni a livello di repository e confermarne l'effetto tramite un log di audit.

L'indagine sostiene invece che il processo di archiviazione di ZCode operasse al di fuori del ciclo di strumenti visibile dell'agente. Secondo quanto riferito, gli strumenti elencati dell'agente non contenevano alcuna azione di istantanea o caricamento che gli utenti potessero approvare.

Questa architettura spiegherebbe perché le autorizzazioni sui comandi non siano riuscite a fermare il trasferimento. Un componente sidecar a livello host può funzionare indipendentemente dagli strumenti del modello, anche quando l'utente limita l'esecuzione della shell o la modifica dei file.

Espone inoltre un punto cieco nelle attuali interfacce degli agenti. Le richieste di autorizzazione si concentrano di solito su azioni evidenti, come eseguire un comando, modificare un file o aprire un indirizzo di rete.

I servizi in background ricevono meno attenzione. Possono indicizzare cartelle, raccogliere dati diagnostici, sincronizzare sessioni o creare artefatti di ripristino senza apparire nella conversazione.

Qui diventa importante la distinzione tra inferenza e sincronizzazione. L'invio di codice selezionato a un modello cloud è sufficientemente visibile perché la maggior parte degli utenti se lo aspetti da un assistente supportato dal cloud.

Copiare il database del repository sottostante per rollback o indicizzazione è un secondo flusso di dati. Richiede una spiegazione dedicata, controlli sull'ambito, regole di conservazione e un'interfaccia di eliminazione.

L'attuale informativa sulla privacy di ZCode afferma che i dati personali possono essere conservati secondo necessità per fornire servizi, adempiere obblighi, tutelare legittimi interessi commerciali e migliorare sicurezza o stabilità. Afferma inoltre che la conservazione varia in base al tipo di dati, alla sensibilità, allo scopo e ai requisiti legali.

Queste dichiarazioni generali non rispondono alle domande sollevate dal rapporto. La policy deve identificare se i checkpoint dello spazio di lavoro siano considerati input dell'utente, dati tecnici o un'altra categoria.

Dovrebbe inoltre spiegare quale regione di archiviazione si applica, se subappaltatori elaborino gli archivi e se l'eliminazione di un account rimuova ogni checkpoint. Gli utenti hanno bisogno di periodi di conservazione concreti o di criteri chiari collegati alla funzionalità pertinente.

Soprattutto, Z.ai dovrebbe documentare se le opzioni sulla privacy influenzano il caricamento dei checkpoint. Un controllo etichettato in riferimento alla raccolta dati può creare una falsa sicurezza se regola l'analisi ma non la sincronizzazione dell'area di lavoro.

Il linguaggio e il posizionamento di un controllo contano quanto la sua implementazione interna. Gli sviluppatori non possono prendere decisioni informate quando flussi di dati sostanzialmente diversi sono raggruppati dietro termini vaghi.

La risposta più efficace possibile da parte di Z.ai sarebbe tecnica, non retorica. Dovrebbe elencare versioni interessate, condizioni di attivazione, esclusioni dagli archivi, endpoint, ruoli della crittografia, periodi di conservazione e procedure di eliminazione.

Dovrebbe inoltre spiegare se il comportamento è cambiato dopo la segnalazione. Senza questo dettaglio, gli utenti non possono stabilire se un aggiornamento ha risolto il problema o ha semplicemente rimosso le prove locali.

I pesi aperti non rendono locale un agente di coding chiuso

L'incidente separa il modello dal software che decide cosa il modello può vedere e cosa lascia la macchina.

I modelli GLM sono centrali nella strategia di Z.ai per gli sviluppatori e alcune versioni sono state distribuite con pesi aperti. Gli sviluppatori possono ispezionare quei file del modello, eseguire versioni compatibili sulla propria infrastruttura ed evitare un endpoint di inferenza ospitato.

ZCode è un livello diverso. È l'harness che seleziona il contesto, invoca gli strumenti, archivia le sessioni, gestisce i checkpoint, si connette ai servizi cloud e si aggiorna autonomamente.

L'harness può determinare gli esiti in materia di privacy anche quando il modello sottostante viene eseguito localmente. Un modello locale non impedisce a un'applicazione circostante di inviare altrove telemetria, indici, cronologia delle sessioni o snapshot di ripristino.

Allo stesso modo, un modello aperto non può rivelare cosa fa un'applicazione Electron chiusa in un processo in background. I ricercatori devono osservare il traffico di rete, ispezionare i bundle dell'applicazione e ricostruire il comportamento dopo il rilascio.

Questo è il conflitto di fiducia principale. L'esperienza di prodotto di ZCode enfatizza la comprensione locale dell'area di lavoro, mentre la segnalazione descrive un meccanismo di acquisizione cloud più ampio di quanto gli sviluppatori si aspettassero.

Anche i concorrenti elaborano dati degli sviluppatori, quindi il confronto corretto non è “ZCode carica il codice mentre ogni altro agente resta locale”. Sarebbe inesatto.

Claude Code, GitHub Copilot, Codex, Cursor e altri strumenti connessi al cloud inviano alcuni input degli utenti e contesti di codice a servizi remoti. Indici dei repository, sessioni degli agenti e ambienti di attività cloud possono creare copie aggiuntive.

Le differenze emergono nella comunicazione e nei controlli. GitHub, ad esempio, documenta le politiche di esclusione dei contenuti e spiega che alcune superfici di Copilot non supportano tali esclusioni.

GitHub documenta inoltre quando l'indicizzazione semantica per repository esterni a GitHub carica dati e afferma che gli amministratori aziendali devono abilitare tale funzionalità. Questi controlli hanno comunque dei limiti, ma gli utenti possono identificare il flusso di dati e valutarlo.

Questo è lo standard che Z.ai deve ora affrontare. Un fornitore non deve promettere che nessun codice lasci mai un computer se il prodotto dipende dall'inferenza cloud.

Deve descrivere con precisione ogni trasferimento. Deve distinguere il contesto temporaneo del prompt da uno snapshot persistente del repository e offrire agli amministratori un controllo applicabile.

Gli harness open source offrono una risposta. Il loro codice può rivelare esclusioni dagli archivi, endpoint di rete e comportamento degli aggiornamenti, mentre revisori indipendenti possono verificare se le impostazioni documentate corrispondono all'implementazione.

L'open source non è una garanzia di sicurezza completa. Pochi utenti ispezionano ogni dipendenza, i binari firmati possono differire dal codice pubblicato e aggiornamenti compromessi possono comunque causare danni.

Anche gli strumenti closed source non sono automaticamente dannosi. Possono essere sottoposti a valutazioni indipendenti, fornire mappe dettagliate dei dati, applicare controlli per tenant e pubblicare comportamenti di rete verificabili.

Tuttavia, l'opacità aumenta il costo della verifica. Quando un'applicazione dispone di ampie autorizzazioni sul filesystem e di esecuzione autonoma, tale costo diventa una considerazione di sicurezza rilevante.

La discussione su Hacker News ha riflesso entrambi i punti di vista. Diversi commentatori hanno considerato qualunque harness di coding chiuso un rischio inaccettabile, mentre altri hanno osservato che gli agenti cloud ricevono intrinsecamente il contesto del progetto.

Un utente ha dichiarato di non essere riuscito a riprodurre la directory dei checkpoint segnalata nonostante usasse ZCode. Altri hanno sostenuto che una sandbox dovrebbe limitare ogni strumento proprietario per sviluppatori, indipendentemente dal fornitore o dal Paese.

Queste reazioni individuano due responsabilità diverse. I fornitori devono divulgare i propri flussi di dati e i team di sviluppo devono limitare ciò a cui un agente può accedere.

Nessuna delle due responsabilità annulla l'altra. Il sandboxing non è consenso e un controllo della privacy non equivale a un contenimento efficace.

Il rischio immediato dipende dal contenuto del repository e dalla versione del prodotto

Le prove giustificano una revisione urgente, ma non dimostrano che ogni utente di ZCode abbia caricato gli stessi dati.

L'esempio documentato riguardava un'area di lavoro e una configurazione dell'applicazione osservata. Le segnalazioni pubbliche non hanno stabilito quante installazioni abbiano creato checkpoint, quando sia iniziato il comportamento o se ogni sistema operativo abbia seguito lo stesso percorso.

Non è inoltre chiaro se gli utenti dovessero abilitare una particolare funzione di ripristino o indicizzazione. Lo stato di autenticazione potrebbe essere rilevante, poiché la segnalazione associa i trasferimenti all'accesso effettuato.

Anche la cronologia delle versioni è importante. Una release successiva potrebbe modificare directory, endpoint, esclusioni o comportamento di pianificazione senza invalidare l'osservazione precedente.

Questa incertezza dovrebbe circoscrivere le affermazioni, non soffocare l'indagine. I team che hanno usato ZCode con repository privati dispongono di elementi sufficienti per condurre una revisione dell'incidente.

Dovrebbero iniziare dall'ambito. Identificare quali sviluppatori hanno installato ZCode, quali versioni hanno eseguito, quando hanno effettuato l'accesso e quali repository erano accessibili in quei periodi.

Successivamente, ispezionare i log di endpoint, proxy, DNS, firewall e rilevamento degli endpoint per comunicazioni con i servizi Z.ai e Aliyun. I file di checkpoint locali possono aiutare, ma la loro assenza non dimostra in modo conclusivo che non sia avvenuto alcun trasferimento.

Le organizzazioni dovrebbero preservare le prove prima di disinstallare o aggiornare l'applicazione. Un aggiornamento può modificare log, percorsi di archiviazione o binari che altrimenti aiuterebbero gli investigatori a ricostruire l'attività.

I team di sicurezza dovrebbero presumere che ogni credenziale sottoposta a commit nella cronologia di un repository esposto richieda una revisione. GitHub raccomanda di ruotare una credenziale divulgata, poiché rimuoverla dai file più recenti non la neutralizza.

La risposta dovrebbe restare proporzionata. Non ruotare ogni credenziale aziendale solo perché uno sviluppatore ha installato ZCode. Mappare prima i repository, poi cercare nelle loro cronologie e convalidare quali segreti sono rimasti attivi.

I proprietari dei repository dovrebbero inoltre esaminare il materiale sensibile non costituito da segreti. I vecchi commit potrebbero contenere dati dei clienti, dettagli sulle vulnerabilità, endpoint interni, risorse con licenza o trattative che richiedono una revisione legale.

Se il repository conteneva dati regolamentati o soggetti a restrizioni contrattuali, i team legali e di conformità dovrebbero valutare gli obblighi di notifica. La risposta dipende dalla giurisdizione, dal linguaggio contrattuale, dalle prove di trasferimento confermate e dai dati coinvolti.

Gli sviluppatori che continuano a testare ZCode dovrebbero isolarlo. Una macchina virtuale o un container dedicati possono limitare il filesystem visibile, sebbene rete e directory montate richiedano comunque una configurazione accurata.

Usare un repository usa e getta che non contenga credenziali reali né cronologia commerciale. Evitare di montare una directory home, una cartella SSH, configurazioni cloud, credenziali di pacchetti o alberi di codice sorgente non correlati.

Le restrizioni sul filesystem possono bloccare le directory dei checkpoint, ma sono una difesa fragile. Percorsi e processi possono cambiare con gli aggiornamenti e negare le scritture può disabilitare il comportamento di ripristino o compromettere l'applicazione.

I controlli di rete offrono un ulteriore livello. I team possono limitare le destinazioni in uscita e registrare i tentativi di connessione, anche se bloccare i servizi richiesti potrebbe rendere il prodotto inutilizzabile.

Un modello più sicuro a lungo termine usa allowlist esplicite. L'agente riceve un checkout ristretto del progetto, credenziali temporanee e solo i servizi necessari per l'attività.

Questo approccio è utile in tutti i flussi di lavoro di ingegneria, non solo con ZCode. Qualsiasi assistente autonomo con accesso al filesystem e alla shell dovrebbe essere trattato come una dipendenza di sviluppo privilegiata.

L'obiettivo non è dimostrare un intento malevolo sulla base di prove incomplete. È ridurre le conseguenze di comportamenti non documentati.

Tre segnali mostreranno se Z.ai ha risolto il divario di fiducia

Il prossimo test sarà verificare se Z.ai trasformerà un flusso di dati non documentato in una funzionalità di prodotto circoscritta, visibile e verificabile.

Il primo segnale è una risposta pubblica dettagliata. Z.ai dovrebbe confermare o contestare il caricamento segnalato della cronologia Git di ZCode, identificare le versioni interessate e spiegare quale stato del prodotto lo ha attivato.

Una dichiarazione utile affronterebbe direttamente i contenuti dell'archivio misurati. Dovrebbe indicare se fossero inclusi .git/objects, .git/lfs, reflog, file ignorati e configurazione globale.

Se Z.ai pubblica solo un'assicurazione generale sul fatto che i dati siano crittografati, la preoccupazione centrale rimane. Secondo quanto riferito, l'azienda controllava la chiave di decrittografia, quindi la crittografia in transito non risponde alle domande sull'accesso o sulla conservazione.

Il secondo segnale è un controllo dei checkpoint applicabile. ZCode necessita di un'impostazione che interrompa gli snapshot remoti, possa essere gestita da un'organizzazione e sia indipendente dalle preferenze relative ad analisi o addestramento dei modelli.

Gli utenti dovrebbero poter verificare l'impostazione attraverso i log o un evento di rete documentato. L'applicazione dovrebbe mostrare ciò che intende caricare prima del primo trasferimento.

Le esclusioni predefinite dovrebbero rimuovere .git, cache LFS, file ignorati, credenziali e comuni posizioni dei segreti. Gli utenti potrebbero acconsentire al caricamento di ulteriore cronologia quando un'attività lo richiede davvero.

Un'opzione di ripristino esclusivamente locale risolverebbe gran parte della tensione. I checkpoint possono supportare il rollback senza trasformarsi in archivi cloud, in particolare quando agente e modello vengono eseguiti sulla stessa macchina.

Il terzo segnale è una riproduzione indipendente. I ricercatori devono testare una release corrente sui sistemi operativi supportati, con account nuovi ed esistenti e diverse configurazioni della privacy.

Questo lavoro dovrebbe chiarire se il comportamento originario fosse universale, condizionale o già modificato. Dovrebbe inoltre verificare se l'eliminazione dei checkpoint tramite il prodotto rimuova ogni copia lato server.

Una valutazione di terze parti rafforzerebbe la risposta di Z.ai, soprattutto se il valutatore pubblicasse ambito e metodi. Catture di pacchetti e manifesti degli archivi riproducibili sarebbero più preziosi di un linguaggio generico sulle certificazioni.

Per i team di sviluppo, la lezione va oltre una singola applicazione. Inventariare gli agenti di coding come componenti della supply chain software, documentarne gli endpoint e rivederne i flussi di dati prima di concedere l'accesso ai repository privati.

Porre cinque domande dirette: Cosa può leggere l'agente? Cosa trasmette? Cosa persiste da remoto? Chi detiene le chiavi? Quale controllo interrompe ogni trasferimento?

Se un fornitore non riesce a rispondere a queste domande, limitare l'agente ad ambienti usa e getta finché non sarà in grado di farlo. Se una risposta si basa soltanto su “crittografato”, chiedere chi può decrittografarlo.

Il caricamento segnalato della cronologia Git di ZCode non ha ancora stabilito l'esposizione di ogni utente né dimostrato l'uso improprio di alcun archivio. Ha però stabilito una discrepanza credibile che richiede una risposta precisa.

Z.ai può ridurre tale divario pubblicando il meccanismo, correggendo le impostazioni predefinite, offrendo un vero interruttore di disattivazione e supportando verifiche indipendenti. Fino ad allora, gli sviluppatori dovrebbero trattare l'area di lavoro visibile di ZCode come il confine minimo possibile della raccolta, non quello massimo.