北京
在最新曝光的測試中，xAI的Grok Build命令行工具做出了一個遠遠超出多數開發者預期的動作：它把測試項目完整的Git倉庫，連同所有提交歷史，一股腦上傳到了xAI運營的Google云端存儲桶里，而不是僅僅傳取當前編碼任務所需要的文件。
發現這一行為的研究者以“cereblab”的名義發布分析，他測試的Grok Build版本是0.2.93。在一次攔截中，他抓到了上傳的數據流，從中克隆出了Git包，然后發現包里竟然包含一個被明確告知“不許碰”的金絲雀文件。這個文件被原封不動地還原了出來。
上傳動作走的是一條完全獨立于大模型通信的通道。在一個體積達到12 GB的倉庫測試中，模型本身發出的流量大約只有192 KB，而同一次會話里發往存儲端點的數據量卻高達5.10 GiB。兩者相差約27800倍——模型的“剛需”和實際上傳的內容，完全不在一個量級。
這批上傳被拆成了73個分塊，每個約75 MB，全部收到服務器HTTP 200的響應。更讓研究者注意的是，不論倉庫大小如何變化，上傳量都緊緊跟著倉庫總尺寸走。數據流向的目的地是一個叫作grok-code-session-traces的桶，這個名字直接寫在二進制文件和一份暫存的metadata.json里，其中每個文件路徑都指向gs://grok-code-session-traces/。
那個被反復提到的未讀文件名叫src/_probe/never_read_canary.txt，里面植入了唯一標記。研究者從截獲的Git包中不僅完整恢復了它的內容，還得到了倉庫自創建以來的全部提交記錄。同樣的實驗在另一個完全無關的倉庫上復現了同樣的結果。這次捕獲證明的是上傳、接收和存儲這三步都真實發生了，并沒有暗示xAI拿代碼來訓練，也不意味著有員工查看過這些數據，同樣也不等于.gitignore忽略的文件一定被收走。線路上可見的，只是被Git跟蹤的文件與歷史。
憑證泄露的路徑則更加直接。如果Grok在執行任務時讀取了一個.env文件，文件內容就會原樣進入模型通信回合，study中的金絲雀API密鑰和數據庫密碼于是就以未脫敏的形態一同送了出去。同樣一份內容還被寫入了發往存儲端的session_state存檔。當然，這些憑證都是用假數據預先埋伏的，并沒有真正泄露什么，但行為本身的問題在于：一個代碼倉庫里的憑證文件一旦被助理讀到，就會被毫無屏蔽地外傳并持久化保存。
最讓使用者可能以為安全的那個開關，在這里完全沒起作用。界面上的“改進模型”選項即使被關掉，Grok依然會上傳整個倉庫。服務器端返回的/v1/settings響應里，trace_upload_enabled始終標記為true。這個開關只管“要不要拿你的數據訓練模型”，卻不管“你的代碼要不要離開本機”。這是兩套完全不同的控制邏輯，而系統只向前者暴露了用戶界面。
任何云編碼助手為了工作，都必須把部分源碼發往遠端的大模型，這一流量通道可以理解。但把整個受Git跟蹤的倉庫以及全部歷史都送出去，就遠比“僅發送任務所需文件”的邊界要寬得多。倉庫里可能裝著專有代碼、內部網址、客戶數據，以及已經從工作區刪掉卻還留在提交歷史里的老舊憑證。
在cereblab做的跨工具對照中，Claude Code和Codex都沒有發送任何倉庫包；Gemini在一次空閑測試里也沒發，但那場包含真實任務的測試在數據出來之前就因達到使用限額被阻止了。對照結果讓Grok Build這一遠超功能需求的傳輸行為，顯得格外醒目。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
