Grok Build 被曝整庫上傳：你的 SSH 金鑰，正被悄悄傳上雲

馬斯克這邊剛把 Grok Build 開源，那邊就被人扒出了一樁隱私醜聞。安全研究者 cereblab 用網路抓包工具復現了 Grok Build 0.2.93 版的行為，結果讓人後背發涼：哪怕你只讓 AI 回覆一句「OK」，它也會把整個程式碼倉庫——連同 Git 歷史裡早就刪掉的金鑰——一股腦傳上 xAI 的 Google Cloud Storage。

數字更刺眼。模型互動本身只用了約 192 KB 的任務內容，儲存通道卻一口氣上傳了 5.10 GB 資料，按 75 MB 一塊切了 73 份，比例高達實際需求的 27800 倍。上傳的是 Git 打包檔案，裡面裝著倉庫的完整提交歷史，不只是當前檔案。

最嚇人的案例來自其他使用者：有人整個使用者目錄都被開啟上傳，裡面躺著 SSH 金鑰和密碼管理器資料庫。研究還發現，即便你關掉了「改進模型」的開關，上傳行為也不會停——那個開關管的是資料「保留」，不是資料「傳送」。xAI 後來推給使用者的 /privacy 命令，也只是按會話清理 retention，並不是真正攔住上傳的那個開關。

真正攔住上傳的，是服務端一個靜默的全域性標誌 disable_codebase_upload: true，使用者 opt-in 還是 opt-out 都攔不住它重新開啟。xAI 在事件曝光後改了服務端配置，六次複測都沒再出現儲存請求，但開源出來的程式碼裡，那段上傳邏輯依然原封不動地留著。

這事給所有用雲端程式設計 Agent 的人提了個醒：Claude Code 和 Codex 都只上傳真正開啟的檔案，整倉收集是 Grok Build 獨有的行為。但更根本的是，凡是跑在雲端的工具，都會上傳它實際接觸到的檔案。如果你曾經把金鑰 commit 進倉庫、後來又刪了，別以為就安全了——Git 歷史裡還在。

把視線拉遠一點，Agent 越能幹，它「能碰到的東西」就越多。預設就該是「不傳」，而不是「傳了再說、被抓才改」。對開發者來說，現在最實在的動作是：輪換每一個曾經進過倉庫的憑證，不管它今天還在不在工作區裡。