Grok Build, l’agente di programmazione da terminale sviluppato da SpaceXAI, avrebbe trasferito verso l’infrastruttura cloud dell’azienda interi repository Git, compresi file non utilizzati durante le attività di coding, cronologia dei commit e configurazioni potenzialmente contenenti credenziali riservate. Il caricamento sarebbe avvenuto in background durante le normali sessioni del programma e avrebbe coinvolto quantità di dati molto superiori a quelle effettivamente necessarie per elaborare le richieste dell’utente.
Grok Build è un agente AI distribuito attraverso un’interfaccia a riga di comando e progettato per operare direttamente all’interno dei progetti software. Il prodotto può analizzare il codice, preparare piani di intervento, modificare file ed eseguire attività complesse dal terminale. SpaceXAI lo ha reso disponibile in versione early beta agli abbonati SuperGrok e X Premium Plus.
L’anomalia è stata individuata attraverso un’analisi del traffico di rete generato dal client ufficiale. Il ricercatore ha utilizzato una sessione controllata nella quale l’agente non aveva effettuato chiamate a strumenti e non aveva aperto i file presenti nel repository. Nonostante ciò, il programma avrebbe iniziato a trasferire verso un bucket Google Cloud Storage gestito da SpaceXAI una copia molto estesa del progetto.
Il traffico risultava suddiviso in almeno due canali distinti. Il primo, collegato all’endpoint /v1/responses, trasportava le informazioni utilizzate nelle interazioni con il modello. Il secondo, identificato attraverso l’endpoint /v1/storage, veniva invece impiegato per caricare grandi quantità di dati del repository verso l’archiviazione cloud.
Nel test principale, il canale delle conversazioni con il modello aveva trasferito complessivamente 196.705 byte, equivalenti a circa 192 KB, distribuiti su cinque richieste. Il canale di archiviazione aveva invece inviato 5.476.228.005 byte, pari a circa 5,10 GiB. Il volume trasferito attraverso lo storage risultava quindi circa 27.800 volte superiore a quello utilizzato dalle interazioni effettive con il modello.
La prova era stata eseguita su un repository di circa 12 GB composto da file casuali che l’agente non aveva letto. Il fatto che diversi gigabyte fossero stati trasferiti attraverso il canale di storage, mentre soltanto 192 KB transitavano nelle richieste del modello, indicava che il client stava creando e inviando una copia del repository indipendentemente dai file necessari per completare l’attività.
Ulteriori test condotti con repository di dimensioni comprese tra 64 MB e 12 GB avrebbero mostrato una correlazione tra la quantità totale di dati presenti nel progetto e il volume caricato attraverso /v1/storage. Il comportamento non sembrava quindi limitato a una selezione contestuale di file, ma compatibile con un meccanismo di acquisizione estesa della base di codice.
Il client avrebbe confezionato il repository sotto forma di bundle Git e trasferito i dati in blocchi di grandi dimensioni verso un bucket denominato grok-code-session-traces. Un bundle Git può comprendere non soltanto lo stato corrente dei file, ma anche oggetti e cronologia del repository necessari per ricostruirne revisioni e commit.
L’analisi ha inoltre segnalato il possibile caricamento di file che l’agente non aveva aperto e di informazioni eliminate dalle versioni più recenti ma ancora presenti nella cronologia Git. Un segreto rimosso dal codice corrente, per esempio una chiave API precedentemente inserita in un commit, può continuare a essere contenuto negli oggetti storici del repository e risultare incluso in una copia completa.
Tra i dati potenzialmente coinvolti figurano file .env, chiavi API, token di accesso, credenziali dei servizi cloud, password dei database e configurazioni interne. I file .env vengono normalmente utilizzati per conservare variabili d’ambiente necessarie all’esecuzione delle applicazioni e possono contenere informazioni che non devono essere inserite nel codice sorgente o trasmesse a servizi esterni.
Secondo la ricostruzione tecnica, il comportamento sarebbe stato osservato anche quando l’utente aveva disattivato l’opzione destinata a impedire l’utilizzo dei propri contenuti per migliorare il modello. La modifica del controllo “Improve the model” non avrebbe interrotto il caricamento del repository, perché la trasmissione sarebbe stata gestita come telemetria o tracciamento della sessione e non come invio dei contenuti destinati all’addestramento.
Nel traffico analizzato, il server avrebbe continuato a restituire un’impostazione trace_upload_enabled: true. Questo valore suggeriva che l’attivazione del caricamento delle tracce dipendesse anche da una configurazione ricevuta dal backend e non soltanto dalle preferenze selezionate localmente dall’utente.
La distinzione tra utilizzo dei dati per l’addestramento e conservazione delle tracce è centrale nel funzionamento del prodotto. Un utente può scegliere di non contribuire al miglioramento dei modelli, ma ciò non implica necessariamente che tutti i dati operativi, diagnostici o di telemetria smettano di essere trasferiti. Nel caso di Grok Build, tuttavia, il tracciamento avrebbe incluso una porzione molto più ampia dei dati locali rispetto alle sole informazioni tecniche necessarie per analizzare il comportamento del client.
Dopo la pubblicazione dei risultati, i caricamenti sarebbero cessati senza che gli utenti installassero un aggiornamento del programma. Il cambiamento suggerisce che SpaceXAI abbia disattivato o modificato dal lato server la funzione responsabile della raccolta, probabilmente intervenendo sulla configurazione remota ricevuta dal client.
La società ha dichiarato che, per i clienti coperti da accordi Zero Data Retention, i dati del codice e le informazioni di tracciamento non vengono conservati. SpaceXAI ha inoltre affermato di attribuire grande importanza alla privacy e alle scelte dei propri clienti.
Gli accordi Zero Data Retention, o ZDR, vengono normalmente applicati a clienti aziendali per impedire la conservazione dei contenuti inviati ai servizi AI oltre il tempo strettamente necessario alla loro elaborazione. Non è stato chiarito quanti utilizzatori di Grok Build fossero coperti da un contratto di questo tipo né quale trattamento fosse applicato agli utenti consumer e agli abbonati individuali.
Elon Musk ha annunciato che tutti i dati degli utenti caricati in precedenza sui sistemi di SpaceXAI sarebbero stati eliminati completamente come misura precauzionale. Secondo la dichiarazione, dopo l’operazione non sarebbe rimasta alcuna copia dei dati interessati.
La cancellazione annunciata riguarda le informazioni presenti nell’infrastruttura di SpaceXAI, ma non consente agli utenti di verificare direttamente quali file siano stati trasferiti, per quanto tempo siano rimasti archiviati o se siano stati consultati. Non è stata descritta una procedura attraverso la quale ogni cliente possa ottenere un inventario dei dati ricevuti dal servizio o una prova indipendente dell’eliminazione.
Non risultano inoltre ancora comunicati il numero complessivo degli utenti coinvolti, le versioni precise del client interessate e la data di attivazione del comportamento. L’analisi tecnica pubblicata riguarda in particolare la versione 0.2.93 di Grok Build, ma non è stato stabilito se la stessa funzione fosse presente nelle versioni precedenti o successive.
Rimane da chiarire anche se i dati fossero cifrati durante il trasferimento e con quali protezioni venissero conservati nel bucket cloud. L’analisi ha accertato l’uscita delle informazioni dal computer locale e la loro destinazione verso l’infrastruttura di archiviazione, ma non ha dimostrato un accesso non autorizzato da parte di soggetti esterni.
La presenza di chiavi e credenziali nei repository comporta comunque un rischio operativo indipendente dalla successiva cancellazione dei file. Una credenziale trasferita fuori dall’ambiente previsto deve essere considerata potenzialmente esposta, perché non è possibile escludere che sia stata registrata in log, copiata in altri sistemi o consultata durante il periodo di conservazione.
Per questo motivo, agli utenti che hanno utilizzato Grok Build su repository contenenti API key, token cloud o password di database è stato raccomandato di revocare e rigenerare le credenziali. La semplice eliminazione della copia caricata non modifica infatti la validità di una chiave ancora attiva.
La rotazione dovrebbe coinvolgere anche i segreti eliminati dai file correnti ma ancora presenti nella cronologia Git. Rimuovere una chiave dall’ultima versione del codice non la elimina automaticamente dai commit precedenti. Quando viene trasferito un bundle completo, anche questi oggetti storici possono essere inclusi.
La verifica dovrebbe riguardare file .env, configurazioni CI/CD, chiavi SSH, token dei package registry, credenziali AWS, Google Cloud o Azure, password dei database, webhook, certificati, file di configurazione Kubernetes e qualsiasi altro segreto che possa essere stato conservato nel repository o nella sua cronologia.
L’analisi comparativa citata dal ricercatore ha coinvolto anche Claude Code, Codex e Gemini CLI. Nelle prove effettuate con la stessa metodologia, questi strumenti avrebbero mantenuto localmente i file non consultati e trasmesso soltanto quelli effettivamente aperti durante il processo. Un file-esca predisposto per non essere letto dall’agente non sarebbe stato inviato dai tre client confrontati.
Il confronto non riguarda la qualità dei modelli o le capacità di programmazione, ma il comportamento dei rispettivi client nella selezione dei dati da trasferire. Grok Build avrebbe utilizzato un canale separato per acquisire il repository, mentre negli altri strumenti osservati il traffico sarebbe rimasto collegato alle informazioni necessarie per le singole operazioni.
La documentazione di presentazione di Grok Build descrive il prodotto come un agente capace di operare sui progetti direttamente dal terminale. Per le attività complesse può essere avviato in modalità Plan, nella quale prepara un piano che l’utente può approvare, commentare o riscrivere prima dell’esecuzione. Dopo l’approvazione, le modifiche vengono mostrate attraverso diff consultabili.
Questi controlli riguardano le azioni visibili eseguite sul codice, ma il caricamento delle tracce sarebbe avvenuto come processo separato e non sarebbe comparso tra le modifiche sottoposte all’approvazione dell’utente. L’autorizzazione al piano di coding non equivaleva quindi a una conferma esplicita per trasferire l’intero repository verso lo storage remoto.
Grok Build viene installato attraverso uno script da terminale e si autentica utilizzando l’account associato all’abbonamento. Il client dispone quindi dell’accesso diretto alla directory dalla quale viene avviato e ai file leggibili dall’utente del sistema operativo. L’estensione dei dati acquisibili dipende dal percorso selezionato e dai permessi assegnati al processo.
L’utilizzo dell’agente nella radice di un progetto può rendere accessibili non soltanto il codice, ma anche directory nascoste, configurazioni locali, file temporanei e metadati Git. Se il programma costruisce automaticamente una rappresentazione completa del repository, tutti questi elementi possono rientrare nel materiale elaborato o caricato.
SpaceXAI non ha ancora pubblicato una descrizione tecnica completa della funzione disattivata, delle ragioni per cui fosse stata implementata e delle finalità attribuite alle copie dei repository. Non è stato specificato se il caricamento servisse per debugging, analisi delle sessioni, riproduzione degli errori, valutazione del prodotto o altre attività interne.
Musk ha indicato che la conservazione dei dati può essere utile per individuare e correggere i problemi del servizio, pur affermando che le impostazioni sulla privacy devono essere rispettate. Il punto ancora da chiarire riguarda quindi la corrispondenza tra le preferenze mostrate nell’interfaccia, le configurazioni applicate dal server e il comportamento effettivo del client.
La documentazione generale di SpaceXAI consente agli utenti di decidere se i contenuti possano essere utilizzati per migliorare il modello e permette di richiedere la cancellazione delle conversazioni o dell’account. Per i normali servizi Grok, la società indica che l’eliminazione dai propri sistemi può richiedere fino a trenta giorni, salvo dati anonimizzati o informazioni che debbano essere conservate per motivi di sicurezza o obblighi legali.
Non è stato precisato se queste condizioni generali si applicassero nello stesso modo ai bundle e alle tracce generate da Grok Build. Il prodotto utilizza infatti un flusso operativo differente rispetto alla normale chat e può trattare automaticamente file locali che l’utente non ha caricato manualmente attraverso un’interfaccia.
L’intervento dal lato server avrebbe interrotto il caricamento, mentre la promessa di eliminazione riguarda i dati già raccolti. Restano ancora da comunicare un resoconto tecnico dell’incidente, le versioni coinvolte, il periodo di attività della funzione, i criteri di conservazione, gli eventuali accessi interni e le modalità con cui gli utenti potranno verificare la completa rimozione dei propri repository.
Il caso riguarda quindi una funzione di Grok Build distinta dall’elaborazione necessaria per il coding: un canale di storage capace di trasferire intere basi di codice e cronologie Git verso il cloud. Dopo la segnalazione pubblica, SpaceXAI avrebbe disabilitato il caricamento da remoto e annunciato la cancellazione integrale dei dati precedentemente acquisiti.