馬斯克的AI，把你的整個代碼庫連鍋端走, 連密鑰都不放過！！！

關(guān)注飛總聊IT，了解IT行業(yè)的方方面面。

一個安全研究人員，一個叫mitmproxy的抓包工具，一臺Mac，就把馬斯克旗下xAI的編程助手Grok Build按在地上曝了個底掉——你以為它只是在幫你寫代碼，其實它順手把你整個項目連根拔起，打包送去了自己的云端服務(wù)器,一個字節(jié)都沒留下。

研究者以cereblab為化名（X平臺賬號是@cereblab，本人叫Hari）在7月12日公布了這份分析報告：Grok Build版本0.2.93在處理編程任務(wù)的時候，會在后臺把整個被Git追蹤的項目倉庫——連同完整的提交歷史，也就是你代碼庫里所有曾經(jīng)寫過、又刪掉的秘密——打包成一個Git bundle,悄悄上傳到一個叫g(shù)rok-code-session-traces的谷歌云存儲桶里，這個存儲桶歸xAI管理。

這件事最要命的地方，不是"AI編程工具會上傳代碼"這件事本身——這本來就是云端編程助手的常規(guī)運作方式，為了完成任務(wù)，把相關(guān)代碼片段發(fā)給遠(yuǎn)程模型是必要的。

問題出在"上傳范圍"上。 cereblab用一個12GB的測試倉庫做了對比實驗，結(jié)果相當(dāng)離譜：真正跑去模型那邊、用來完成編程任務(wù)的流量只有大約192KB，但走存儲通道上傳出去的數(shù)據(jù)卻高達(dá)5.1GB，兩者相差大約27800倍。

換句話說，Grok Build壓根不是"發(fā)送任務(wù)需要的文件"，而是把整個代碼庫原封不動地打包帶走了。

為了把這個結(jié)論釘死，cereblab還做了一個更狠的驗證——他在測試倉庫里埋了兩個"金絲雀"標(biāo)記：一個.env文件里寫著一串明顯是偽造的API密鑰和一個模擬數(shù)據(jù)庫密碼，另外還有一個文件他明確告訴Grok Build"不要讀取"。

結(jié)果呢？那串偽造密鑰原封不動地出現(xiàn)在了截獲的網(wǎng)絡(luò)流量里，而那個被明令禁止讀取的文件，最后也被他從截獲的Git bundle里成功克隆了出來，內(nèi)容一字不差。

也就是說，AI根本沒打開那個文件去"學(xué)習(xí)"，但上傳程序照樣把它一并打包帶走了。

這就是"連密鑰都不放過"這句話的真正分量所在——Git提交歷史里往往藏著早就已經(jīng)從工作目錄里刪除、但從未從版本歷史里徹底清除的敏感信息，比如某個開發(fā)者手滑提交過又刪掉的密鑰、內(nèi)部接口地址、客戶數(shù)據(jù)。你以為刪掉了就是刪掉了，但只要它曾經(jīng)被提交過，這類"歷史遺留污點"就會隨著完整的Git bundle一起，原封不動地被連鍋端走。

更讓人后背發(fā)涼的是接下來這部分。xAI一直對外宣傳Grok Build"會話期間代碼庫中的任何內(nèi)容都不會傳輸?shù)絰AI服務(wù)器"，產(chǎn)品文檔里也把它包裝成一款"本地優(yōu)先"的工具。

cereblab專門去測試了這句承諾——他關(guān)掉了Grok Build里那個面向用戶的核心隱私選項"改進(jìn)模型"（Improve the model），照理說這應(yīng)該能阻止數(shù)據(jù)外傳。

結(jié)果重新運行之后，服務(wù)器的/v1/settings接口依然穩(wěn)穩(wěn)地返回trace_upload_enabled: true，存儲通道該傳照傳，一個字節(jié)都沒少。

原因說穿了很簡單：這兩個開關(guān)根本管的不是一回事。"改進(jìn)模型"這個選項，控制的是"你的數(shù)據(jù)會不會被用來訓(xùn)練未來版本的模型"；而真正決定"你的代碼會不會離開這臺機(jī)器"的，是另一個完全獨立、且從未暴露給用戶的技術(shù)開關(guān)。

