Grok Build CLI tiše nahrává celé repozitáře na cloud, varuje bezpečnostní analýza

Nezávislý bezpečnostní výzkumník z Cereblab (@cereblab) provedl reprodukovatelnou analýzu síťového provozu (wire-level teardown) nástroje Grok Build CLI verze 0.2.93 od společnosti xAI Elona Muska. K analýze použil mitmproxy a kompletní výsledky zveřejnil formou GitHub Gistu . Analýza odhalila tři zásadní bezpečnostní chyby, které jsou v přímém rozporu s marketingovým označením „local-first“ a porušují očekávání vývojářů ohledně ochrany jejich dat.

Chování při exfiltraci dat odporuje marketingovému označení „Local-First"

Výzkumník identifikoval dvě zcela odlišné datové cesty, jimiž data opouštěla vývojářův počítač :

• Kanál modelových dotazů (

  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í.
• Úložný kanál (

  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ů .

Typy utajovaných údajů a souborů přenášených bez redakce

• Soubory .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 . V kontrolovaných testech se 48 KB soubor s databázovými přihlašovacími údaji a API klíči objevil v request body v čitelné podobě .
• Každý sledovaný soubor v repozitáři a celá git historie (všechny commity, větve, tagy) byly zabaleny a nahrány . To znamená, že i stará tajemství, která byla commitnuta před měsíci a později rotována, mohou být stále součástí nahraných dat.
• Mechanismus nahrávání byl identifikován jako první stranou vyvinutá Rust knihovna (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/ .
• U reálné 12GB kódové báze náhodných souborů, které agent nikdy nečetl, endpoint pro ukládání přijímal nahrávky bez jakéhokoli odmítnutí na základě velikosti; jediné non-200 odpovědi byly chyby kvóty využití modelu (402/429), nikoli selhání úložiště .

Selhání vypínače soukromí

Výzkumník otestoval přepínač soukromí „Improve the model“ a zjistil, že nezastavil nahrávání .

• Po vypnutí přepínače a restartu nástroje server stále vracel nastavení

  trace_upload_enabled: true

  .
• Úložný kanál nadále přijímal dávkové nahrávky git bundle s HTTP odpovědí 200 .
• V konfiguraci harnessu existuje volba 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 .

Doporučená ochranná opatření pro postižené vývojáře

Původní výzkumník a navazující analýzy doporučují následující :

Okamžitá opatření pro týmy, které používaly Grok Build CLI na soukromých repozitářích:

• Rotujte všechny přihlašovací údaje, které kdy existovaly v jakémkoli .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 .
• Zkontrolujte git historii kvůli tajemstvím, která mohla existovat v jakémkoli minulém commitu – CLI odeslalo celou historii .
• Počítejte s tím, že data byla uložena, nejen přenesena – server vrátil HTTP 200 u všech požadavků na uložení, čímž potvrdil jejich přijetí .
• Zeptejte se xAI, zda byl bucket smazán, jaká měl přístupová oprávnění a zda se na něj vztahovala Smlouva o zpracování dat (DPA) – v době zveřejnění nebyla žádná publikována .

Architektonická opatření pro jakéhokoli coding agenta:

• Spouštějte agenty v kontejnerech/VMech s připojeným pouze adresářem s úkolem, bez domovského adresáře, SSH agenta, Docker socketu a adresářů s cloudovými přihlašovacími údaji .
• Zaveďte egress kontroly: povolte endpointy pro inferenci modelů a autentizaci, ale zablokujte přímé nahrávání na generické object storage. Upozorněte na přenosy přesahující 100 MB .
• Používejte packet capture na úrovni celého hostitele, DNS logování a síťovou telemetrii koncových bodů k detekci nahrávání procesy na pozadí, které by jinak unikly čítačům bytů v popředí .
• Testujte minimální a maximální prompty pod dohledem packet capture – případy, kdy je agentovi řečeno, aby nečetl soubory, jsou klíčové pro odhalení exfiltrace nad rámec kontextového okna .
• Proveďte alespoň tři promptové scénáře: (1) „odpověz OK, nečti žádné soubory", (2) přečti jeden konkrétní soubor, (3) zkontroluj programovací jazyk projektu – a poté porovnejte počet bytů na jednotlivých endpointech .