Grok Build 曾上載完整 Git repo：用過嘅開發者應點樣檢查風險

AI coding agent 要讀 code 先做到嘢，呢點人人都知；但讀到邊、送走幾多，差距可以好大。獨立研究團隊 Cereblab 嘅封包測試 顯示，Grok Build 0.2.93 喺一般消費者帳戶下，曾經將完整 Git repository 打包送去 SpaceXAI 控制嘅 Google Cloud Storage。The Verge 報道 指 SpaceXAI 之後停咗上載，Elon Musk 亦承諾刪除之前收過嘅數據。不過受影響人數、功能開咗幾耐、數據留咗幾耐同有冇第三方睇過，暫時都冇公開答案。

封包入面見到啲咩

Cereblab 用 mitmproxy 攔截自己帳戶嘅流量，叫 CLI 只回覆 OK，同埋唔好開任何檔案。個 agent 冇讀檔，但 /v1/storage 仍然收到一個 Git bundle；研究員將封包 clone 返開，搵到事先放入去、明確叫工具唔好讀嘅 canary 檔，連 4 個 commit 同 47 個檔案嘅 history 都返晒嚟。佢哋亦喺第二個無關 repo 重現到同類結果。研究另有記錄顯示，agent 主動讀取 .env 時，假 API key 同 DB password 原文會出現喺 model request。**封包證據顯示資料的確傳咗出去，server 亦回覆 HTTP 200。**不過公開測試集中喺一個帳戶同指定版本，唔足以推論所有 Grok Build 用戶都中招。

刪咗檔，舊 commit 仲喺度

Git bundle 帶走嘅係 tracked files 同 commit history。你喺最新分支刪咗 .env，只係多咗一個刪除記錄，舊 commit 仍然保留原本內容，完整 bundle 照樣帶得走。Cereblab 嘅公開重現工具 指出，從未 commit、又有 .gitignore 排除嘅檔案冇入 bundle；曾經 track 過再刪走就另一回事。GitHub 官方指引 亦將 revoke 或 rotate secret 擺喺第一步，因為改 history 只係減少之後再俾人搵到嘅機會，已經傳出去嘅 credential 唔會跟住失效。

/privacy 管保存，完整上載由另一個旗標停低

研究團隊喺 0.2.99 再做 opt-in 同 opt-out A/B，兩邊都照送 session traces、model turns 同 telemetry；主要差別係 /v1/traces 回覆由 200 變 204，反映 server 收到後按設定唔保存。完整 repo bundle 停低，靠嘅係 /v1/settings 回傳 disable_codebase_upload: true 呢個 server 旗標。SpaceXAI 官方企業文件 本身都將 transport 同 retention 分開：prompt 同檔案內容會經 TLS 去 inference proxy，Zero Data Retention 講嘅係 session 完結後，inference layer 唔持久保存。關咗訓練用途、選咗 opt-out、開咗 ZDR，要逐項睇；三者都唔等於 client 冇傳資料。

用過 Grok Build，而家點查

實際上載時段同帳戶 rollout 未公開。如果你喺 7 月中之前用過 Grok Build，又開過有敏感資料嘅 repo，唔好用「而家停咗」作結案。先搵返 CLI 版本、使用日期、當時開過邊啲 repo 同帳戶類型，再掃晒所有 branch、tag 同舊 commit，唔好淨係掃 working tree；要列出 API key、雲端 access key、database password、SSH key、webhook secret 同簽署 key。搵到相符 credential 就當有機會傳過出去，立即 revoke 或 rotate，縮細權限，睇埋 provider audit log 有冇異常使用。涉及客戶 code 或個人資料，就交畀公司保安同合規團隊按 incident 程序評估。就算刪咗 repo、重寫 Git history，或者等公司刪走雲端副本，都仍然要 rotate credential。

揀下一隻 agent，先問清楚資料路線

今次仲拆穿一個常見誤會：agent 嘅 Read deny 同 approval 係限制 model tool call，未必限制 CLI 自己嘅 background upload。Cereblab 個測試入面，明確 deny 讀取嘅 tracked file 仍然入咗 Git bundle。團隊揀 AI coding agent 時，要問清楚 client 會送咩、送去邊個 domain、完整 repo 定按需讀檔、保存幾耐、訓練 opt-out 同 retention opt-out 點分、刪除有冇 audit 證明，管理員又可唔可以鎖死設定。限制對外連線只係最後一道防線；受測 bundle 經核心 proxy host 嘅 /v1/storage 送走，單靠 domain allowlist 未必分得開正常請求同 repo 上載。日常亦應將長效 secret 移離 repo，用短命、最小權限 credential，重要 code 放喺獨立 workspace，agent 權限亦要一齊收窄。

停用功能之後，仍然欠一份完整交代

SpaceXAI 停咗完整 codebase 上載，又承諾刪除舊數據，方向係啱；截至 7 月 15 日，外界仍驗證唔到刪除進度，亦未有完整 security advisory 交代受影響版本、帳戶範圍同第三方存取情況。用過相關版本嘅開發者，應以 credential rotation 同 audit log 排查作實際收尾；公司採購下一隻 AI coding agent，就要將 transmission、retention、training 同權限控制拆開逐項問，唔好淨係睇一個「privacy」開關。

參考來源

• The Verge — SpaceXAI’s Grok programming tool was uploading its users’ entire codebase to cloud storage — original report
• Cereblab — Grok Build CLI wire-level findings — 主要技術報告，列出受測版本、封包結果同停用旗標
• Grok Build exfiltration reproduction — 公開重現方法、canary repo、Git bundle 證據同測試限制
• Grok privacy opt-out analysis — 0.2.99 opt-in／opt-out 封包對照，分清楚 transmission 同 retention
• SpaceXAI Grok Build enterprise deployments — 官方資料傳送流程、ZDR、權限同企業設定說明
• GitHub：Removing sensitive data from a repository — 官方解釋點解 secret 要先撤銷或更換，改寫 history 唔足以解除風險

本文根據原文及公開資料整理；資料有出入時，以原文及官方資料為準。