Ruotate ogni segreto che Grok Build abbia mai visto

Il file che nessuno aveva aperto

Il ricercatore ha piazzato un'esca. Un unico file, lasciato in un repository di prova, che all'assistente non era stato chiesto di aprire e che l'assistente non ha mai citato: un canarino. Poi ha messo il traffico sotto proxy e ha guardato che cosa Grok Build, la CLI di coding di xAI, spedisse davvero a casa. Il canarino è ricomparso nel pacchetto intercettato. Aveva lasciato la macchina senza essere mai stato letto.

L'analisi del traffico di rete della versione 0.2.93, ormai pubblica, descrive due canali distinti. Il primo è quello che chiunque si aspetta da un assistente di coding in cloud: un canale legato al turno del modello, che trasporta i file che l'agente legge davvero, per poter rispondere. Il secondo è un canale di archiviazione in background, che spedisce un'istantanea dell'intero spazio di lavoro verso un bucket di storage, che l'agente abbia guardato quei file oppure no.

La scoperta sta nella distanza fra i due. Su un repository di prova da 12 gigabyte, il canale del turno del modello ha mosso circa 192 kilobyte. Il canale in background ne ha mossi 5,10 gibibyte, in 73 blocchi da circa 75 megabyte ciascuno. Una differenza di circa 27.800 volte. Un canale stava facendo il lavoro. L'altro stava copiando l'edificio.

Tra i file partiti c'era un .env tracciato, il file in cui per convenzione gli sviluppatori tengono esattamente le cose che non devono mai viaggiare: chiavi API, password di database. È partito integrale e in chiaro.

L'interruttore sullo schermo non era quello sul filo

Ogni strumento di sviluppo con IA arriva ormai con un interruttore che dice, in una forma o nell'altra, "aiutaci a migliorare il modello". È il comando di cui chiede conto l'ufficio acquisti, quello che il responsabile della protezione dei dati riporta nella valutazione, quello che un capo dell'ingegneria indica quando qualcuno chiede se il codice sia al sicuro.

Il ricercatore lo ha spento. Poi è andato a vedere che cosa ne pensasse il server. L'endpoint delle impostazioni continuava a restituire trace_upload_enabled come true. I caricamenti proseguivano.

Qui conviene separare la sostanza dal titolo. Il difetto non è che un assistente di coding mandi del codice a un server: è la premessa stessa di un assistente in cloud, ed è il motivo per cui si leggono le condizioni prima di installarne uno. Il difetto è che l'interruttore del consenso e il percorso dei dati non sono mai stati collegati l'uno all'altro. L'interruttore governava l'addestramento. Il caricamento passava da un altro tubo, e niente di ciò che stava sullo schermo arrivava fin lì.

Un comando che non comanda nulla è peggio di nessun comando, perché il team che lo vede smette di guardare.

La vera scoperta è la correzione lato server

Il 13 luglio 2026 i caricamenti si sono fermati. La parte istruttiva è il come. Nessuna nuova release del client, nessun cambio di versione, nessuna voce di changelog da leggere e approvare. Lo stesso binario 0.2.93 ha semplicemente smesso di fare richieste allo storage, perché il server ha iniziato a rispondere con un nuovo flag che disattivava il caricamento del codice. Elon Musk ha dichiarato che i dati già caricati sarebbero stati, parole sue, "completamente e totalmente cancellati".

Rileggete quella sequenza dal punto di vista della governance. Il comportamento del software sui portatili dei vostri sviluppatori è stato cambiato da remoto, dal fornitore, senza toccare l'artefatto che avevate approvato. Il che vuol dire che allo stesso modo poteva essere cambiato nella direzione opposta, e dalla vostra parte sarebbe sembrato identico.

È questa la lezione strutturale, e vale ben oltre xAI. Se il comportamento di uno strumento sui dati dipende da flag lato server, esaminare il client una volta vi dice che cosa faceva il giorno in cui l'avete guardato. Non vi dice che cosa fa adesso. Fissare una versione, leggere le note di rilascio e firmare l'approvazione è un processo costruito per software che porta il proprio comportamento dentro il binario. Gran parte degli strumenti di IA non lo fa più.

xAI non ha reso noto perché quei caricamenti esistessero, per quanto tempo i dati siano stati conservati, chi potesse raggiungerli o quanti utenti siano stati coinvolti. Quelle quattro risposte sono ciò che serve a un cliente per misurare l'incidente, e la loro assenza è già di per sé un'informazione.

Che cosa deve adesso ai suoi clienti un team europeo

Partite dall'ipotesi che costa meno se si rivela sbagliata: considerate comunicato a terzi ogni segreto che si sia trovato in un repository aperto con Grok Build. Ruotate chiavi API, credenziali di database, chiavi di firma e token. Fatelo sulla base dei repository che sono stati aperti, non dei file che pensate l'assistente abbia letto, perché tutto il senso di questa scoperta è che quei due insiemi non coincidono.

Poi guardate che cos'altro c'era in quei repository. Il solo codice sorgente è un problema commerciale. Dati personali, o credenziali che aprono sistemi che ne contengono, sono un problema giuridico. Ai sensi del GDPR, un fornitore di IA che tratta il vostro repository su vostra istruzione è un responsabile del trattamento, e una copia di quel repository che finisce in un bucket di archiviazione al di fuori della finalità concordata è una comunicazione di dati che siete tenuti a valutare. Il termine per la notifica al Garante per la protezione dei dati personali decorre da quando ne siete venuti a conoscenza, e il rimedio del fornitore non lo azzera.

I soggetti essenziali e importanti ai sensi della NIS2 devono trattarlo come un incidente della catena di fornitura e registrarlo come tale, con l'ACN come riferimento nazionale, perché è esattamente questo che è: un difetto nel prodotto di un fornitore che ha spostato i vostri dati in un posto che non avete scelto.

Niente di tutto questo richiede certezze su che cosa xAI abbia fatto con i dati. Richiede soltanto che oggi non siate in grado di dimostrare che non abbia avuto conseguenze.

Come si compra uno strumento di coding con IA dopo questo caso

Il cambiamento utile non è il divieto. I team che vietano in blocco gli assistenti di coding con IA scoprono quasi sempre che i loro sviluppatori ne hanno installato uno lo stesso, e che adesso nessuno lo sta tracciando. Il cambiamento utile è smettere di considerare il client come il confine.

Fate tre domande a un fornitore prima che il prossimo strumento finisca su un portatile. Con quali endpoint parla lo strumento, e possiamo vederlo sulla nostra rete anziché nella vostra documentazione. Il vostro server può cambiare ciò che il client già installato invia senza rilasciare una nuova versione, e in tal caso che cosa ci avverte quando succede. Se un'impostazione è disattivata nel nostro tenant, qual è la sua rappresentazione lato server, e ci lascerete verificarla.

Poi rendete le risposte verificabili invece che contrattuali. Un proxy e un pomeriggio hanno prodotto questa scoperta. È un controllo più economico di qualunque questionario di assurance, ed è l'unico che misura il comportamento invece delle intenzioni. I segreti, intanto, non dovrebbero proprio stare in un repository che un agente di coding può vedere: iniezione delle variabili d'ambiente a runtime e un gestore di segreti trasformano questa categoria di incidenti da violazione a scrollata di spalle.

Vale la pena avere questi strumenti. Quello che non vale la pena avere è un processo di revisione che legge l'etichetta e non guarda mai il filo.

Da leggere ora: I prezzi dei wafer salgono su ogni nodo avanzato  |  Nessun laboratorio IA ha superato il C+ in sicurezza