POST /v1/responses): sem se serializovaly soubory, které agent skutečně otevřel. To je u cloudového coding agenta očekávané chování.POST /v1/storage): celý repozitář byl nezávisle zabalen do git bundle a nahrán po ~75 MB dílcích do bucketu Google Cloud Storage s názvem grok-code-session-traces Rozdíl v objemu dat jasně dokazuje, že nahrávání nebylo řízeno tím, co agent skutečně četl. Na testovacím repozitáři o velikosti 12 GB přesunul úložný kanál 5,10 GiB dat ve 73 dávkách (všechny s HTTP odpovědí 200), zatímco kanál modelových dotazů přenesl jen 192 KB – poměr je tak přibližně 27 800 : 1 . Dokonce i při promptu „odpověz OK, nečti žádné soubory“ nástroj nahrál celý repozitář jako git bundle; klonováním zachyceného bundle bylo možné obnovit soubor (
src/_probe/never_read_canary.txt), který agent výslovně otevřít nesměl, a to včetně úplné historie git commitů .
.env obsahující API klíče, hesla do databází a další přihlašovací údaje byly přenášeny doslovně, bez jakéhokoli maskování či redakce oběma kanály xai-data-collector) přítomná přímo v binárce, se zdrojovými cestami jako crates/codegen/xai-data-collector/src/gcs.rs a crates/codegen/xai-grok-shell/src/upload/ trace_upload_enabled: true disable_codebase_upload=true, ale její vztah k chování na straně serveru není zdokumentován a výzkumníkovy testy ukázaly, že server preference klienta nerespektoval Okamžitá opatření pro týmy, které používaly Grok Build CLI na soukromých repozitářích:
.env souboru, konfiguračním souboru nebo git historii v repozitářích použitých s Grok Build, protože mohly být přeneseny a uloženy v GCS bucketu grok-code-session-traces Architektonická opatření pro jakéhokoli coding agenta: