Cosa il tuo AI coding tool NASCONDE veramente
Grok Build carica l'intero repository su server xAI, file .env inclusi. Claude Code brucia 33mila token prima del prompt. Un'analisi dei dati che i tool di AI coding non dicono di inviare.
Installa Grok Build su un progetto reale. Prompt di tre parole: "rispondi solo OK". Il tool non deve leggere nessun file. Non deve toccare niente.
Eppure l'intero repository, ogni file tracciato e cronologia git completa, parte via cavo verso un bucket Google Cloud Storage chiamato grok-code-session-traces.
Un'analisi indipendente via mitmproxy ha dimostrato che un file canary inserito apposta, never_read_canary.txt, con un marker univoco che l'agente non doveva nemmeno sapere esistesse, è stato recuperato verbatim dal bundle git caricato. Il server ha risposto HTTP 200. L'upload è stato accettato.
Non è un incidente. È architettura.
Il caso Grok Build: quello che l'analisi wire-level ha dimostrato
Un'analisi indipendente pubblicata il 12 luglio 2026 ha catturato il traffico di grok 0.2.93 via mitmproxy. L'analisi completa è qui, ma i punti chiave sono questi.
Primo: l'intero repository viene caricato, non solo i file che l'agente legge. Su un repo da 12 GB di file mai letti, il canale di storage (POST /v1/storage) ha mosso 5,10 GiB in 73 chunk da ~75 MB, tutti HTTP 200. Il canale del modello (/v1/responses) ha mosso solo 192 KB. Il rapporto è ~27.800:1: i dati che lasciano la macchina sono quasi trentamila volte quelli che il modello ha effettivamente processato.
Il modello non ha mai visto quei file. Ma 5,10 GiB di essi sono comunque arrivati ai server xAI.
Secondo: i file .env vengono trasmessi senza alcuna redazione. Un file secrets.env contenente API_KEY=CANARY7F3A9-SECRET-should-not-leave è stato trovato verbatim in due canali separati: il corpo della richiesta al modello (POST /v1/responses) e l'archivio session_state caricato via POST /v1/storage. Non c'è alcun filtro per pattern come API_KEY= o DB_PASSWORD=.
Terzo: l'opt-out per il miglioramento del modello non ferma l'upload. Dopo aver disattivato l'opzione nelle impostazioni account, il server rispondeva ancora trace_upload_enabled: true, e un successivo run con l'opt-out attivo ha caricato comunque l'intero repository come git bundle. L'opt-out riguarda l'addestramento, non la trasmissione. I tuoi file partono lo stesso.
Quarto: la destinazione è grok-code-session-traces, un bucket Google Cloud Storage. Il nome del bucket compare nel binario stesso (strings su grok restituisce il percorso letterale), e i metadati staged mappano ogni file a un fileId del tipo gs://grok-code-session-traces/repo_changes_dedup/v2/supplemental/sha256_.... Nessuno di questi meccanismi è documentato nei materiali di setup della CLI che l'analista ha esaminato. Sono attivi di default.
Claude Code: più sottile, stesso principio
Con Claude Code il problema ha una forma diversa. Non è un bucket GCS nascosto. È il volume di token: ogni token inviato al modello è un dato che lascia la tua macchina, e Claude Code ne manda molti più del necessario.
Uno studio pubblicato da Systima ha misurato il traffico al confine API con un proxy di logging.
Su un task di una riga ("Reply with exactly: OK"), Claude Code invia circa 33.000 token prima che il prompt dell'utente arrivi al modello. OpenCode, a parità di modello (Sonnet 4.5), ne invia circa 7.000. Il rapporto è 4,7x.
Il costo delle definizioni
Il grosso non è il system prompt: sono le definizioni dei tool. 27 tool per Claude Code (inclusi CronCreate, Monitor, Task, worktree management) contro 10 di OpenCode. Ma il punto non è quanti tool hai.
Quei 33.000 token vengono rispediti a ogni turno di conversazione, e occupano un sesto di una finestra di contesto da 200K prima ancora che una riga di codice entri nella chat.
Con la configurazione reale la cosa peggiora:
- Un file
CLAUDE.mdda 72 KB aggiunge ~20.000 token per richiesta - Cinque server MCP modesti aggiungono 5.000-7.000 token a ogni turno
- Con 11 MCP server e un instruction file reale, OpenCode arriva a 90.000 token sul primo cold-cache write
- I subagenti moltiplicano tutto: un task da 121.000 token fatto direttamente ne consuma 513.000 con due subagenti: un fattore 4,2x
C'è un dettaglio che fa la differenza. Claude Code riscrive la cache dei prompt a metà sessione, run dopo run. Nello studio Systima, sullo stesso task di riepilogo file, Claude Code ha scritto 53.839 token di cache contro i 1.003 di OpenCode: fino a 54x in più.
Cache write che si pagano a premio (1,25x il costo base), e che rivelano un'instabilità nel prefix che OpenCode non ha: i suoi prefix erano byte-identici in ogni run catturata.
Il pattern: due tool, due meccanismi, stesso risultato
Confrontiamo i due casi.
Policy contro architettura
Grok Build carica l'intero repository per policy: il binario contiene crate Rust chiamate xai-data-collector, file_access_tracker, circuit_breaker_observer. C'è un coordinatore in background che prepara before_codebase.tar.gz e after_codebase.tar.gz a ogni turno di conversazione. È un meccanismo intenzionale, attivo di default, non documentato nel setup, immune all'opt-out per il miglioramento del modello.
Claude Code invia molto più del necessario per architettura: il suo system prompt varia in base al modello (più pesante su Sonnet, più snello su Fable 5), le definizioni dei tool includono un'intera suite di orchestrazione che pochi task richiedono, e il prefix instabile costringe a cache write ripetute. Non è un collettore nascosto: è un design che non è stato ottimizzato per mandare solo ciò che serve.
Il risultato è lo stesso: entrambi i tool trasmettono più dati di quanto l'utente medio immagini, e lo fanno in modi che non sono ovvii né dall'interfaccia né dalla documentazione di primo livello.
Cosa puoi fare oggi
Grok Build: kill switch verificati
Esistono kill switch verificati. Il repository grok-build-privacy-hardening ha testato ogni impostazione disponibile su grok 0.2.93. I risultati:
[harness] disable_codebase_upload = truein~/.grok/config.tomlè un veto duro alla fine della pipeline di upload. Funziona anche con upload forzati via env: nei log comparerepo_state.upload.skip reason=disable_codebase_uploadcon zero codebase in coda.- Per il canale session-trace (quello che trasporta i
.env), la precedenza è env > config > remoto.GROK_TELEMETRY_TRACE_UPLOAD=falsevia shell wrapper funziona, ma solo per le invocazioni che passano dal wrapper. Le chiavi TOML[features] telemetry = falsee[telemetry] trace_upload = falsecoprono invece tutti i percorsi di invocazione, a patto che l'ambiente sia pulito (nessuna variabile d'ambiente che le sovrascriva). - Il repo include
verify.sh, Esegue due probe adversariali e restituisce exit code 0 solo se le protezioni sono attive e confermate. Rilanciatelo dopo ogniauto_update.
Attenzione: auto_update = true è attivo di default. Un aggiornamento può cambiare la semantica delle chiavi senza preavviso.
Claude Code: audit e trasparenza
Per Claude Code la mitigazione è meno binaria ma concreta:
- Audit del file di istruzioni: un CLAUDE.md da 72 KB aggiunge 20.000 token a ogni richiesta. Chiediti se tutto quel contenuto serve davvero a ogni turno.
- Taglia i server MCP che non usi: ogni server aggiunge 1.000-1.400 token a richiesta. Cinque server sono 5.000-7.000 token che si accumulano turno dopo turno.
- Considera OpenCode: lo studio Systima mostra che su task identici, con lo stesso modello, OpenCode consuma sistematicamente meno token e ha cache stabili. Non è sempre la scelta giusta, ma per task dove la suite di orchestrazione di Claude Code non serve, il risparmio è evidente.
- Logga le chiamate API: un proxy di logging tra il tool e l'endpoint del modello è l'unico modo per sapere davvero cosa sta partendo. Lo studio Systima l'ha fatto con 200 righe di Node.
Chi vuole il massimo controllo può già usare modelli locali. Con llama.cpp e modelli come Gemma-4-26B o Qwen 3.5-27B su hardware consumer (24 GB VRAM, 32 GB RAM), si ottiene un'assistenza alla programmazione senza che una singola riga di codice lasci la macchina. Non battono i modelli cloud su task complessi, ma per molti flussi di lavoro quotidiani sono più che sufficienti.
Il prezzo della potenza
Grok Build e Claude Code risolvono problemi reali, nessuno lo mette in dubbio. La questione è un'altra: siamo disposti a pagare il prezzo in privacy per quella potenza, e quel prezzo ci è stato comunicato onestamente?
Nel caso di Grok Build, la risposta sulla trasparenza è no. Un meccanismo che carica l'intero repository, inclusi file che l'agente non legge e .env non redatti, su un bucket GCS non documentato nel setup, immune all'opt-out visibile all'utente, non è trasparente. È un comportamento che l'utente ha il diritto di conoscere prima di lanciare il primo prompt.
Nel caso di Claude Code, il problema è più sottile: nessuno ti nasconde un bucket, ma il costo in token, e quindi in dati trasmessi, è talmente alto e opaco che pochi sviluppatori sanno davvero cosa stanno inviando a ogni turno. Lo studio di Systima è il primo a misurarlo con questo rigore, e i numeri dovrebbero far riflettere chiunque usi Claude Code in produzione.
La buona notizia è che le mitigazioni funzionano. Per Grok Build, i kill switch sono attivi oggi, su questa versione, con queste chiavi. Per Claude Code, un audit della configurazione può ridurre drasticamente il volume di token. Ma funzionano finché le controlli tu. E in questo settore, nulla garantisce che le cose non cambino la prossima settimana.
Per approfondire
262588213843476
L'analisi completa di cereblab con tutti gli artefatti, gli SHA-256 e il metodo riproducibile per catturare il traffico di Grok Build.
Systima
Lo studio di Systima che misura il costo in token di Claude Code rispetto a OpenCode su task identici, con proxy di logging e audit chain.
wetlink
Kill switch verificati per Grok Build CLI, con script harden.sh e verify.sh per confermare che le protezioni funzionino sul proprio binario.
cereblab
Il repository per riprodurre l'analisi wire-level sul proprio ambiente, con canary file e comandi pronti.
xAILa documentazione ufficiale xAI per il pinning delle policy enterprise, citata nel repo di hardening come alternativa per ambienti con requisiti di conformità.
