Grok Build CLI îți urcă tot codul și secretele pe serverele xAI — chiar și cu opt-out activat

Grok Build CLI — tool-ul oficial de coding de la xAI (compania lui Elon Musk, cunoscuta si ca SpaceXAI) — iti urca intregul repository de cod pe serverele companiei. Nu doar fisierele pe care le citeste agentul. Totul. Fisiere .env cu parole si API keys, istoricul git, fisiere plantate pe care agentul a fost instruit explicit sa nu le deschida. Toate ajung pe Google Cloud Storage. Si se intampla chiar si cand dezactivezi optiunea „Improve the model”.

Pe 12 iulie 2026, cercetatorul independent de securitate AI @cereblab a publicat o analiza completa, verificabila, cu traficul de retea interceptat prin mitmproxy. Concluziile sunt clare: Grok Build CLI versiunea 0.2.93 urca codul tau pe serverele xAI prin doua canale separate, fara sa te informeze, fara sa ofere un opt-out real.

Ce vei gasi in acest articol:

• Ce a descoperit cercetatorul — date exacte, dimensiuni, endpoint-uri, tot traficul de retea
• Cele trei descoperiri principale — upload-ul verbatim al fisierelor, upload-ul intregului repository, si destinatia reala (Google Cloud, nu AWS)
• De ce opt-out-ul nu functioneaza — si ce controleaza de fapt setarea „Improve the model”
• Ce alte scurgeri mai are Grok Build CLI — telemetrie third-party, bug-ul cu disk-ul
• Cum te protejezi — checklist concret pentru developeri
• Comparatie cu alte tool-uri de coding AI — Claude Code, Cursor, Copilot

Ce este Grok Build CLI si cum il instalezi

Grok Build CLI este echivalentul xAI pentru Claude Code de la Anthropic sau GitHub Copilot CLI de la Microsoft. Este un agent de coding care ruleaza in terminalul tau, iti citeste proiectul, si iti scrie cod pe baza instructiunilor tale in limbaj natural.

Se instaleaza cu un script bash de pe x.ai/cli/install.sh. Odata instalat, accesezi modelul Grok direct din terminal si il poti intreba sa repare bug-uri, sa rescrie functii, sa analizeze arhitectura proiectului. Practic, un ChatGPT specializat pe cod, care iti vede fisierele.

Problema e exact asta: iti vede fisierele. Si nu doar le vede — le urca pe servere.

Pentru context, daca vrei sa intelegi mai bine ecosistemul tool-urilor AI de coding si riscurile asociate, poti citi articolul nostru despre Claude Code si markerii ascunsi de steganografie si despre cum Alibaba a interzis Claude Code angajatilor.

Descoperirea 1: Continutul fisierelor .env este transmis verbatim

Cercetatorul a folosit mitmproxy — un instrument standard pentru interceptarea traficului HTTPS — pentru a vedea exact ce date ieseau din calculatorul sau catre serverele xAI.

Rezultatul: de fiecare data cand Grok Build CLI citieste un fisier din proiectul tau, continutul acelui fisier este transmis catre xAI exact asa cum e, fara nicio redactare, fara nicio mascare.

Doua canale de transmitere:

Endpoint	Ce trimite	Format
POST /v1/responses	Continutul fisierului citit in timpul conversatiei	JSON (model turn)
POST /v1/storage	Arhiva completa a sesiunii	Binary (session_state)

Ce inseamna asta concret? Daca ai un fisier .env in proiectul tau cu asa ceva:

API_KEY=sk-abc123xyz-secret-key
DB_PASSWORD=ParolaMeaSecreta123!
AWS_SECRET=AKIAIOSFODNN7EXAMPLE

…iar Grok citeste acest fisier (fie ca ii ceri tu, fie ca il acceseaza automat in timpul analizei proiectului), continutul ajunge verbatim pe serverele xAI. Nicio masca, nicio inlocuire cu ***, nimic.

Asta nu e o scurgere ipotetica. E comportamentul demonstrat si masurat al tool-ului.

Descoperirea 2: Intregul repository este urcat, indiferent de ce citeste agentul

Aceasta este cea mai grava descoperire din cercetare.