用戶以為自己關(guān)掉了閥門，實際上關(guān)的只是隔壁那根根本不相干的水管。

橫向一對比，問題更清楚 cereblab沒有止步于揪出Grok Build一家，他用同樣的抓包方法，把Claude Code、Codex、Gemini這幾款同類競品也測了一遍。

結(jié)果是：Claude Code和Codex都只發(fā)送AI實際打開過的文件，那個被埋進(jìn)去的"不要讀取"標(biāo)記文件，一次都沒有離開本地機(jī)器；Gemini在空閑狀態(tài)測試中也沒有發(fā)送任何倉庫打包數(shù)據(jù)，雖然它在更貼近真實場景的測試?yán)镆驗橛|發(fā)了配額限制沒能完整跑完。

這個對比結(jié)果說明,把整個代碼庫連同完整歷史打包上傳,并不是這類工具的行業(yè)慣例,而是Grok Build獨有的問題。

報道曝光之后,xAI沒有走正式安全公告的流程,而是通過社交媒體做出了回應(yīng)——馬斯克親自確認(rèn)了這次上傳行為的存在,并表示公司會刪除此前所有Grok Build收集到的用戶數(shù)據(jù)。

技術(shù)層面,xAI通過服務(wù)器端悄悄下發(fā)了一個新的標(biāo)志位disable_codebase_upload: true。cereblab在報告發(fā)布一天后重新測試了同一個0.2.93客戶端,發(fā)現(xiàn)服務(wù)器現(xiàn)在返回的是disable_codebase_upload: true加上trace_upload_enabled: false,連續(xù)六次重測都沒有再觀察到倉庫上傳行為,這說明xAI確實在服務(wù)器端做了一次靜默的遠(yuǎn)程修復(fù)。

但這個修復(fù)目前只在cereblab自己的一臺機(jī)器、一個賬號上得到驗證，沒有辦法確認(rèn)這個修復(fù)是不是已經(jīng)全局生效、是分階段推送還是永久性的。

而且截至目前，xAI既沒有發(fā)布正式的安全公告，也沒有說明此前那些已經(jīng)上傳到grok-code-session-traces存儲桶里的代碼庫究竟會被怎么處理、留存了多久、是否已經(jīng)被員工查看過。

官方更新日志里，7月12日發(fā)布的0.2.98版本，只字未提這次倉庫上傳的問題。

cereblab在報告里也很坦誠地劃清了證據(jù)邊界：這些抓包數(shù)據(jù)只能證明"未經(jīng)披露的傳輸和存儲確實發(fā)生了"，并不能證明xAI用這些代碼訓(xùn)練過模型，也不能證明有員工查看過這些數(shù)據(jù)，或者所有賬號都遭遇了同樣的配置問題。

但反過來看，這恰恰也是問題所在——除了社交媒體上一句簡短的確認(rèn)，xAI幾乎沒有給出任何實質(zhì)性的答案。

Grok Build是xAI今年伴隨Grok 4.5一同推出的編程工具，本意是對標(biāo)Claude Code和Cursor，試圖在企業(yè)開發(fā)者市場里搶下一席之地。

對于一款剛剛起步、急需贏得企業(yè)開發(fā)者信任的產(chǎn)品來說，這次曝光的時機(jī)相當(dāng)致命。

對普通開發(fā)者而言，這件事其實是一記警鐘：云端AI編程工具打的"數(shù)據(jù)安全"廣告牌，光看營銷文案和一個孤立的隱私開關(guān)是不夠的。

開發(fā)者應(yīng)該假定但凡接入這類工具的代碼倉庫，就存在被超出預(yù)期范圍上傳的可能，尤其是那些藏在Git歷史深處、早已從工作目錄刪除但從未真正清除的敏感信息，才是最容易被忽視、也最難被追回的部分。

推薦飛總知識星球，在私域場合里暢所欲言，聊聊職場發(fā)展的事情，和飛總提問交流，這么低 的價格不會一直保留，機(jī)會難得，一定不要錯過這個的機(jī)會。