Una ricerca indipendente ha acceso i riflettori su un comportamento inatteso di Grok Build CLI, l’interfaccia a riga di comando sviluppata da xAI per assistere gli sviluppatori nella scrittura del codice. Secondo le analisi pubblicate dal ricercatore noto come cereblab, il software non si limitava a trasmettere al modello di intelligenza artificiale i file necessari per svolgere un’attività, ma inviava ai server dell’azienda l’intero repository Git del progetto, inclusa la cronologia completa dei commit.

La scoperta riguarda la versione 0.2.93 del client e solleva interrogativi importanti sul modo in cui gli strumenti di coding basati su AI gestiscono il codice sorgente degli utenti. Sebbene l’invio di alcune porzioni di codice sia inevitabile quando un assistente AI opera nel cloud, il trasferimento dell’intera base di codice rappresenta un livello di esposizione decisamente superiore rispetto a quanto gli sviluppatori normalmente si aspettano.

Per dimostrare il comportamento del software, il ricercatore ha intercettato il traffico di rete generato da Grok Build durante una sessione di lavoro. L’analisi ha mostrato due flussi completamente distinti. Da una parte erano presenti le richieste dirette al modello linguistico, che trasportavano soltanto poche centinaia di kilobyte di dati necessari per elaborare il prompt. Dall’altra compariva un canale separato destinato all’archiviazione, attraverso il quale venivano caricati diversi gigabyte di informazioni verso un bucket di Google Cloud Storage gestito da xAI.

L’esperimento più significativo è stato condotto su un repository di circa 12 GB contenente numerosi file che il modello non aveva mai aperto durante la sessione. Nonostante ciò, il client ha trasferito oltre 5 GB di dati verso il cloud, suddivisi in decine di blocchi da circa 75 MB ciascuno, tutti accettati dal server con risposta HTTP 200. Secondo il ricercatore, il volume dei dati inviati cresceva proporzionalmente alla dimensione del repository, suggerendo che il comportamento fosse sistematico e non limitato ai file realmente utilizzati.

Ulteriori verifiche hanno permesso di individuare nel codice del programma il riferimento a un bucket denominato grok-code-session-traces, lo stesso utilizzato per ricevere gli archivi contenenti il repository. All’interno del materiale recuperato era presente perfino un file creato appositamente come “esca”, denominato never_read_canary.txt, che l’assistente aveva ricevuto l’istruzione esplicita di non aprire. Il fatto che quel documento fosse comunque presente nel pacchetto dimostra che il caricamento non dipendeva dai file effettivamente consultati durante il lavoro.

Gli autori della ricerca precisano però che le prove raccolte dimostrano il trasferimento e l’archiviazione dei dati, ma non costituiscono una prova che xAI abbia utilizzato quel codice per addestrare i propri modelli, o che il personale dell’azienda abbia avuto accesso ai repository caricati.

Grok Build

L’aspetto più delicato riguarda la gestione delle informazioni sensibili. Durante i test è stato verificato che, quando Grok Build apriva un file contenente credenziali, il suo contenuto veniva trasmesso integralmente al modello senza alcun meccanismo di mascheramento. In un file .env preparato per l’esperimento erano stati inseriti valori fittizi per chiavi API e password di database, che risultavano presenti sia nella richiesta inviata al modello sia nell’archivio della sessione destinato allo storage remoto.

In questo caso non si è verificata alcuna compromissione reale, poiché tutte le credenziali erano state create esclusivamente per il test. Tuttavia, il comportamento evidenzia un problema di progettazione, nel senso che se uno sviluppatore dovesse aprire accidentalmente un file contenente credenziali autentiche, queste verrebbero trasmesse senza alcuna forma di anonimizzazione.

Particolarmente controverso è anche il funzionamento delle impostazioni sulla privacy. Il ricercatore ha infatti verificato che la disattivazione dell’opzione “Improve the model”, che molti utenti interpretano come un blocco dell’invio dei dati, non impediva il caricamento del repository. Le impostazioni restituite dal server continuavano infatti a mantenere attiva la funzione responsabile dell’upload dei tracciati di sessione. La distinzione è sostanziale. Rinunciare all’utilizzo dei dati per l’addestramento del modello non equivale automaticamente a impedirne la trasmissione verso i server dell’azienda. Si tratta di due controlli differenti e, secondo quanto emerso dall’analisi, soltanto uno era realmente esposto all’utente.

Il confronto con altri strumenti di sviluppo basati sull’intelligenza artificiale rende ancora più evidente la particolarità del comportamento osservato. Anche piattaforme come Claude Code, Codex o Gemini inviano inevitabilmente porzioni di codice ai rispettivi modelli cloud quando devono elaborare una richiesta. Nei test effettuati da cereblab, tuttavia, nessuno di questi strumenti ha trasferito automaticamente un archivio completo del repository con l’intera cronologia Git.

La situazione sembra comunque essere cambiata rapidamente. Il 13 luglio il ricercatore ha ripetuto gli esperimenti utilizzando lo stesso client, senza installare aggiornamenti, rilevando che le richieste verso il servizio di storage erano completamente scomparse. Le nuove impostazioni restituite dal server indicavano infatti che il caricamento della codebase e dei tracciati era stato disabilitato tramite una modifica lato server. Anche altri sviluppatori hanno confermato di aver osservato lo stesso comportamento, suggerendo che la modifica sia stata distribuita su larga scala.

xAI, almeno finora, non ha pubblicato un bollettino di sicurezza né una documentazione tecnica dettagliata sull’accaduto. L’azienda ha solo precisato che i clienti enterprise che utilizzano modalità Zero Data Retention (ZDR) non archiviano codice o dati delle sessioni, mentre gli utenti consumer possono utilizzare il comando /privacy per disabilitare la conservazione dei dati e richiedere l’eliminazione di quelli già sincronizzati.

Resta però aperta una serie di interrogativi. xAI non ha spiegato perché il caricamento completo dei repository fosse abilitato per impostazione predefinita, per quanto tempo tali dati siano stati conservati né quanti utenti siano stati coinvolti. Un’analisi successiva della versione 0.2.99 del client avrebbe inoltre rilevato che il codice responsabile dell’upload è ancora presente nel software e risulta semplicemente inattivo grazie a un’impostazione controllata dal server. Ciò significa che la funzione potrebbe teoricamente essere riattivata senza distribuire un nuovo aggiornamento del programma, cosa che alimenta ulteriormente il dibattito sulla trasparenza e sul controllo effettivo esercitato dagli utenti sui propri dati.

(Immagine in apertura: Shutterstock)