Grok Build diventa open source dopo il caso privacy: cosa è successo davvero

Se negli ultimi giorni hai usato Grok Build, l’agente di coding da terminale di xAI, vale la pena che tu dedichi cinque minuti a questa storia. Non perché sia l’ennesima polemica social attorno a una società di Elon Musk, ma perché il caso ha messo a nudo un problema che riguarda chiunque affidi il proprio codice sorgente a un assistente basato su intelligenza artificiale. In pochi giorni si è passati dalla scoperta che lo strumento caricava interi repository sui server dell’azienda, alla cancellazione dei dati, fino all’apertura completa del codice sorgente sotto licenza Apache 2.0. E poi, con un tempismo quasi beffardo, alla segnalazione di una vulnerabilità trovata meno di ventiquattro ore dopo la pubblicazione del repository.

Che cosa faceva Grok Build senza dirlo agli utenti

Il punto di partenza è l’analisi di un ricercatore che pubblica con lo pseudonimo cereblab, condotta sulla versione 0.2.93 del client. L’osservazione è tecnicamente semplice e per questo difficile da contestare: mentre lavorava, Grok Build non si limitava a inviare al modello i file necessari a completare il compito richiesto, ma spediva l’intero repository Git tracciato, cronologia dei commit compresa, verso un bucket di Google Cloud Storage gestito da xAI e chiamato grok-code-session-traces.

La differenza tra i due flussi è il dettaglio che rende la faccenda evidente. Su un repository da 12 GB contenente file che il modello non aveva mai letto, il traffico diretto all’endpoint conversazionale ammontava a circa 192 KB, mentre il canale di archiviazione ne trasferiva 5,10 GiB. Parliamo di uno scarto di circa 27.800 volte tra quello di cui il modello aveva bisogno e quello che lasciava effettivamente la macchina. L’upload avveniva in settantatré blocchi da circa 75 MB ciascuno, tutti accettati dal server.

Per dimostrare che non si trattasse di un artefatto della misurazione, il ricercatore aveva piazzato nel repository un file esca con un identificatore unico, un file che all’agente era stato esplicitamente detto di non aprire. Ricostruendo il pacchetto Git intercettato, quel file è tornato fuori identico, insieme alla cronologia completa del progetto. La prova è stata replicata su un secondo repository indipendente.

Il problema delle credenziali e dell’impostazione che non serviva a niente

C’è un secondo aspetto, più banale ma altrettanto fastidioso. Quando Grok Build leggeva un file, il contenuto finiva nel turno di conversazione con il modello. Un file di ambiente tracciato, il classico .env dove finiscono chiavi API e password dei database, è stato trasmesso senza alcuna redazione, con i valori in chiaro. Nel test si trattava di credenziali finte, quindi non è uscito nulla di reale, ma il comportamento resta il problema.

Il dettaglio che più dovrebbe farti riflettere riguarda però l’impostazione che qualsiasi sviluppatore avrebbe cercato per proteggersi. Con l’opzione di contributo al miglioramento del modello disattivata, il caricamento del repository avveniva comunque, e il server continuava a dichiarare attivo il flag relativo all’invio delle tracce. La ragione è che si tratta di due controlli distinti: uno decide se i tuoi dati vengono usati per addestrare il modello, l’altro decide se il tuo codice esce dal computer. All’utente ne era esposto soltanto uno.

Va detto con onestà che qualunque agente di coding in cloud deve per forza inviare del codice a un modello remoto, altrimenti non potrebbe funzionare. Il primo canale, insomma, è fisiologico. Spedire l’intero repository tracciato con tutta la sua storia è un confine molto più ampio, e nel confronto tra strumenti condotto dallo stesso ricercatore né Claude Code né Codex inviavano pacchetti dell’intero repository. Grok Build era l’anomalia. Questo non significa che gli altri siano strumenti locali, perché inviano comunque i file che aprono, ma la raccolta indiscriminata dello spazio di lavoro era una caratteristica specifica di un solo prodotto.

La correzione è arrivata dal server, non da un aggiornamento

Il 13 luglio lo stesso identico binario 0.2.93 ha smesso di effettuare richieste di archiviazione. Il ricercatore ha ripetuto la prova sei volte senza osservare più alcun caricamento, e il server ha iniziato a restituire i flag che disabilitano l’invio del codice. Il particolare rilevante è che il client non era cambiato: a cambiare erano le impostazioni restituite dal server. Si è trattato quindi di un interruttore remoto, non di una correzione distribuita con un aggiornamento.

La distinzione non è accademica. Un’analisi successiva condotta sulla build 0.2.99 ha rilevato che il codice di caricamento è ancora presente nel binario, semplicemente tenuto a riposo dal flag lato server. In altre parole, la funzione può essere riattivata senza che venga rilasciata alcuna nuova versione. Anche nel repository pubblicato restano tracce del meccanismo, con la funzione che gestiva l’invio dello stato di sessione che ora si limita a restituire un errore di indisponibilità.

Sul fronte comunicativo, xAI ha gestito la vicenda soprattutto su X, senza un vero avviso di sicurezza o una nota nel changelog. L’azienda ha spiegato che i team enterprise con conservazione dati azzerata non hanno mai avuto codice archiviato e che gli utenti consumer possono usare un comando dedicato nel terminale per disattivare la conservazione e cancellare quanto già sincronizzato. Musk è andato oltre, dichiarando che tutti i dati caricati fino a quel momento sarebbero stati, per usare le sue parole, “completely and utterly deleted”. Restano senza risposta pubblica le domande più scomode, cioè perché i repository venissero caricati per impostazione predefinita, per quanto tempo siano stati conservati e quanti utenti siano stati coinvolti.

L’apertura del codice come tentativo di ricucire la fiducia

