許多開發者在嘗試 AI 程式碼助手（AI Coding Agents）時，習慣將其視為本地工具，認為只有在 AI 讀取特定檔案時才會將資料傳送到雲端。然而，最近關於 xAI 推出的 Grok Build CLI 工具的分析揭露了一個嚴重的隱私風險：該工具在執行任務時，不僅上傳了 AI 實際讀取的檔案，而是將整個 Git 儲存庫（Repository）包含完整的提交紀錄（Commit History）全部上傳至 xAI 的雲端儲存空間。
這對工程師來說是一個重要的警訊，因為這意味著即使你告訴 AI 不要讀取某個檔案，或者該檔案目前不在工作目錄中，只要它存在於 Git 紀錄裡，就有可能被上傳。
理解 Git Bundle 與上傳機制
在這次事件中，研究員發現 Grok Build 使用了一種獨立於模型對話之外的通道來傳輸資料。通常我們認為 AI 助手運作的流程是：使用者下指令 $\rightarrow$ 助手讀取必要檔案 $\rightarrow$ 將內容傳給模型 $\rightarrow$ 模型回傳結果。
但 Grok Build 的行為是將整個 Git 儲存庫打包成一個 Bundle（一種將 Git 紀錄打包成單一檔案的格式）並上傳到 Google Cloud Storage。研究數據顯示，在一個 12 GB 的儲存庫中，模型對話僅產生約 192 KB 的流量，但儲存通道卻傳輸了 5.10 GiB 的資料，兩者相差近 27,800 倍。這證明了工具在背景悄悄地將大量不需要的本地資料同步到了伺服器。
隱私設定的誤區：訓練選項不等於傳輸控制
許多開發者會開啟 Improve the model（改善模型）的關閉選項，認為這樣就能保護隱私。但在這次案例中，即使關閉了該選項，Grok 依然會上傳儲存庫。
這裡涉及一個關鍵的技術概念區分：訓練控制（Training Opt-out）與資料傳輸控制（Data Transmission Control）。 訓練控制決定的是你的資料是否會被用來優化未來的模型版本；而傳輸控制決定的是資料是否會離開你的電腦。在 Grok Build 的設計中，這兩者是分開的，但使用者介面僅提供了訓練控制的開關，讓開發者誤以為資料不會被上傳。
機密資訊洩漏的實務影響
這次事件最危險的地方在於對機密資訊（Secrets）的處理。研究發現，當 Grok 讀取包含 API 金鑰或資料庫密碼的 .env 檔案時，這些內容會以明文形式直接傳送到伺服器，且完全沒有經過遮罩（Redaction）處理。
更嚴重的是 Git 歷史紀錄的風險。在實務開發中，我們經常不小心將金鑰 commit 到 Git 中，隨後發現錯誤並在下一版將其刪除。雖然在目前的檔案樹中看不到這些金鑰，但它們永遠存在於 Git 的歷史紀錄（Commit History）中。由於 Grok Build 上傳的是整個儲存庫 Bundle，這些被刪除的舊金鑰會被完整地重新上傳到雲端。
目前的狀態與應對建議
xAI 在發現問題後，透過伺服器端的設定（Server-side switch）關閉了此功能，而非發布客戶端更新。這意味著開發商可以隨時在不通知使用者的情況下重新開啟此功能。
對於曾經使用過此類 AI 工具的工程師，建議採取以下安全措施：
首先，不要依賴工具內建的隱私開關，應假設所有經過 AI 助手讀取的檔案都已上傳。
其次，立即輪換（Rotate）所有可能外洩的憑證。這包括目前儲存庫中的金鑰，以及曾經出現在 Git 紀錄中但後來被刪除的舊金鑰。
最後，重新審視 .gitignore 的使用。雖然這次事件中被 gitignore 忽略且未 commit 的檔案沒有被上傳，但這再次提醒我們，任何進入 Git 追蹤範圍的資料都應被視為潛在的公開資料。
來源：thehackernews.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。