安全研究機構 Cereblab 近日發布了一份 wire-level 流量分析報告，揭露 xAI 官方程式碼助手 Grok Build CLI（v0.2.93）會在使用者毫不知情的情況下，將整個程式碼儲存庫上傳至 xAI 控制的 Google Cloud 儲存桶。受影響的不只是工作階段期間被模型讀取的檔案，而是整個 Git 儲存庫的完整內容，包括歷史提交記錄、已刪除的機密、以及使用者明確要求工具「不要開啟」的檔案，全部在使用者不知情的情況下被打包送出。
Grok Build 被抓到偷傳程式碼
研究人員 @hrkrshnn（Hari）在 X 上放出這份報告，將其定性為「帶有惡意軟體特徵的背景程式碼收集機制」，引發開發者社群軒然大波。Elon Musk 本人隨後親自出面，承諾刪除所有已上傳的使用者資料，但 xAI 至今仍未發布正式的資安通報。
SpaceXAI was caught uploading your code to its cloud.
I reversed xAI’s official Grok Build binary. In a controlled session with zero tool-calls, it uploaded the complete codebase to xAI’s storage
It ships a malware-like background code collector. https://t.co/1AjmmjiJjU
— Hari (@hrkrshnn) July 13, 2026
三條傳輸通道，兩條不該存在
Cereblab 使用 mitmproxy 攔截並記錄了工具使用期間發出的所有網路請求，分析結果揭示了三條截然不同的資料傳輸通道：
- 模型通道（預期行為）：工具將使用者要求模型讀取的檔案傳送至 Grok API，這是 AI 程式碼助手的正常運作方式
- 儲存庫上傳通道（異常行為）：整個 Git 儲存庫，含完整歷史提交記錄，被打包後以 73 個分段傳送至 Google Cloud Storage 儲存桶
grok-code-session-traces，端點為POST /v1/storage - Session trace 通道（異常行為）：包含
.env機密的完整檔案內容被傳送至 xAI 的遙測伺服器，未經任何遮蔽
最能說明問題嚴重性的是資料量的對比。在一個 12 GB 的測試儲存庫中，模型通道傳輸了 192 KB 的資料，而儲存庫上傳通道傳出了 5.10 GB，是模型所需資料量的 27,800 倍。研究人員在工具使用期間完全沒有發出任何工具呼叫（zero tool-calls），上傳行為在這個前提下依然發生。
Cereblab 還進行了跨工具比較：在相同測試條件下，Claude Code 和 Codex 均未發送任何儲存庫封存包，Gemini 在閒置測試中也沒有發現類似行為。Grok Build 是唯一一個進行整個程式碼庫收集的工具。
隱私開關是擺飾
Grok Build 介面提供的隱私設定完全沒有實際效果。研究人員測試後發現，「Improve the model」切換開關只控制資料是否用於模型訓練，並不影響上傳行為本身。伺服器持續回傳 trace_upload_enabled: true，不受本地設定影響。
另一位獨立研究人員 @arafatkatze 進一步確認，即使執行 /privacy 命令並設定 trace_upload_enabled=false，工具仍向 /v1/traces 端點發出 7,407 位元組的請求。
Grok Build is straight up malware behavior with an Apple notarized signature.
You could explicitly deny the agent permission to read a file and it would upload that exact file anyway, because a separate code path silently packed your entire repo, full Git history included, and… https://t.co/d0eIbMhice
— Ara (@arafatkatze) July 14, 2026
根據社群分析，各種無效的本地設定包括：
~/.grok/config.toml中的[telemetry] trace_upload = false被二進位檔案忽略[features] telemetry = false同樣無效- 唯一確認有效的設定是
[harness] disable_codebase_upload = true，或透過 shell 包裝器設定環境變數GROK_TELEMETRY_TRACE_UPLOAD=false
更嚴重的是，研究人員在 .env 檔案中植入了金絲雀憑證（canary credential），這是一個用來驗證資料是否外洩的假機密，並告知工具「不要開啟這個檔案」。結果，這個憑證完整地出現在捕獲到的上傳內容中，未經任何遮蔽，因為儲存庫打包機制是獨立於工具存取控制流程之外運作的。
xAI 事先知道這個功能的存在
@arafatkatze 的分析指出，Grok Build 的 Apple 簽署二進位檔案中含有 grok code session traces、after_codebase.tar.gz 和 disable_codebase_upload 等字串，顯示這套程式碼收集機制是刻意設計的功能，並非無意的漏洞。[5] 工具做了它被設計來做的事，只是沒有告知使用者。
更重要的脈絡是，xAI 在研究人員公開發現結果之後，才通過伺服器端將 disable_codebase_upload 旗標設為 true，阻止了後續的上傳行為。修復是在外部壓力下才出現，而非事先主動設計的保護機制。
xAI 官方回應：保護措施只適用於企業用戶
xAI 官方帳號 @SpaceXAI 發出聲明，聲稱使用零資料留存（Zero Data Retention，ZDR）的企業用戶「完全不留存任何程式碼或追蹤資料」，並指出 API 金鑰方式存取也會遵守 ZDR。同時，CLI 內的 /privacy 命令可停用資料留存並刪除已同步的資料。
但問題在於，ZDR 是企業方案的功能，一般個人開發者在標準版本下並沒有這層保護。換言之，在事件曝光之前，大多數使用 Grok Build 的開發者從來就不在 xAI 聲稱的保護範圍內。
Elon Musk 本人的回應則讓事態更加複雜。他先在 7 月 13 日發出推文，表示「保留一定量的資料有助於除錯」，希望使用者允許 xAI 繼續保留；隨後在同日另一則推文中承諾：「作為預防措施，SpaceXAI 此前上傳的所有使用者資料將完全、徹底地刪除，零任何留存。」兩則立場相反的公開聲明，在幾個小時內接連出現。
這不是 AI 出軌，是產品設計的選擇
在眾多技術分析中，一個重要的釐清點被反覆提及：現有證據只能證明資料被傳輸並儲存於 xAI 控制的 Google Cloud 儲存桶，無法證明 xAI 員工曾閱讀捕獲到的程式碼，也無法證明捕獲到的程式碼被用於模型訓練。
Cereblab 的報告明確界定了研究範圍，@itsJaimeMedina 的總結也強調：這起事件的核心問題是「超出合理預期的資料存取範圍」。開發者預期工具會讀取任務相關的檔案，沒有預期整個儲存庫的完整 Git 歷史會在不知情下離開本機。
@DeepThoughtAR 的評論切中要點：「有人在 xAI 建立、測試並發布了一個有這種行為的 CLI。威脅來自產品的設計決策，不是模型。」這起事件符合一個清晰的模式：出貨、被抓到、停用。旗標在有人公開之前，一直保持未設定的狀態。
使用者的自保清單
事件曝光後，社群整理出以下建議措施：
- 立即輪換金鑰：如果曾將 Grok Build 指向含有 API 金鑰、密碼或任何機密的儲存庫，應立即輪換相關憑證。有報告指出，有使用者從家目錄啟動 Grok Build，導致 SSH 金鑰和密碼管理器資料庫一併被上傳
- 執行稽核腳本：@hrkrshnn 在 7 月 14 日發布了稽核提示與 Python 腳本，可查詢本機日誌
~/.grok/logs/unified*.jsonl中repo_state.upload.start和repo_state.upload.enqueued事件，確認哪些儲存庫曾被收集 - 執行
/privacy命令：可停用留存並要求刪除已同步的資料，但需注意此命令在事件曝光後才被廣泛推薦 - 使用隔離環境：在生產儲存庫上使用任何 AI 程式碼助手之前，先在 throwaway 儲存庫搭配金絲雀機密進行測試