Da promettente assistente di programmazione, Grok Build è diventato uno dei casi più discussi dell’anno nel mondo della sicurezza informatica. Il programma non trasmetteva soltanto i file necessari per rispondere alla richiesta dell’utente, ma creava un archivio contenente l’intera base di codice del progetto. Così l’azienda di Elon Musk ha disattivato immediatamente la funzione incriminata, promesso di cancellare i dati raccolti e, soprattutto, ha reso pubblico l’intero codice sorgente del progetto con licenza Apache 2.0. Gli agenti AI per la programmazione stanno diventando strumenti quotidiani per milioni di sviluppatori. Claude Code, Codex, Cursor, Gemini CLI e Grok Build hanno tutti bisogno di leggere parti del codice locale per poter suggerire modifiche o correggere errori. Ma leggere il codice necessario per rispondere a una richiesta è molto diverso dal trasferire automaticamente l’intero contenuto di una cartella o di un repository remoto.
Il problema Secondo le analisi indipendenti che hanno fatto esplodere il caso, Grok Build non si limitava ai file utilizzati durante la sessione. In alcune configurazioni inviava l’intero repository Git, compresa la cronologia delle modifiche, verso bucket Google Cloud gestiti da xAI. Un ricercatore ha dimostrato che perfino file che il modello non aveva mai aperto erano finiti nell’archivio remoto. Per un programmatore il problema non è soltanto la privacy personale. Nei repository aziendali possono essere presenti codice proprietario, chiavi API, certificati, documentazione interna e informazioni commercialmente sensibili. È materiale che spesso rappresenta il patrimonio più prezioso di un’impresa. xAI sostiene che gli utenti avevano già la possibilità di disabilitare la conservazione dei dati e che gli account configurati con modalità Zero Data Retention erano sempre stati esclusi. Dopo le proteste, però, l’azienda ha modificato l’impostazione predefinita: la raccolta dei dati è ora disattivata per tutti, i dati precedentemente conservati verranno eliminati e Grok Build può essere eseguito completamente in locale utilizzando modelli propri. La soluzione Rendere open source l’intero progetto significa permettere a chiunque di verificare cosa faccia realmente il software. Non è una garanzia assoluta, perché il codice pubblicato deve corrispondere a quello distribuito e molti comportamenti possono dipendere anche dai server remoti. Ma introduce un elemento che finora mancava: la verificabilità. Il repository pubblicato contiene oltre 840 mila righe di codice Rust e appare come il risultato di un progetto sviluppato internamente per molto tempo, anche se la storia del suo sviluppo resta invisibile. Sono presenti i prompt di sistema utilizzati dall’agente, un renderer testuale per diagrammi Mermaid e numerosi strumenti ispirati a progetti concorrenti come Codex e OpenCode, importati nel rispetto delle rispettive licenze open source. Rimangono inoltre tracce del sistema utilizzato per il caricamento dei dati verso Google Cloud, oggi apparentemente disabilitato. Negli ultimi mesi i produttori di agenti AI hanno insistito sul concetto di “local-first”: il software gira sul computer dell’utente e quindi dovrebbe offrire maggiori garanzie rispetto alle tradizionali applicazioni cloud. Ma “locale” non significa necessariamente che i dati restino sul computer. Dipende da quali informazioni vengono trasmesse ai server e da quanto controllo ha realmente l’utente. Aprire il codice è il modo più rapido per cercare di ristabilire la fiducia in Grok Build. Ci riuscirà?