Cercetatorul a deschis un repository in Grok Build CLI si a dat urmatorul prompt: „reply OK, do not read any files” — adica instructiunea explicita ca agentul sa nu citeasca niciun fisier.

Ce s-a intamplat? Grok Build CLI a urcat intregul repository pe server. Nu doar fisierele pe care le-a citit (pentru ca nu a citit niciunul). Tot repository-ul. Fiecare fisier urmarit de git. Plus istoricul complet git.

Testul canary

Pentru a demonstra ca upload-ul includea si fisiere pe care agentul nu le-a accesat, cercetatorul a plantat un fisier numit never_read_canary.txt in repository. Agentul a fost instruit explicit sa nu il deschida.

Fisierul a fost recuperat verbatim din arhiva upload-ata pe server. Adica Grok Build CLI l-a urcat fara sa il citeasca vreodata, pur si simplu pentru ca exista in repository.

Volumul transferului

Pe un repository de 12 GB, endpoint-ul /v1/storage a transferat 5,10 GiB de date. Transferul s-a facut in 73 de chunk-uri de aproximativ 75 MB fiecare, toate cu status HTTP 200 (succes), zero esecuri.

Formatul upload-ului: un git bundle — un fisier care contine tot repository-ul, inclusiv istoricul git. Practic, o copie completa a proiectului tau.

De ce e grav

Upload-ul intregului repository inseamna ca:

• Codul proprietar al companiei tale este pe serverele xAI
• Istoricul git — inclusiv commit-uri sterse, branch-uri abandonate, si comentarii vechi — este pe serverele xAI
• Fisierele de configurare cu secrete, tokeni, si parole sunt pe serverele xAI
• Orice fisier din repository, inclusiv cele pe care nu le-ai cerut niciodata sa fie accesate, este pe serverele xAI

Totul se intampla fara sa stii, fara sa fii intrebat, si fara sa existe vreo optiune reala care sa opreasca acest comportament.

Descoperirea 3: Destinatia este Google Cloud Storage, nu AWS S3

Cercetatorul a analizat binarul Grok Build CLI si a gasit strings (secvente de caractere citibile) care indicau o destinatie surprinzatoare: nu AWS S3 (cum ar fi fost de asteptat pentru o companie americana de tech), ci Google Cloud Storage.

Bucket-ul: grok-code-session-traces

Confirmarea a venit din fisierele metadata.json generate in timpul upload-ului, care contineau fileId-uri de forma:

gs://grok-code-session-traces/...

Prefixul gs:// este specific Google Cloud Storage. Nu S3 de la Amazon, nu Azure Blob Storage de la Microsoft. Google Cloud.

Asta inseamna ca xAI nu doar ca iti urca codul, dar il stocheaza pe infrastructura unui tert — Google — ceea ce adauga un strat suplimentar de preocupari legate de cine poate accesa datele si in ce conditii.

De ce opt-out-ul nu functioneaza

Grokk Build CLI are in setari o optiune numita „Improve the model”. Presupunerea logica e ca daca dezactivezi aceasta optiune, codul tau nu mai este folosit pentru imbunatatirea modelului — si, prin extensie, nu mai este trimis catre servere.

Conform cercetarii, aceasta presupunere este gresita.

Setarile serverului returneaza intotdeauna:

{
  "trace_upload_enabled": true,
  "upload_enabled": true
}

Indiferent de cum setezi „Improve the model” in interfata.

Ce face de fapt aceasta optiune? Guverneaza antrenarea — adica daca datele tale sunt folosite pentru a imbunatati modelul Grok. Nu controleaza daca datele sunt uploadate.

Practic:

Ce crezi ca se intampla	Ce se intampla de fapt
Dezactivezi „Improve the model”	Se dezactiveaza antrenarea
Crezi ca nu se mai upload-eaza nimic	Totul se upload-eaza in continuare
Crezi ca optiunea controleaza transmiterea	Optiunea controleaza doar ce se intampla DUPA transmitere

Acest tip de opt-out este problematic pentru ca induce in eroare utilizatorul. Tu crezi ca ai oprit scurgerea de date, cand de fapt ai oprit doar un pas ulterior din lant. Datele tale sunt deja pe servere.

Telemetrie third-party si bug-ul cu disk-ul

