事實
AI 安全 · AI 代理 · 封包層拆解cereblab · 2026-07-12 · 記錄至 2026-08-25
執行摘要 · 單頁綜覽
「不要開啟任何檔案」——整個儲存庫照樣送出
對 xAI（2026 年 7 月 6 日更名為 SpaceXAI）旗下程式碼 CLI Grok Build 0.2.93 版所做的封包層拆解顯示，它同時運作兩條獨立通道：模型實際讀取檔案的通道，以及另一條在背景把整個工作區打包成 git bundle 上傳的通道。權限提示只管得到前者。在關鍵的對照實驗中，代理被指示不要開啟任何檔案——它照做了，儲存庫仍然離開了這台機器，連同完整的 git 歷史。上傳行為於翌日即遭伺服器端停用；但它揭露的同意模型缺陷，才是六週後這篇報導依然成立的原因。
關鍵數據 單一 12 GB 儲存庫 · 單次工作階段
- 27,800×離開機器的資料量，是模型對話所需的倍數
- 5.10 GiB經 /v1/storage 上傳——相對於模型流量僅 192 KB
- 0在7月13日修補前，找到可停止上傳的設定數——「我沒有找到」
- 2個無關的儲存庫——都取回了未被讀取的 canary
哪些已證實 — 哪些並未確認 依確信程度排序，最確實的在前
| 確信程度 | 內容 | 誰這麼說 |
|---|---|---|
| 已證實 | Grok Build 推出時，xAI 將它宣傳為「本機優先」，表示不會將任何原始碼傳送至其伺服器 | DevOps.com 直2026年5月15日的推出報導，直接讀取 |
| 已證實 | 7 月13 日，整個儲存庫的上傳行為停止；伺服器開始回傳 disable_codebase_upload: true——另一個帳號也獨立確認了這點 | cereblab 自行重測；開發者 Peter Dedene 自己帳號的發現，發佈於 X |
| 已證實 | xAI（六天前才更名為 SpaceXAI）公開承認，非企業用戶的資料保存預設為開啟；Musk 並承諾刪除所有先前上傳的資料 | SpaceXAI 自己發布於 X 的聲明；The Register，2026年7月14日 |
| 已證實 | SpaceXAI 於 7 月16 日以 Apache 授權條款開源 Grok Build CLI；發現上傳碼仍留存於發布版本中，只是被修改而非移除 | The Register，2026年7月16日，引述開發者 Simon Willison 自己的審閱 |
| 已確認，但本站無法查證 | Grok Build 0.2.93 同時運作第二條通道，將整個儲存庫（連完整 git 歷史）打包並經由 /v1/storage 上傳，與代理是否被指示讀取無關；在一個 12 GB 的測試儲存庫上，該通道上傳了 5.10 GiB，而模型對話流量僅 192 KB | cereblab 的封包擷取記錄，附公開重現工具——以下來源中並無具名第三方獨立重現此結果 |
| 已確認，但本站無法查證 | clone 回保存下來的 bundle，可原封不動取回一個代理被明確指示不要開啟的檔案，並連完整 git 歷史一併取回；且已在另一個無關的儲存庫上重現 | cereblab，同上 |
| 已確認，但本站無法查證 | 一個被 git 追蹤的 .env 檔案中的機密，無論在模型對話流量還是儲存上傳中，都未經任何遮蔽即送出 | cereblab，同上 |
| 已確認，但本站無法查證 | 關閉「改進模型」並不能阻止 bundle 上傳；伺服器仍持續回傳 trace_upload_enabled: true | cereblab，同上 |
| 未確認 | 承諾刪除先前上傳資料一事，是否真的完成 | 截至 2026年8月25日，以下來源均未提及此事已完成；The Register 自己 7月14日的報導也同樣表示無法就其報導本身作出確認 |
| 未確認 | 「其他研究者」已在自己的儲存庫上獨立確認此發現；並且 Codex 與 Anthropic「各自獨立發現了間接證據」，顯示另有八個私人儲存庫完整被上傳 | cereblab 自己網站（未具名，也無任何附件連結）；以及開發者 Peter Dedene 自述他所言那些方的發現——兩者都未獲 OpenAI 或 Anthropic 的聲明作為佐證 |
| 非公開資訊 | SpaceXAI 是否以此管道收集的資料訓練模型 | cereblab 自己的 gist 明確表示，此事從未得到任何方向的證實：「上傳／儲存 ≠ 訓練」 |
時序
事件經過 從拆解到開源僅十一天，其後五週再無下文
- 2026-02-02SpaceX 以全股票交易完成收購 xAI。
- 2026-05-15Grok Build 進入早期測試階段的報導出現，宣傳詞為「本機優先」——業界媒體報導 xAI 自己的說法：不會有任何原始碼傳送至其伺服器。
- 2026-07-06xAI 的公開帳號更名為 SpaceXAI。
- 2026-07-12cereblab 發表對 grok build 0.2.93 的封包層拆解，附上以 SHA-256 雜湊佐證的證據與公開的重現工具。
- 2026-07-13上傳行為停止：伺服器開始回傳
disable_codebase_upload: true。開發者 Peter Dedene 在自己的帳號上也回報了相同的旗標。 - 2026-07-14The Register 與 The Hacker News 報導此發現。SpaceXAI 於 X 發文說明「改進模型」、ZDR 與新增的 /privacy 指令各自涵蓋的範圍。Musk 公開承諾刪除所有先前上傳的使用者資料——此事尚未獲獨立確認已完成。
- 2026-07-16SpaceXAI 以 Apache 授權條款開源 Grok Build CLI 並重設使用額度。獨立開發者 Simon Willison 審閱釋出的原始碼後指出：上傳程式碼仍然存在，只是被修改以反轉其行為，而非直接移除。
- 2026-07-22cereblab 重新測試 grok build 0.2.106，再次確認修補仍然有效。
- 尚未結案承諾的刪除是否已經完成，至今仍未獲確認。截至 2026 年 8 月 25 日，以下來源均未見任何 CVE 編號或廠商正式發布的安全公告。
論點
兩條通道，兩套規則 權限提示只看得到其中一條
通道 A · 依讀取
/v1/responses
- 只承載代理實際開啟過的內容。
- 權限提示管的是這一條。
- 測試工作階段中，五次請求共 192 KB。
- 未被讀取的檔案，確實不在其中。
通道 B · 依儲存庫
/v1/storage
- 打包所有 git 追蹤檔案與完整歷史。
- 與模型讀了什麼、沒讀什麼無關。
- 同一工作階段 5.10 GiB；73 個分塊，全數 HTTP 200。
- 目的地：一個 Google Cloud Storage 儲存桶。
那個從未被讀取的 canary 左為敘述 · 右為關鍵實驗
單看位元組比例已足以起疑：192 KB 的模型對話不可能承載 5.10 GiB，因此儲存通道必然是整個儲存庫的快照，而非讀取行為的副產品。但決定性的證據是逐檔的。研究者以「僅回覆 OK。不要讀取或開啟任何檔案。」作為提示；代理照做，什麼也沒開——POST /v1/storage 仍回傳 200，把整個儲存庫以 git bundle 送出。將保存下來的 bundle clone 回來，可原封不動取回一個代理從未碰過的 canary 檔案，以及完整的四筆提交歷史。此結果在另一個無關的程式庫上重現。執行此事的工具已公開，其方法亦已完整發布——但上述紀錄仍是 cereblab 自己的實驗，目前並無已知有其他人獨立重跑過一次。
- OK代理的全部回覆——它什麼都沒開
- 4從 bundle 完整取回的提交數
- ×2重複驗證的程式庫數
封包實況 單一工作階段 · 兩個目的地
| 送出的內容 | 通道 | 證據 |
|---|---|---|
| 整個儲存庫（git bundle） | /v1/storage | 73 個約 75 MB 的分塊，全數 HTTP 200；clone 回來即可取回從未被讀取的 canary。 |
| 未遮蔽的 .env | 兩者皆是 | API 金鑰與資料庫密碼明文出現在 48 KB 的請求內文，並再次出現在 session-state 封存檔中。 |
| 目的地儲存桶 | GCS | 出現在執行檔字串與暫存 metadata 路徑中——三重佐證。 |
三個開關，沒有一個是煞車 預期 vs. 實際，7 月13日修補之前
| 控制項 | 開發者的預期 | 實際行為 |
|---|---|---|
| 「改進模型」開關 · 預設開啟 | 讓我退出資料蒐集 | 管的是訓練／保存政策，而非傳輸。關閉後伺服器仍回傳 trace_upload_enabled: true，bundle 照樣上傳——直到 7 月13日伺服器端修補為止。 |
| /privacy 指令（修補後新增） | 停止送出 | 是資料保存設定——cereblab 實測後認定，「並非阻擋送出的內容」。真正停止傳輸的，是另一個獨立的伺服器端旗標 disable_codebase_upload。 |
| 任何使用者端的關閉開關 | 總該有一個吧 | 7 月13日之前，並未找到任何一個。上傳行為之所以停止，只因 SpaceXAI 在自己的伺服器上翻轉了一個旗標——那是使用者根本碰不到的補救方式。 |
總結
問題出在同意模型，而不是某一行程式碼。提示問的是「我可以讀取嗎？」，而另一條通道卻把所有 git 追蹤檔案與完整歷史打包送出，與此無關——而唯一能讓它停下來的，始終是廠商自己在其伺服器上的動作。
重新定位
你的暴露面是工具上傳的內容——絕不是它讀取的內容。
補充
為何已刪除的機密仍會送出 暴露鏈
- 01提交數月前的一則機密
- 02刪除自工作目錄移除
- 03留存仍存在於 git 歷史
- 04打包追蹤檔案 ＋ 歷史
- 05上傳與讀取與否無關
- 06輪替唯一真正的補救
同業比較 cereblab 自行對多款工具的測試
| 工具 | 是否上傳整個儲存庫？ | 確信程度 |
|---|---|---|
| Claude Code | 否——只有它開啟過的檔案 | 已確認，但本站無法查證 |
| Codex | 否——只有它開啟過的檔案 | 已確認，但本站無法查證 |
| Gemini | 否——只有它開啟過的檔案 | 已確認，但本站無法查證 |
| Grok Build (0.2.93, before the fix) | 是——整個儲存庫連同 git 歷史，送上雲端 | 已確認，但本站無法查證 |
廠商自己的話，以及後續發展 直接讀取，而非僅透過媒體轉述
SpaceXAI 自己的公開聲明，經直接讀取，寫道：「自推出以來，Grok Build 一直完全遵守零資料保存（ZDR）……在早期測試版中，非 ZDR 使用者的資料保存預設為開啟。根據各位的回饋，我們已作出變更。」這是廠商自己以自己的話陳述發生了什麼——承認除企業層級以外，所有使用者的保存設定原本預設為開啟，而不只是描述一項修補。它把整起事件定調為一個已被更正的測試版預設值，而非 cereblab 封包擷取所描述的傳輸缺陷；本文將兩種說法並列於此，不代為判定孰是。就以下來源而言，SpaceXAI 迄今未曾就此行為發布安全公告、更新日誌條目或 CVE——其對事件的陳述僅見於社群貼文，而非日後可供讀者引用的廠商正式紀錄。該聲明另有兩句直接關乎此一發現，而在下列來源中始終未與之調和：SpaceXAI 稱「所有使用者一直都能在 CLI 中關閉資料上傳」，且「當使用者關閉上傳時，此一選擇獲得尊重」——這正面否認了「沒有任何使用者端設定擋得住該封包上傳」的說法。該公司並將自身的變更日期定於「自 7 月 12 日起」，比外界觀察到伺服器旗標改變的日子早了一天。
結論
建議 以最高回報為先
- 輪替所有可從 git 追蹤歷史取得的憑證——刪除從未真正移除它，而刪除已上傳資料的承諾，也收不回已經送出的內容。
- 在封包層驗證，而非看提示——權限對話框只描述一條通道；請像公開的重現工具讓第三方所能做到的那樣，實測到底有什麼離開了這台機器。
- 要求預設關閉——每次工作階段都得手動退出的保存開關，不叫同意，而且它與真正能阻止傳輸的開關根本不是同一個。預設值就是政策。
- 把廠商端的修補視為暫停，而非結案——修補之後，據報導上傳程式碼本身仍然存在，只是遭到修改；而先前上傳的資料是否真的已被刪除，至今仍未獲確認。優先選擇關閉開關由你掌握、且可驗證的工具。
最終落點
任何代理式編碼工具，只要其同意介面涵蓋的範圍比實際傳輸的通道更窄，就有這個問題——不論掛的是誰的招牌。Grok Build 管住了讀取，另一條通道卻送出了整個儲存庫，而且 cereblab 未能找到任何擋得住的使用者端設定，此點 SpaceXAI 予以否認：上傳之所以停止，只因廠商——數日前才更名為 SpaceXAI 的 xAI——在被抓包數日後，於自己的伺服器上關掉了它；此後該公司開源了這款工具、承諾刪除已蒐集的資料，卻始終未以正式公告的形式作出任何說明。你碰不到的補救，就不算控制。正確的預設值是關閉。