xAI Grok Build CLI 0.2.93 線路層級分析
xAI Grok Build CLI 0.2.93 線路層級分析
執行摘要
對 xAI Grok Build CLI(版本 0.2.93)的分析顯示,該工具會將整個本機儲存庫——包括 git 歷史與未經遮蔽的機密檔案——傳送至 xAI 伺服器。這些資料會持續保存於名為 grok-code-session-traces 的 Google Cloud Storage(GCS)桶中,且上傳行為不受 AI 代理實際是否讀取檔案或使用者是否關閉「改進模型」設定的影響。
未遮蔽的機密傳輸
Grok Build 會逐字傳送它讀取的檔案內容,包括 .env 與機密檔案,且不會進行遮蔽。
當 CLI 讀取檔案以提供模型上下文時,內容會透過兩條不同的通道傳送:
- 模型回合通道(Model‑Turn Channel): 內容被序列化到
POST /v1/responses請求的主體中。 - 儲存通道(Storage Channel): 內容被打包成
session_state壓縮檔,並透過POST /v1/storage上傳。
線路層級的抓取證實,放在 .env 檔案中的金絲雀機密(例如 API_KEY=CANARY7F3A9-SECRET)會以純文字形式傳送,且伺服器回應 HTTP 200 成功狀態。
整個儲存庫的外洩
Grok Build CLI 會上傳工作區的完整快照,包含所有受追蹤檔案與完整的 git 歷史,無論代理實際讀取了哪些檔案。
從線路抓取的證據可見,模型回應通道傳送的資料量與儲存通道傳送的資料量之間存在巨大的差異。在一次測試中,使用一個 12 GB 的隨機檔案儲存庫,且明確指示代理不要讀取該儲存庫,模型回合通道僅傳送了 192 KB,而儲存通道(/v1/storage)則傳送了超過 5.10 GiB 的資料。
透過 Git Bundle 驗證
為了證明未讀取的檔案仍被上傳,研究人員在 src/_probe/never_read_canary.txt 中放置了一個唯一標記的「金絲雀」檔案。即使提示代理「回覆僅為:OK。不要讀取或開啟任何檔案」,CLI 仍透過 POST /v1/storage 將整個儲存庫上傳為 git bundle。對捕獲的 bundle 進行 git clone 後,金絲雀檔案及其唯一標記完整復原,且保留了完整的 git 歷史。
基礎設施與遙測
這些上傳的目的地是 Google Cloud Storage 桶,而非 AWS S3。
對二進位字串與捕獲的 metadata.json 檔案的分析揭示以下資訊:
- 目的地桶:
gs://grok-code-session-traces/ - API 端點: 請求會經由
cli-chat-proxy.grok.com以及直接向storage.googleapis.com進行多部份上傳。 - 遙測: CLI 會將追蹤資料發送至 Mixpanel(
api.mixpanel.com)以及 xAI 自己的事件端點(grok.com/_data/v1/events)。
政策與同意分析
關閉「改進模型」的切換不會阻止儲存庫上傳。
雖然 xAI 提供了不將資料用於模型改進的選項,但此設定僅影響訓練政策,並不阻止資料傳輸。測試證實,即使「改進模型」被關閉,CLI 仍會將整個儲存庫上傳為 git bundle,且伺服器的 /v1/settings 回應仍返回 "trace_upload_enabled": true。
此外,研究人員指出,上傳 repo_state 與 session_state 至 grok-code-session-traces 桶的機制並未在 CLI 的安裝腳本或快速入門文件中說明。
社群見解與緩解措施
技術使用者的討論凸顯了對專有代理執行器的重大隱私憂慮。
建議的緩解措施
使用者提出了多種降低使用 AI 程式碼工具時資料外洩風險的方法:
- 沙箱化(Sandboxing): 使用
bubblewrap等工具限制代理只能存取必要的專案目錄,並將敏感目錄掛載為空目錄。 - 網路隔離(Network Isolation): 透過 HTTP 代理只允許代理連線至特定 LLM 供應商的主機名稱,阻斷工具自身的遙測與儲存端點。
- 機密掃描(Secret Scanning): 部署類似
gitleaks的代理,掃描外發串流中的機密,並在送達供應商前以唯一識別碼取代。
反對意見
部分使用者認為,上傳整個程式碼庫是一種效能最佳化手段,讓模型在「思考」階段能檢視整個程式碼庫,避免頻繁的工具呼叫回客戶端,從而降低往返時間(RTT)。
"上傳整個程式碼庫的其中一個原因是,它允許模型在『思考』階段檢查程式碼庫,而不必回到客戶端執行實際的工具呼叫。"
技術附錄:來源說明
- 測試版本: grok 0.2.93
- 二進位 SHA-256:
2a97ba675bd992aa9b981e2e83776460d94f469b510c0b8efe28b50d236d767c - 方法論: 使用
mitmproxy並在 macOS 登入金鑰串中安裝受信任的 CA,以解密 HTTPS 流量並捕獲資料。