Grok Build caricava repository Git completi sui server xAI senza consenso

🛡️ Executive Summary

• Grok Build 0.2.93 caricava automaticamente interi repository Git attraverso un canale di storage separato dalle richieste inviate al modello.
• Gli archivi comprendevano cronologia dei commit e file sensibili già tracciati, anche quando l’utente disattivava il miglioramento del modello.
• xAI ha fermato gli upload lato server e permette di gestire conservazione e cancellazione dei dati attraverso il comando /privacy.

Grok Build, lo strumento CLI di programmazione sviluppato da xAI, caricava automaticamente interi repository Git su un bucket Google Cloud Storage, includendo la cronologia completa dei commit e file che il modello non aveva mai aperto. Il comportamento, osservato nella versione 0.2.93, risultava attivo per impostazione predefinita e continuava anche quando l’utente disabilitava l’opzione destinata al miglioramento del modello. La scoperta solleva un problema che va oltre la telemetria ordinaria: codice proprietario, credenziali e versioni eliminate dei file potevano uscire dalla macchina dello sviluppatore senza un consenso specifico e chiaramente separato dall’utilizzo dell’assistente AI.

Grok Build separava le richieste al modello dall’upload del repository

L’analisi tecnica pubblicata dal ricercatore cereblab mostra che Grok Build utilizzava due canali distinti. Le normali conversazioni e i contenuti necessari al modello passavano attraverso l’endpoint /v1/responses, mentre gli archivi delle sessioni e lo stato del repository venivano inviati mediante /v1/storage. Questa separazione è fondamentale per comprendere la portata del problema, perché il trasferimento del repository non rappresentava una semplice conseguenza dei file letti dall’agente durante il lavoro: era un processo autonomo, capace di proseguire indipendentemente dalle effettive necessità del modello. Il file metadata.json generato dal client indicava come destinazione il bucket gs://grok-code-session-traces/, mentre nel binario erano presenti riferimenti ai componenti interni dedicati alla raccolta e all’invio dei dati. Il server restituiva inoltre il flag trace_upload_enabled: true, mantenendo operativo il caricamento anche quando l’opzione “Improve the model” risultava disattivata. La documentazione ufficiale del changelog di Grok Build mostra che il prodotto disponeva già da giugno di funzioni dedicate al caricamento delle tracce e al ripristino remoto delle sessioni, ma non chiariva in modo esplicito che l’operazione potesse comprendere l’intero repository. Il caso si inserisce nel settore sempre più competitivo degli agenti di sviluppo, già caratterizzato dalla crescita di Grok 4 Code e degli strumenti concorrenti di OpenAI, ma evidenzia come l’autonomia operativa debba essere accompagnata da limiti verificabili sul trattamento del codice sorgente.

Il file canary dimostra che veniva trasmesso tutto il contenuto tracciato da Git

Per stabilire se Grok Build inviasse soltanto i file effettivamente consultati, il ricercatore ha creato never_read_canary.txt, inserendovi un indicatore univoco e ordinando espressamente all’agente di non aprire alcun file. Il test ha mostrato che il canary era comunque presente nel bundle caricato attraverso l’endpoint di storage, insieme alla cronologia Git completa. La prova è stata replicata su un secondo repository, escludendo che il risultato dipendesse da una configurazione particolare del primo progetto. L’upload comprendeva i file committed e le loro versioni storiche, rendendo recuperabili anche contenuti eliminati dalla working directory ma ancora presenti nei commit precedenti. I file esclusi tramite .gitignore non venivano normalmente aggiunti al bundle, ma questa protezione non era sufficiente per segreti, chiavi o configurazioni che fossero stati registrati almeno una volta nel repository. Il dato quantitativo più significativo emerge dal test effettuato su un progetto da 12 GB: mentre il canale delle risposte del modello trasferiva circa 192 KB, il canale di storage inviava 5,10 GiB in 73 blocchi da circa 75 MB, tutti accettati dal server con risposta HTTP 200. Il rapporto tra i due flussi dimostra che il volume non poteva dipendere dal contesto necessario alla risposta dell’AI, ma corrispondeva alla copia sostanziale del repository. La questione assume particolare rilievo perché gli agenti di coding vengono sempre più integrati nei flussi di sviluppo aziendali, come dimostrano l’arrivo del coding agentico in Xcode con Claude e Codex e la diffusione di strumenti capaci di leggere, modificare e validare autonomamente grandi basi di codice. (Gist)

File .env e cronologia dei commit amplificavano il rischio per aziende e sviluppatori