Il 15 luglio xAI ha compiuto il passo più significativo, pubblicando l’intera base di codice di Grok Build su GitHub con licenza Apache 2.0 e azzerando contestualmente i limiti di utilizzo. Il ragionamento implicito è comprensibile: se non ti fidi delle nostre dichiarazioni, guarda il codice tu stesso, compilalo e fallo girare in locale con la tua inferenza.

Il repository ha riservato qualche sorpresa a chi lo ha analizzato. Secondo il conteggio di Simon Willison, si tratta di circa 844.530 righe di Rust escludendo spazi e commenti, di cui solo il tre per cento circa proveniente da dipendenze incorporate. Per avere un termine di paragone, il progetto Codex di OpenAI si attesta attorno alle 950.933 righe dello stesso linguaggio. Sono numeri che raccontano quanto siano diventati complessi gli agenti di coding da terminale, molto lontani dall’idea di semplice interfaccia testuale attorno a un modello. Nel codice si trovano il prompt di sistema principale, quello dei subagenti, perfino un renderer di diagrammi Mermaid pensato per il terminale.

Un limite dell’operazione è che il repository è stato pubblicato con un unico commit iniziale, quindi non è possibile ricostruire come il progetto si sia evoluto nel tempo né osservare quando siano state introdotte le funzioni contestate. L’apertura riguarda lo stato attuale, non la storia.

Il paradosso della vulnerabilità trovata subito dopo

Aprire il codice significa anche esporlo allo scrutinio di chi cerca falle, e in questo caso l’attesa è durata pochissimo. In meno di ventiquattro ore i ricercatori di SlowMist hanno segnalato un problema di confine di fiducia che, nella sostanza, funziona così: i file di configurazione che gli agenti di coding leggono automaticamente risalendo le cartelle fino alla radice del repository vengono incorporati nel prompt di sistema senza alcuna validazione della loro provenienza. Se quei file arrivano da un repository non fidato, possono influenzare il comportamento dell’agente e le sue autorizzazioni.

È una categoria di rischio che non riguarda soltanto xAI, perché lo stesso schema di caricamento automatico dei file di contesto è comune a diversi strumenti sul mercato. La risposta ricevuta attraverso il programma di segnalazione, però, ha fatto discutere: la segnalazione è stata classificata come duplicato e considerata fuori ambito in quanto relativa esclusivamente al lato client. Per uno strumento che gira sulla macchina dello sviluppatore e ha accesso in scrittura al filesystem, definire il lato client come questione secondaria è una scelta di perimetro quantomeno opinabile.

Che cosa dovresti fare concretamente

Se hai eseguito Grok Build in una cartella che conteneva qualcosa di sensibile, la mossa sensata non è aspettare comunicazioni ufficiali. Ruota le credenziali che lo strumento potrebbe aver trasmesso, considerando non solo i file che ha letto durante il lavoro ma anche tutto ciò che si trovava nei file tracciati e nella cronologia Git. Questo è il punto che sfugge più spesso: una chiave committata mesi fa e poi rimossa dal codice resta nella cronologia, e la cronologia viaggiava insieme al resto. Cancellarla dal file oggi non la fa sparire dai commit passati.

Al di là del singolo prodotto, la lezione più utile riguarda il modello mentale con cui ti avvicini a questi strumenti. Un agente di coding in cloud non è un programma locale, e ragionare come se lo fosse porta a sottovalutare quanto materiale attraversa la rete. Se lavori su codice proprietario o su progetti soggetti a vincoli contrattuali, vale la pena verificare periodicamente il traffico che il tuo assistente genera, invece di dedurlo dalle impostazioni che l’interfaccia ti mostra. Come ha dimostrato questo caso, un’opzione disattivata non garantisce che il comportamento associato sia effettivamente cessato.

Per chi ha esigenze di riservatezza stringenti, l’alternativa più solida resta portare il modello sulla propria macchina, una strada oggi molto più praticabile di quanto fosse un paio d’anni fa e che abbiamo affrontato nella nostra guida su come usare un modello AI in locale. Vale la pena ricordare che xAI aveva presentato Grok Build come parte della propria offerta per sviluppatori, la stessa che ruota attorno al modello descritto nel nostro approfondimento su Grok 4.5 per coding e agenti, e che il tema della sicurezza degli agenti autonomi si intreccia sempre più con quello della protezione aziendale, come raccontiamo nella panoramica su AI e cybersecurity.

Conclusioni

La vicenda Grok Build è interessante meno per il singolo errore che per la sequenza che ne è seguita, perché condensa in pochi giorni tutte le tensioni del settore. C’è la corsa a rilasciare strumenti agentici sempre più potenti, c’è la disinvoltura con cui vengono raccolti dati senza spiegarlo chiaramente, c’è la reazione rapida quando la comunità se ne accorge e c’è l’apertura del codice come gesto riparatore che però espone immediatamente altre debolezze. Ed è utile riconoscere che l’apertura, pur con i suoi limiti, resta una risposta più verificabile di un comunicato rassicurante.

Il punto che ti conviene portare a casa è che la fiducia in questi strumenti non può basarsi sulle dichiarazioni di chi li produce, ma su ciò che è possibile osservare e controllare. Il codice sorgente aperto aiuta, la possibilità di eseguire tutto in locale aiuta ancora di più, ma nessuna delle due cose sostituisce l’abitudine a chiederti che cosa esce davvero dalla tua macchina quando lavori. Se usi quotidianamente assistenti di questo tipo, dedica un po’ di tempo a capire come funzionano sotto il cofano, magari partendo dalla nostra guida completa agli agenti AI, e continua a seguirci per restare aggiornato su come evolve la sicurezza di questi sistemi.