根據一位資安研究員的分析，馬斯克旗下 SpaceXAI 推出的命令列程式碼工具 Grok Build，在未取得明確同意的情況下，悄悄將開發者的完整程式碼儲存庫上傳至雲端；這份分析登上 Hacker News 首頁，並引來馬斯克本人回應。原本可能只是一樁小眾開發者工具的抱怨，如今卻演變成本週最尖銳的 AI 隱私事件之一，原因既在於這款工具做了什麼，也在於它遠遠超出了任務實際所需的範圍。
這份於 7月12日發布的封包層級分析發現，Grok Build 並非只是讀取完成任務所需的檔案。它把整個受 Git 追蹤的儲存庫打包起來，包含完整的提交歷史，以及過程中曾被提交的任何機密資訊，再傳送到一個 Google Cloud Storage 儲存桶。研究員量測到，離開一台機器的資料量約為實際程式撰寫工作所需的27800倍，其中一次上傳據報達數 GB。最令人不安的發現是，使用者原本可能倚賴、用來防止這類情況的隱私開關，對這些上傳毫無作用。
正是這個細節，把一樁資料處理的事件，變成了實際的資安問題。已提交的機密資訊並非假設性的顧慮，它們往往包含開發者在某個時間點不慎簽入儲存庫的真實 API 金鑰、資料庫密碼與雲端存取權杖。研究人員給出的實務建議很直接：任何曾在含有憑證的程式碼庫上執行過 Grok Build 的人，無論當時隱私設定看似做出什麼承諾，都應把那些憑證視為已可能外洩，並加以輪替更換。
分析登上 Hacker News 後，反應來得很快。馬斯克發文表示，作為預防措施，此前所有上傳至 SpaceXAI 的使用者資料都將被徹底、完全地刪除。公司員工補充說，Grok Build 自推出以來便支援零資料保留，使用者也可以執行一道隱私指令來選擇退出，並觸發刪除先前同步的資料。該研究員反駁了這套說法，主張那道隱私指令只是逐次工作階段的保留開關，並非真正堵住漏洞的關鍵。根據其說法，真正的修補是伺服器端一個未公開的旗標，也就是把 disable codebase upload 設為 true，並在全域套用，而非讓使用者自行去尋找並切換的東西。
這件事的重要性，超越了單一工具與單一公司。AI 程式撰寫助手的運作方式就是吃進你的程式碼，這使得程式碼事後何去何從成為核心問題，而非無關緊要的註腳。這起案例赤裸裸地凸顯出一道落差：工具的隱私控制看似做出的承諾，與軟體在網路傳輸層實際所做之事之間的落差；也凸顯出提交到儲存庫的機密資訊，可以多快就落到你從未打算傳送的地方。隨著愈來愈多開發者把代理式程式撰寫工具接進日常工作，搞清楚你的原始碼流向何方，以及你是否真能把那項功能關掉，正迅速成為執行任何一款工具前，最值得先確認的事項之一。