Pe langa upload-ul codului catre xAI, cercetatorul a mai gasit doua probleme.

Telemetrie la terti

Grok Build CLI trimite date de telemetrie catre doua terte parti:

• api.mixpanel.com — platforma de analytics. Trimite evenimente despre cum folosesti tool-ul (ce comenzi rulezi, cat de des, cat timp).
• grok.com — trimite evenimente de utilizare catre site-ul principal Grok.

Aceasta telemetrie ruleaza in fundal, fara sa iti ceara consimtamantul explicit si fara sa existe o optiune clara de dezactivare in interfata.

Bug-ul upload_queue

Un bug separat, dar la fel de problematic: directorul ~/.grok/upload_queue poate stoca aproximativ 3 GB per sesiune. In conditii de sarcina intensa (proiecte mari, multe fisiere), acest director poate creste la zeci de GB, epuizand spatiul de pe disc.

Pentru developerii care lucreaza pe laptopuri cu SSD-uri de 256 GB sau 512 GB, asta inseamna ca Grok Build CLI poate umple discul fara sa iti dai seama. Am scris deja despre un bug similar la OpenAI Codex, care scrie 640 TB de loguri pe an si iti poate distruge SSD-ul.

Cum te protejezi — checklist pentru developeri

Daca ai folosit sau inca folosesti Grok Build CLI, iata ce trebuie sa faci:

Comparatie cu alte tool-uri de coding AI

Nu toate tool-urile de coding AI se comporta la fel. Iata cum se comparta Grok Build CLI cu alternativele:

Diferenta principala: Grok Build CLI este singurul tool care urca intregul repository fara sa iti ceara permisiunea si fara sa ofere un opt-out real. Celelalte tool-uri au propriile riscuri, dar macar iti ofera transparenta si control.

Ce inseamna pentru developerii din Romania

Daca lucrezi la o companie din Romania si folosesti Grok Build CLI pe proiecte comerciale, situatia e serioasa.

GDPR: Daca proiectul tau contine date personale (baze de date cu utilizatori, formulare, CRM), aceste date sunt acum pe serverele xAI si Google Cloud. Asta poate constitui o incalcare a GDPR, care prevede ca datele personale nu pot fi transferate catre tari terte fara garantii adecvate. Statele Unite au un cadru de transfer (EU-US Data Privacy Framework), dar xAI nu este pe lista companiilor certificate.

NDA si contracte: Daca ai semnat un NDA (acord de confidentialitate) cu un client sau angajator, iar codul acestuia a fost uploadat pe serverele xAI prin Grok Build CLI, poti fi in incalcare a NDA-ului. Faptul ca nu ai stiut ce face tool-ul nu te absolve — esti responsabil pentru ce software folosesti pe datele altora.

Secrete de productie: Daca proiectul tau contine API keys pentru servicii de productie (Stripe, AWS, baze de date), acele chei sunt acum pe servere externe. Singura solutie sigura este sa le rotesti (sa generezi altele noi si sa dezactivezi cele vechi).

Pentru mai multe sfaturi despre cum iti protejezi datele in relatia cu AI-ul, citeste articolul despre de ce AI chatbots nu sunt prietenii tai si cum te protejezi.

Ce ar trebui sa faca xAI

Fara sa presupunem rea-vointa, iata ce ar trebui sa faca xAI pentru a rezolva aceasta situatie:

1. Documentare clara: Comportamentul de upload trebuie documentat in materialele de instalare si in interfata. Utilizatorul trebuie sa stie exact ce se intampla cu datele lui.

2. Opt-out real: O optiune care opreste cu adevarat upload-ul codului, nu doar antrenarea. Fara exceptii, fara ambiguitati.

3. Filtrare automata: Tool-ul ar trebui sa detecteze si sa nu transmita fisiere care contin secrete — .env, .pem, id_rsa, credentials.json, etc.

4. Selectie granulara: Utilizatorul ar trebui sa poata alege ce directoare si fisiere sunt accesibile agentului, nu sa dea acces la tot repository-ul.

5. Audit public: Un audit de securitate independent care sa confirme sau sa infirme comportamentul descris si masurile corective.

Ce urmeaza

