馬斯克親口承認Grok Build偷傳用戶代碼，承諾歷史數據全部清零不留一個字節

獨立安全研究員日前揭露，SpaceXAI 旗下的 AI 編程助手 Grok Build 會在使用者毫不知情的情況下，將整份程式碼倉庫上傳至雲端。這項發現迅速引爆隱私爭議，而 SpaceXAI 創辦人伊隆・馬斯克（Elon Musk）隨後親自出面回應，坦承確有此事，並承諾將所有已上傳的歷史資料「連一個位元組都不留」全數刪除。Grok Build 是 SpaceXAI 開發的程式碼生成工具，官方宣傳頁面明確標榜「本地優先，程式碼留在你自己的電腦上」，主打隱私保護與資料在地化處理。然而這項保證卻被一名獨立安全研究者的實測徹底戳破，暴露出產品設計與行銷說詞之間的巨大落差。

這次測試由代號 @cereblab 的研究人員執行。他建立一個專為釣魚測試設計的虛假倉庫，在其中埋入偽造的 API 金鑰、資料庫密碼等已做唯一標記的誘餌，並預先架設監控機制，能夠攔截 Grok Build 對外發出的每一個封包。整個實驗的設計，就是要驗證這款工具是否真的如官方所稱，只在本地處理資料。測試過程中，研究人員對 Grok Build 下達明確指令：什麼都不用做，只回答一個「OK」。Grok Build 確實乖乖回覆了 OK，但同時卻在背景將整個測試倉庫的所有檔案，連同完整的修改歷史，打包上傳至 Google Cloud 的儲存空間。

這一行為完全違背了「本地優先」的承諾，且未在使用者介面中出現任何提示或請求許可。數據更能看出問題的嚴重性。被上傳的程式碼倉庫總容量約為 1 GB，Gro Build 將它拆成 73 個封包順利送達雲端。而真正經由使用者對話產生的流量僅有 192 KB。兩相比較，遭暗中傳送的資料量是正常回覆所需流量的 27,800 倍。換句話說，工具表面上只回了一個單字，實際上卻把使用者的整份原始碼、設定檔與演進歷史都搬上了伺服器。消息曝光後，馬斯克在社群平台上直接回應這起隱私風波。他開口的第一個詞是「True」，明確承認研究人員的發現屬實。

他隨後進一步保證，所有先前已被上傳至 SpaceXAI 的用戶數據，將會執行徹底且不可逆的清除作業，「一個位元組都不會留下」。這項承諾等同於公開認錯，並主動提出數據歸零的補救措施。過去雖然曾有多起 AI 產品涉及濫用使用者資料的爭議，但極少看到企業高層在第一時間直接承認事實，更遑論承諾將歷史數據完全刪除。業界普遍認為，馬斯克這次的處理方式在 AI 圈創下先例，也為後續類似事件的危機處理立下一個可能被參考的標準。不過，清理伺服器上的歷史資料僅是第一步。

Grok Build 在架構設計上是否本身就存在將用戶資料回傳雲端的機制，或者僅是特定版本的行為異常，至今仍未獲得 SpaceXAI 的詳細技術說明。開發者社群也開始呼籲，除了刪除既有數據，SpaceXAI 應公開 Grok Build 的實際網路行為，並開放第三方進行安全審計，才能重建用戶信任。Grok Build 並非市場上唯一的 AI 編程助手，同類產品還包括 GitHub Copilot、Amazon CodeWhisperer 等。這類工具通常需要讀取部分程式碼才能提供建議，但用戶對於「哪些資料會被送離本機」始終高度敏感。

Grok Build 主打在地化處理，原本被視為一項重要賣點，如今卻因為這起事件讓隱私保護的承諾大打折扣。對開發者而言，這個事件也敲響了警鐘。即使產品宣稱本地優先，實際行為仍可能存在落差。使用 AI 編程工具前，最好先透過網路監控工具確認其連線行為，或者利用容器、虛擬機等方式限制其對外存取權限。畢竟，一旦程式碼被上傳到第三方伺服器，即便後續承諾刪除，也很難百分之百確認沒有留下任何副本。馬斯克與 SpaceXAI 選擇正面回應並承諾清零，表現出一定的誠意。但在 AI 產業快速擴張的當下，透明度與使用者控制權才是建立長期信任的基石。

Grok Build 若想重新站穩腳步，勢必得從這次教訓中徹底改革資料處理流程，而不是僅止於一次性的資料刪除行動。