Cosa invia davvero la tua CLI di coding AI: il caso Grok e il paradosso al contrario

Un'analisi wire-level della CLI di coding di xAI (grok) documenta l'upload dell'intero repository e dei file .env verso un bucket cloud di xAI, anche con l'opzione 'migliora il modello' disattivata. Insieme al footprint dei desktop agent e al 'paradosso dell'informazione al contrario', è il promemoria che il codice che dai a un'AI in cloud esce dal tuo perimetro. La risposta: sovranità e governance.

AICybersecurityGovernanceAI CodingGrokxAIData ExfiltrationTelemetryAI GovernanceAI SovereigntyOn-PremiseAdminaPrivacy

Il codice che dai a un’AI esce dal tuo perimetro

Quando colleghi un coding agent in cloud al tuo repository, gli stai dando accesso al tuo codice. La domanda operativa, che quasi nessuno si pone, è: cosa esce davvero dalla tua macchina, e dove finisce? Due documenti di metà luglio 2026 provano a rispondere in modo concreto, e la risposta merita attenzione.

Nota. Questo articolo riporta analisi e segnalazioni di terze parti (ricercatori indipendenti e testate giornalistiche), non verifiche tecniche condotte direttamente da noze. Le situazioni descritte sono in evoluzione: dove note, riportiamo le risposte dei fornitori. Cifre, endpoint e comportamenti si riferiscono alle versioni e alle date indicate e possono essere già cambiati.

Il caso Grok: repository e segreti caricati per intero

Il primo è un’analisi wire-level della CLI di coding di xAI (grok), pubblicata dal ricercatore indipendente @cereblab. Intercettando il traffico con mitmproxy e marcatori canary, l’analisi documenta che, su un normale login consumer, la CLI fa tre cose che vale la pena conoscere con precisione.

Primo, trasmette il contenuto dei file che legge, incluso un file .env contenente chiavi e secrets, a xAI in chiaro e senza redazione, su due canali: il turno del modello (POST /v1/responses) e un archivio caricato (POST /v1/storage, che risponde HTTP 200).

Secondo, e qui sta il punto, carica l’intero repository (ogni file tracciato più la git history) come git bundle, indipendentemente da quello che l’agente legge. Nel test citato, su un repo di 12 GB di file casuali con l’istruzione esplicita di non leggere nulla, il canale del modello (/v1/responses) ha mosso circa 192 KB, mentre il canale di storage ne ha mossi 5,10 GiB: un rapporto di circa 27.800×. Un file segnaposto (src/_probe/never_read_canary.txt), che l’agente aveva ricevuto istruzione di non aprire, è stato recuperato verbatim dal git bundle catturato.

Terzo, la destinazione è un bucket Google Cloud Storage chiamato grok-code-session-traces. E il dettaglio che chiude il cerchio: disattivare l’opzione “migliora il modello” non ferma l’upload, perché l’endpoint delle impostazioni continua a riportare trace_upload_enabled: true.

L’analisi (riferita alla versione grok 0.2.93) ha una metodologia dichiarata (intercettazione TLS con mitmproxy, marcatori canary, git bundle verificati con SHA-256) ed è stata ripresa da numerose testate di settore. Dopo la pubblicazione, xAI ha disabilitato l’upload lato server e ha introdotto nella CLI un’opzione disable_codebase_upload, ma al momento non risulta una dichiarazione pubblica formale sull’accaduto. La direzione, comunque, è inequivocabile: il tuo codice, e potenzialmente i tuoi segreti, lasciano la macchina anche quando pensi di aver detto di no.

Il footprint nascosto degli agent desktop

C’è un secondo asse, di natura diversa ma illuminante: il footprint di questi strumenti. Nel caso di OpenAI Codex, più testate (tra cui The Register) hanno documentato un bug di logging che scriveva su SSD quantità enormi: un log SQLite a livello TRACE (~/.codex/logs_2.sqlite) che, in una misurazione, produceva circa 37 TB in 21 giorni, nell’ordine dei 640 TB l’anno, abbastanza da erodere in meno di un anno la garanzia di scrittura (TBW) di un SSD consumer. OpenAI ha poi corretto il comportamento, con fix nella linea 0.142.x che riducono le scritture di circa l’85%. Alcune segnalazioni parlano anche di consumi di rete elevati (dell’ordine dei 150 GB al mese) legati a WebSocket persistenti e sandbox in cloud, con CLI più leggere a parità di token: cifre da prendere con più cautela, ma coerenti con un principio semplice. Un agente desktop può avere un’attività di rete e disco molto maggiore di quanto l’interfaccia lasci intuire. Qui il problema è un difetto risolto, non un’esfiltrazione, ma la lezione è la stessa: quello che l’agente fa sotto il cofano raramente è visibile.

Il paradosso dell’informazione, al contrario

C’è un modo elegante di inquadrare tutto questo: il paradosso dell’informazione al contrario, un’espressione coniata da Satya Nadella (CEO di Microsoft) a luglio 2026 e ripresa in vari commenti, tra cui un saggio su sn scratchpad. Il paradosso classico di Arrow riguarda il venditore di informazione, che per venderla rischia di regalarla. Nell’era dell’AI il problema si ribalta sul compratore: per usare davvero questi sistemi devi rivelare la tua conoscenza proprietaria. Come sintetizza il saggio, “paghi l’intelligenza due volte: una con i soldi, e una con qualcosa di ancora più prezioso, la conoscenza proprietaria che sei costretto a rivelare”. Prompt, codice, correzioni e flussi di lavoro diventano exhaust che scorre in una sola direzione, verso chi possiede l’infrastruttura.

Cosa ne pensiamo

Il caso Grok rende concreto ciò che di solito resta invisibile, ma il tema non riguarda un solo vendor: qualunque coding agent in cloud spedisce il tuo codice su un’infrastruttura che non controlli, con regole che possono cambiare e con opzioni che, come si è visto, non sempre fanno quello che promettono. Per chi sviluppa software critico, o semplicemente tiene ai propri segreti, è un rischio da mettere in conto.

La risposta, per noi, è architetturale e ha due gambe. La prima è possedere il pavimento operativo: modelli a pesi aperti che girano in locale, dove il codice non lascia il perimetro. Non è più fantascienza, come abbiamo raccontato per DwarfStar 4, colibri, GLM 5.2 e, sul coding agentico in particolare, Ornith 1.0: un modello open che eguaglia la frontiera chiusa e gira sul tuo hardware chiude alla radice il problema dell’esfiltrazione.

La seconda è governare lo stack quando un modello remoto serve davvero. È esattamente ciò che fa Admina: un piano di controllo che porta audit trail di ogni interazione AI, redazione di PII e segreti, e policy bidirezionali ALLOW/BLOCK/REDACT su qualunque modello, locale o remoto. È il livello che intercetta un .env che sta per uscire, invece di scoprirlo in un bucket altrui mesi dopo. La lezione del “toggle disattivato ma upload ancora attivo” è proprio questa: non puoi affidare il controllo a un interruttore del fornitore, ti serve il tuo.

È il senso di Open Intelligence, Secure Governance, e la stessa logica per cui trattiamo la frontiera closed come tecnologia che qualcun altro può filtrare o spegnere (il caso Fable 5, GPT-5.6 Sol). Gli strumenti di coding AI sono ormai troppo utili per rinunciarci e troppo indiscreti per usarli alla cieca. La via d’uscita non è spegnerli: è possederli e governarli.

Fonti

Vuoi supporto?Sei sotto attacco?Stato dei servizi
Vuoi supporto?Sei sotto attacco?Stato dei servizi