L’upload integrale esponeva una superficie informativa molto più ampia rispetto ai singoli frammenti sottoposti consapevolmente a un modello linguistico. Nel corso dei test, il contenuto di un file .env con password e chiavi API fittizie è stato trasmesso senza redazione sia durante l’interazione ordinaria con il modello sia negli archivi session_state. In un repository reale, file simili possono contenere token cloud, credenziali per database, chiavi di firma, segreti CI/CD e indirizzi di infrastrutture interne. Anche quando una credenziale viene successivamente rimossa, la cronologia dei commit può conservarne una copia, trasformando il bundle Git in un archivio delle informazioni sensibili accumulate durante l’intero ciclo di sviluppo. Il rischio non riguarda quindi soltanto la riservatezza del codice proprietario, ma anche la possibilità di compromettere sistemi esterni collegati attraverso segreti esposti. Il problema assume un peso ulteriore nei repository aziendali soggetti a obblighi contrattuali, accordi di non divulgazione, discipline sulla localizzazione dei dati o procedure interne che vietano il trasferimento del codice verso servizi non autorizzati. La capacità degli agenti AI di analizzare repository completi può produrre benefici importanti anche nella sicurezza, come dimostrato da Codex Security nell’individuazione di migliaia di vulnerabilità nei progetti software, ma proprio questa profondità di accesso rende indispensabile distinguere tra elaborazione temporanea, conservazione delle sessioni, addestramento e archiviazione dell’intera base di codice. Disattivare il miglioramento del modello non impediva infatti l’upload, perché la preferenza regolava il possibile utilizzo dei dati per il training e non il loro trasferimento verso lo storage delle tracce. (Gist)

xAI ha bloccato gli upload attraverso una modifica lato server

Il 13 luglio 2026 i test sulla stessa versione 0.2.93 hanno smesso di produrre richieste verso l’endpoint di storage. Dopo sei verifiche consecutive, il ricercatore non ha osservato nuovi caricamenti e ha rilevato una configurazione server modificata con disable_codebase_upload: true e trace_upload_enabled: false. Il cambiamento è avvenuto senza richiedere inizialmente un aggiornamento del client, dimostrando che l’attivazione della funzione dipendeva da flag controllati centralmente da xAI. Un’analisi successiva della versione 0.2.99 ha indicato che il codice destinato all’upload era ancora presente nel binario, ma risultava inattivo in base alle impostazioni ricevute dal server.

La distinzione è rilevante: la correzione interrompe il comportamento osservato, ma non equivale alla rimozione definitiva della funzionalità dal software. xAI ha precisato che gli account enterprise configurati con Zero Data Retention non avevano mai conservato codice o tracce e che anche l’utilizzo tramite API key rispettava la policy ZDR. Per gli utenti individuali, il comando /privacy permette di disabilitare la conservazione e richiedere la cancellazione dei dati sincronizzati. Elon Musk ha inoltre assicurato che tutti i dati caricati prima dell’intervento sarebbero stati eliminati completamente. Restano però senza una risposta pubblica dettagliata alcuni elementi essenziali: il numero di repository interessati, il periodo esatto di attivazione, la durata della conservazione, le procedure utilizzate per verificare la cancellazione e il motivo per cui l’upload fosse abilitato di default. Il changelog ufficiale disponibile al momento della verifica riporta come versione più recente la 0.2.98 del 12 luglio, senza una descrizione specifica dell’incidente o della disattivazione dei repository upload.

Il consenso deve distinguere elaborazione AI, telemetria e archiviazione del codice

Il caso Grok Build evidenzia un problema strutturale degli assistenti di programmazione: l’utente può accettare che un modello legga determinati file per svolgere un compito senza autorizzare automaticamente la copia persistente dell’intero repository. Elaborazione, telemetria, miglioramento del modello, sincronizzazione delle sessioni e backup remoto del codice rappresentano trattamenti differenti e dovrebbero essere accompagnati da controlli separati, comprensibili e impostati secondo un vero opt-in. La presenza di un’opzione per escludere l’addestramento non può essere interpretata come consenso implicito all’archiviazione integrale della storia Git, soprattutto quando il trasferimento avviene attraverso un endpoint distinto e può superare di migliaia di volte il traffico necessario alla risposta del modello. Gli sviluppatori che hanno utilizzato Grok Build durante il periodo interessato dovrebbero verificare lo stato della privacy nel client, identificare repository contenenti segreti committed e procedere alla rotazione delle credenziali potenzialmente coinvolte, senza considerare sufficiente la loro successiva eliminazione dal ramo corrente. Per le imprese, l’incidente rafforza la necessità di controllare il traffico in uscita degli agenti AI, utilizzare ambienti isolati, applicare policy ZDR quando disponibili e vietare l’impiego di strumenti non ancora validati sui repository sensibili. La disattivazione lato server ha fermato rapidamente gli upload, ma la rapidità della correzione non sostituisce la trasparenza: quando un assistente dispone dell’accesso tecnico necessario per leggere un’intera base di codice, il confine tra ciò che viene elaborato e ciò che viene conservato deve essere dichiarato prima dell’utilizzo, non scoperto attraverso l’analisi del traffico di rete.