Grok Build 未清楚提示就上傳完整 Git 紀錄，受影響 credential 要即刻換

一句「OK」，完整 repo 照樣走

iThome 報道，Grok Build 曾經喺未有清楚提示之下，上傳開發者嘅完整 Git 程式庫。CEREBLAB 原始披露測試 0.2.93 版時，個 agent 明明只收到「回覆 OK，唔好開任何檔案」呢個 prompt，背景程序仍然打包 repo。研究人員由網絡流量抽返個 Git bundle，clone 後搵得返 agent 冇讀過嘅 tracked file、47 個檔案同 4 個 commit。呢份證據確認咗資料離開電腦，server 亦成功收到包含完整 history 嘅內容；佢冇證明 xAI 拎過啲 code 訓練模型，亦冇覆蓋所有帳戶同設定組合。

同一份研究另用 12 GB 隨機資料 repo 測試，model request 總量只得約 192 KB，截取停止前 /v1/storage 已送走至少 5.10 GiB，而且錄得嘅 storage requests 全部回傳 HTTP 200。研究人員亦發現，當 Grok 讀取一個已納入 Git 嘅測試 .env，入面假 API key 同 database password 會原樣出現喺 model request 同 session archive。實驗只確認 tracked files、完整 Git history，同 agent 實際讀過嘅檔案內容會送出，唔應該推論所有 gitignored 檔案都一定上傳。

Git history 點解特別危險

開發者成日以為刪咗 .env、換走 config，再 commit 一次就處理完。Git 其實仲留住舊版本；只要 key、cloud credential、database connection string、客戶測試資料或者內部 URL 曾經入過 commit，完整 bundle 就有機會帶埋走。就算 working tree 而家乾乾淨淨，幾個月前刪咗嘅 secret 仍可喺 history 還原。GitHub 官方指引都叫開發者先撤銷或者輪換 credential，再考慮重寫 history；單靠刪檔同 force-push，阻止唔到已經流出嘅 key 繼續生效。

停止上傳、承諾刪除、證實已刪要分開

停止上傳： CEREBLAB 喺 7 月 13 日用同一個 0.2.93 binary 連續重測六次，/v1/settings 已改為 disable_codebase_upload: true 同 trace_upload_enabled: false，期間冇再見到完整 repo 上傳。0.2.99 嘅重測結果一樣，代表 SpaceXAI 用 server-side 開關停低咗功能。另一位研究人員其後檢查 0.2.101，見到相關傳送程式有部分重構，但核心路徑未完全移除，所以刊登一刻嘅保障仍有 server 設定成分。

承諾刪除： SpaceXAI 官方回應話，已開 ZDR 嘅 team 唔會保留 code 或 trace，API key 用法亦會跟隨 ZDR 設定；一般帳戶就可用 /privacy 關閉資料保留同要求刪除已同步資料。馬斯克再公開承諾，會清除事件前上傳嘅所有用戶資料。呢啲係官方政策聲明，交代咗公司話會點做，但本身唔構成刪除完成嘅技術證據。

已證實刪除： 截至 7 月 15 日，SpaceXAI 未公布受影響帳戶數目、repo 數量、保存時間、刪除時間表，亦未提供第三方審核、逐戶通知或者可驗證嘅清除報告。備份、複本同衍生資料有冇一併處理，官方回應同樣冇交代。現階段只可以寫成「上傳已停止、公司承諾刪除」，未可以當舊資料已經獨立證實刪清。

ZDR 到底包邊啲人

ZDR 最容易俾人講闊。SpaceXAI 企業部署文件寫明，ZDR 係 team 層級控制，team 或 enterprise 啟用後，Grok Build 嘅 prompt、code 同回應先唔會喺 inference layer 留存。官方話 API key 會尊重 ZDR 設定，合理解讀係 key 跟所屬 team 嘅狀態，唔代表所有個人帳戶一用 API key 就自動有零保留。至於一般帳戶嘅 /privacy opt-out，CEREBLAB 用 0.2.99 做 A/B 截取，兩邊仍送出相若嘅 model request、session trace 同 telemetry；分別主要係 trace endpoint 由 HTTP 200 變成 204。所以 /privacy 管 server 點保留資料；完整 repo 上傳就由另一個 server flag 停低。

用過 Grok Build，可以點處理

先列出曾經用 Grok Build 開過嘅 repo，尤其係 server 關閉上傳前跑過 0.2.93 或同時期版本嗰批。可喺 ~/.grok/logs/unified.jsonl 搜尋 trace.upload.decision，再睇 uploads_enabled 有冇出現 true；不過本機 log 保留期有限，搵唔到紀錄只代表現有 log 冇證據，排除唔到較舊 session。跟住要掃描 working tree、所有 branch、tag 同 Git history，搵 API key、cloud access key、service-account credential、database password、connection string、SSH deploy key、webhook secret 同簽署 token。

任何仍然生效或者狀態唔明嘅 secret，都應該先撤銷舊 credential，再開新 credential、更新 deployment 同查 access log。Cloud console、database、source hosting、CI/CD 同付款紀錄都要睇有冇異常存取；涉及客戶資料或者公司私有原始碼，就要跟內部保安事故程序處理。輪換完成後先協調團隊重寫 Git history，避免舊 clone 再推返敏感資料。一般帳戶亦可以開 /privacy opt-out，企業 team 就確認 ZDR 已開，但兩樣都代替唔到 credential rotation。

Coding agent 嘅權限畫面未包晒資料流

今次反映評估 coding agent 時，有一點好容易睇漏：畫面上拒絕 agent 讀某個檔案，只限制 model 嘅工具操作，背景資料收集程序仍可能行另一條路。Grok Build 同時有本機讀檔權限、command execution、遙距 feature flag、session trace 同上載 pipeline；只睇 prompt、sandbox 或模型私隱條款，會漏咗 CLI 本身嘅供應鏈風險。公司 IT 團隊要留意 egress traffic、managed policy、secret scanning 同版本更新，敏感 repo 最好先隔離。下一步要睇 SpaceXAI 會唔會交代影響範圍、永久關閉方式，同提供可核實嘅刪除結果。

參考來源

• iThome — Grok Build被發現偷偷把用戶整個程式庫上傳到雲端，馬斯克承諾將刪除 — original report
• CEREBLAB：Grok Build 0.2.93 網絡分析 — 原始技術披露，提供 Git bundle、流量截取、測試版本同證據限制
• CEREBLAB：/privacy opt-out A/B 測試 — 核對 0.2.99 嘅資料傳送、server 回應同保留設定分別
• Grok Network Monitor — 核對 0.2.99 同 0.2.101 嘅 server flag、傳送程式路徑同本機 log 檢查方法
• SpaceXAI 官方回應 — 官方交代 ZDR、API key 同 /privacy 嘅政策說法
• 馬斯克刪除資料承諾 — 確認刪除舊上傳資料嘅公開承諾，唔代表刪除已獨立證實完成
• SpaceXAI：Grok Build 企業部署文件 — 官方文件界定 ZDR 係 team 層級設定，同交代資料生命週期
• GitHub：移除 repository 敏感資料 — 支援先撤銷或輪換 secret、再處理 Git history 嘅保安建議

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