Descoperirea cercetatorului @cereblab a fost replicata pe doua repository-uri diferite, ambele cu acelasi rezultat. Asta inseamna ca nu e un bug izolat — e un comportament sistematic al tool-ului.

Momentan, xAI nu a emis nicio declaratie oficiala despre aceste descoperiri. Articolul va fi actualizat cand sau daca xAI raspunde.

Intre timp, daca folosesti sau te gandeai sa folosesti Grok Build CLI, sfatul meu e simplu: nu il folosi pe proiecte care contin secrete, cod proprietar, sau date personale. Daca l-ai folosit deja, schimba-ti secretele si informeaza-ti echipa.

Pentru ca problema nu e doar la xAI — e un pattern mai larg in care tool-urile AI de coding primesc acces la tot proiectul tau fara sa iti explice clar ce fac cu datele. Am vazut asta si cu Claude Code si steganografia, si cu Alibaba care a interzis Claude Code. Fiecare incident ne arata ca trebuie sa fim mai atenti la ce permisiuni dam acestor tool-uri.

Si daca vrei sa intelegi mai bine cum functioneaza ecosistemul AI de la xAI, poti citi si articolul nostru despre Grok 4.5, noul model AI de la SpaceXAI.

Grok Build CLI imi urca si fisierele din .gitignore?

Da. Conform cercetarii, Grok Build CLI urca intregul repository sub forma de git bundle, care include toate fisierele urmarite de git. Daca un fisier .gitignore a fost vreodata comis in git (adica a existat in repository inainte sa il adaugi in .gitignore), el poate fi in istoricul git si poate fi uploadat.

Mai mult, chiar daca un fisier e in .gitignore acum, testul cu never_read_canary.txt arata ca tool-ul nu respecta restrictii de genul „nu citi acest fisier”. Nu exista garantii ca fisierele din .gitignore sunt excluse din upload.

Am folosit Grok Build CLI o singura data. Sunt afectat?

Da, daca in acea sesiune ai avut deschis un proiect cu secrete. Fiecare sesiune genereaza un upload catre endpoint-ul /v1/storage care contine repository-ul sub forma de git bundle. Daca proiectul tau continea fisiere .env, API keys, sau alte secrete, acelea sunt acum pe serverele Google Cloud in bucket-ul grok-code-session-traces.

Verifica directorul ~/.grok/ pentru arhivele de sesiune si schimba toate secretele expuse.

Optiunea Improve the model chiar nu face nimic?

Nu, nu face „nimic” — dar controleaza doar un singur lucru: daca datele tale sunt folosite pentru antrenarea modelului. Upload-ul codului pe servere se intampla indiferent de setare. Serverul returneaza intotdeauna trace_upload_enabled: true si upload_enabled: true, conform cercetarii.

Deci da, optiunea face ceva — dar nu ce crezi tu. Ea nu opreste transmiterea codului tau catre xAI si Google Cloud.

Ce tool-uri de coding AI sunt sigure de folosit?

Niciun tool de coding AI nu este 100% sigur din perspectiva privacy-ului, dar unele sunt mai transparente si mai controlabile decat altele. Cauta tool-uri care:

• Documenteaza clar ce date trimit si unde
• Ofera opt-out real care opreste transmiterea, nu doar antrenarea
• Filtreaza automat fisierele cu secrete
• Permit selectia granulara a fisierelor accesibile
• Ruleaza local (modele open-source ca Qwen sau CodeLlama, ruland prin Ollama — vezi ghidul nostru despre modele AI locale pentru programare)

Alternativa cea mai sigura? Rulezi modelul local. Vezi articolul despre cum rulezi AI gratuit pe calculatorul tau.

Pot da xAI in judecata pentru asta?

Depinde de jurisdictie si de circumstante. In UE/GDPR, daca datele personale au fost transferate fara consimtamant informat si fara garantii adecvate de protectie, poti depune plangere la ANSPDCP (autoritatea romana de protectie a datelor). Pentru incalcari de NDA sau contracte de confidentialitate, consulta un avocat.

Retine insa ca cercetatorul a demonstrat transmiterea si stocarea, nu antrenarea pe date. Dovada ca xAI foloseste datele tale pentru antrenarea modelului ar fi necesara pentru anumite tipuri de actiuni legale.