程式碼生成能力大爆發的時代，智慧體的行為更需要可見、可控。
北京時間 7 月 12 日前後，安全研究者 cereblab 公開了一份對 Grok Build CLI 的封包擷取分析，隨後被多家中文媒體轉述。核心指控只有一句：當你在一個倉庫裡執行 Grok Build CLI v0.2.93，它會把整個倉庫、連同完整的 git 歷史打包成 git bundle，透過一條獨立於模型對話的通道上傳到 xAI 的 Google Cloud Storage 儲存桶 grok-code-session-traces——即便你明確要求它不要讀取任何檔案，即便你在設定裡對敏感檔案配置了拒絕讀取。
這類指控適合用技術手段核驗，而不是停留在轉述。我們拿到了 cereblab 指向的那個版本的離線安裝樣本 grok-build-0.2.93~3880d629a6.pkg，用 AVL Code 做了靜態分析：解壓、算熵、抽字串與 IOC、解析其中的 ELF 二進位，再把結果與傳言逐條對照。本文說明三件事：傳言描述的上傳機制是否真實存在於用戶端程式碼中，它的通道和開關長什麼樣，以及靜態分析能證明到哪一步、哪些結論必須依賴 cereblab 的動態封包擷取。
驗證結論
先給結論。對這份離線樣本的靜態分析可以確認：
- 二進位中硬編碼了上傳目標儲存桶
grok-code-session-traces，以及一組獨立於模型通道的上傳開關（GROK_TRACE_UPLOAD_BUCKET、GROK_TELEMETRY_TRACE_UPLOAD等）； - 用戶端持有對 GCS 的完全控制級 OAuth 權限（
devstorage.full_control）； - 樣本中同時存在
git bundle/git clone相關字串，以及--deny、--always-approve、blocked by a permission policy等權限控制字串； - 上傳目標端點為
POST /v1/storage，走api.x.ai/v1，與模型對話端點/v1/responses實體分離。
換句話說，傳言裡那條「整庫打包、經由獨立通道上傳到 GCS」的鏈路，其零件在用戶端二進位中確實齊全：儲存桶名稱、上傳開關、雲端憑證權限、打包命令一一對應。
需要同樣清楚地說明邊界：靜態分析證明的是「這套機制存在於程式碼中」，不是「它在某次執行中確實上傳了你的倉庫」。後者是動態問題——上傳是否真的發生、上傳了多少、未讀取的檔案是否真的離境——這些靠的是 cereblab 的 mitmproxy 封包擷取證據，不是離線樣本能單獨回答的。兩者合起來才構成完整的證據鏈：靜態樣本證明「能做」，動態封包擷取證明「做了」。
傳言的核心是什麼
cereblab 的封包擷取分析把 Grok Build CLI 的外發拆成兩條通道：
- 模型通道：agent 實際讀取的檔案內容，走
POST /v1/responses發給模型； - 儲存通道：整個倉庫打包成 git bundle，走
POST /v1/storage上傳到 GCS。
關鍵的對照來自一次 12 GB 倉庫的測試：儲存通道上傳了約 5.10 GiB（分成 70 多個約 75 MB 的分片，全部回傳 HTTP 200），而同一次會話裡模型通道只傳了 192 KB。兩者相差約 27,800 倍。這個比值本身就說明，上傳的規模與「agent 讀了哪些檔案」無關——它上傳的是整個倉庫，而不是對話需要的那點上下文。
更直接的證據是金絲雀檔案。cereblab 在測試倉庫裡放了一個帶唯一標記（CANARY-XR47P2-NEVERREAD）的檔案，並明確指示 agent 不要開啟它。結束後，他從擷取到的上傳流量裡還原出 git bundle，git clone 之後 grep，那個從未被讀取的標記檔案原樣出現在復原的倉庫裡。這證明：檔案是否被 agent 讀取，和它是否離開你的機器，是兩回事。
傳言裡還有幾點關於「關不掉」的說法：
- 關閉「Improve the model（改進模型）」開關，不影響整庫上傳——伺服端
/v1/settings回傳的trace_upload_enabled始終為true； - 設定裡的拒絕讀取規則（
--deny）只攔住 agent 的讀取動作，攔不住檔案被打進 bundle；--always-approve還能繞過設定裡的限制； - 真正能把檔案擋在 bundle 之外的本地手段，只有
.gitignore（未被 git 追蹤的檔案不進 bundle）。
樣本從哪來，是什麼
先確認拿到手的是不是「同一個東西」，再談分析。
| 屬性 | 值 |
|---|---|
| 檔名 | grok-build-0.2.93~3880d629a6.pkg |
| 檔案大小 | 44,869,412 位元組（約 42.8 MB） |
| 壓縮格式 | Zstandard，魔數 28 b5 2f fd |
| 解壓後大小 | 159,472,640 位元組（約 152 MB） |
| 套件格式 | FreeBSD pkg（tar + 中繼資料），內含 Linux ELF，經 Linuxlator 執行 |
| 版本 | grok-build 0.2.93 |
| 建置時間 | 2026-07-12T22:15:16 UTC |
| SHA256（原始） | 3880d629a6bb438531b777aabadafc1a1bd9258e90de6d575daed1ed0711260e |
熵值分析也印證了解壓過程正確：原始 .pkg 平均熵約 7.999，接近壓縮資料的理論上限，無結構化明文；解壓後降到 6.24，出現可分析的 tar 中繼資料、ELF 段和明文字串。版本號 0.2.93 與傳言指向的版本一致，建置時間（7 月 12 日 UTC）正落在公開揭露的時間窗口裡。
程式碼層面看到什麼
定位與上傳、遙測、權限相關的字串和呼叫痕跡後，主要發現如下。
上傳目標與獨立開關
樣本字串中明確出現上傳相關的儲存桶與開關：
gs://grok-code-session-traces # 會話追蹤上傳桶（原始串中與 event 相鄰出現）
storage.googleapis.com/grok-build-public-artifacts
GROK_TRACE_UPLOAD_BUCKET # 追蹤上傳目標桶
GROK_TRACE_UPLOAD_ENDPOINT_URL # 上傳端點
GROK_TELEMETRY_TRACE_UPLOAD # 追蹤上傳開關
GROK_WORKSPACE_DATA_COLLECTION_DISABLED
這幾個環境變數的存在本身就說明一件事：上傳通道有自己的一組開關，獨立於「改進模型」那類面向對話的選項。傳言裡「關掉模型改進不影響上傳」的說法，在程式碼結構上有對應——兩者本就不是同一個開關。
雲端憑證權限
樣本請求的 GCP OAuth 權限範圍包括：
https://www.googleapis.com/auth/cloud-platform
https://www.googleapis.com/auth/devstorage.full_control
devstorage.full_control 是對 GCS 儲存桶的完全控制權限。對一個把使用者倉庫往桶裡寫的用戶端來說，這是它能寫入的憑證基礎。
打包機制
樣本中同時存在 git bundle、git clone 字串。git bundle create 會把 tracked 檔案連同 .git/objects、refs、logs 一起打成一個可 git clone 復原的單一檔案——這正是 cereblab 從封包擷取裡還原出完整倉庫、包括完整提交歷史的技術前提。
權限與上傳的錯位
樣本裡能看到本地權限控制的痕跡：--deny、--always-approve、blocked by a permission policy。但這些字串對應的是讀取層的檢查。結合金絲雀實驗可以推斷：讀取拒絕作用在「agent 要不要開啟這個檔案」這一步，而 bundle 打包遍歷的是「git 追蹤了哪些檔案」——兩條路徑不共享同一個判定。於是出現了那個關鍵的錯位：你拒絕 agent 讀取 secret.txt，它仍然可能被打進 bundle 上傳——讀取控制不等於上傳控制。
汙點核心路徑：Git Bundle → GCS 上傳
這是整件事的核心鏈路，其餘通道（模型對話、遙測、錯誤回報）都只是旁支。把上面的零件按資料流串起來，從使用者工作區到 xAI 儲存桶，一共經過六個階段：
① 使用者工作區（汙點源 / Source）
├─ git tracked 檔案（原始碼、設定、文件）
├─ .git/objects/ 全部提交物件
├─ .git/refs/ 分支與標籤
└─ .git/logs/ reflog，含已刪除 / 重寫的歷史
│ 遍歷——按「git 追蹤了什麼」，獨立於 agent 是否讀取該檔案
▼
② git bundle create → 單一檔案，可 git clone 完整復原
│ 含完整 commit history 與舊版本
▼
③ 打包 / 壓縮層（tar + zstd）
│
▼
④ HTTP 請求建構
POST /v1/storage Content-Type: multipart/form-data
Authorization: Bearer <token> 分片約 75 MB / 片
│
▼
⑤ 網路傳輸層 https://api.x.ai/v1/storage （TLS，伺服端路由）
│
▼
⑥ GCS 儲存桶（汙點匯 / Sink）
gs://grok-code-session-traces
憑證：OAuth scope devstorage.full_control（完全控制）
gs://grok-code-session-tracesevent（event 為相鄰串）。這條路徑的每一個階段，都能在「本次離線樣本的靜態證據」和「cereblab 的動態封包擷取」兩側各自找到落點——靜態證明零件在、動態證明零件轉起來了：
| 階段 | 靜態證據（本次樣本） | 動態驗證（cereblab 封包擷取） |
|---|---|---|
| ① 工作區遍歷 | 打包邏輯按 git 追蹤範圍收集，與 --deny 的讀取判定不共享（見「權限與上傳的錯位」） |
從未被讀取的金絲雀檔案 CANARY-XR47P2-NEVERREAD 原樣出現在復原的倉庫中 |
| ② git bundle 建立 | 字串 git bundle、git clone |
POST body 中擷取到 # v2 git bundle 魔數，git clone 復原出含完整歷史的倉庫 |
| ③ 打包 / 壓縮 | 套件本身即 zstd + tar，具備完整打包鏈路 | 上傳分片體積約 75 MB / 片，符合串流打包外發 |
| ④⑤ GCS 上傳 | GROK_TRACE_UPLOAD_BUCKET、GROK_TRACE_UPLOAD_ENDPOINT_URL、storage.googleapis.com/grok-build-public-artifacts、devstorage.full_control |
82 次 POST /v1/storage（約 73 個 75 MB 分片）全部回傳 HTTP 200；12 GB 倉庫外發約 5.10 GiB |
| ⑥ 落桶 | 字串 gs://grok-code-session-traces |
/v1/storage 路由至 grok-code-session-traces |
傳輸特徵進一步說明這是一條穩定、成規模的通道，而非偶發行為：cereblab 從 64 MB 到 12 GB 的多個測試倉庫跑下來，儲存通道零失敗（唯一的失敗來自模型用量配額，回傳 402/429，與儲存無關）；封包擷取在上傳到 5.10 GiB 處被截斷——是擷取工具停了，不是上傳自然結束，實際外發只會更多。同一次會話裡，模型通道只傳了 192 KB，與儲存通道相差約 27,800 倍：上傳的是整庫，不是對話需要的那點上下文。
對照本地各種「關閉」手段對這條核心路徑是否有效：
| 本地控制手段 | 對整庫上傳是否有效 | 說明 |
|---|---|---|
.gitignore 敏感檔案 |
✅ 有效 | 未被 git 追蹤的檔案不進 bundle，是唯一確定有效的本地手段 |
| 空倉庫 / 無 tracked 檔案 | ✅ 有效 | 沒有 tracked 內容，bundle 就沒有可打包的東西 |
--deny Read(*.env) |
❌ 無效 | 只攔 agent 讀取，檔案仍在 bundle 中 |
| 關閉「改進模型」 | ❌ 無效 | 面向模型訓練留存，與上傳通道不是同一開關 |
GROK_TELEMETRY_ENABLED=false |
⚠️ 不針對此 | 關的是事件遙測，不是 bundle 上傳 |
社群回饋中提到 GROK_TELEMETRY_TRACE_UPLOAD=0 和本地配置 [harness] disable_codebase_upload = true 能關掉上傳。從樣本看，前一個開關確實存在於二進位中；但這類開關在 v0.2.93 裡是否會被伺服端標誌覆蓋，屬於伺服端行為，離線樣本無法單獨判定。
靜態能證明到哪，動態靠誰
把話說清楚，避免越界：
離線樣本能證明的：上傳鏈路的每一個零件——儲存桶名、上傳端點、上傳開關、devstorage.full_control 憑證權限、git bundle 打包能力、讀取權限與上傳的錯位——都實打實存在於 v0.2.93 二進位中。這是「能做」。
必須依賴 cereblab 動態封包擷取的：某次真實會話裡上傳是否發生、5.10 GiB 的規模、27,800:1 的通道比、金絲雀檔案的原樣復原。這是「做了」，是靜態分析給不出的。
離線樣本給不出、也不該硬下的結論：伺服端後續是否用一個標誌把上傳關掉、何時關的——這是伺服端行為，不在樣本裡。但樣本能給出一個相關的、更持久的判斷：上傳能力是編譯進用戶端二進位的。哪怕伺服端某天把 trace_upload_enabled 翻成 false，用戶端 v0.2.93 仍然保留完整的上傳程式碼；只要那個伺服端標誌再翻回來，上傳就會復原，不需要使用者更新任何東西。使用者這一側無法從本地把這段能力拿掉。
這對使用者和企業意味著什麼
拋開 xAI 是否用這些資料訓練（那是政策問題，不是這次靜態分析能證明的），單看資料邊界，這件事有幾點值得記住：
- 讀取權限不等於資料邊界。你設定的「不許讀」攔得住 agent 的眼睛，攔不住打包器的手。對高權限程式開發工具，「能讀什麼」和「會傳什麼」必須是兩套都能稽核的控制，而不是共用一個。
- 完整 git 歷史一併上傳，暴露面比想像中大。歷史裡有已刪除的檔案、舊版本裡寫死的金鑰、每一次提交的作者資訊——它們不在你當前的工作樹裡，卻在 bundle 裡。
- 伺服端標誌優先意味著本地關不乾淨。當一個開關的最終裁決在伺服端，使用者在本地設的值就只是「建議」。
給使用者和企業的基礎動作：把金鑰和敏感檔案確實寫進 .gitignore（而不是僅靠 agent 的讀取拒絕）；高敏感專案用隔離的、乾淨歷史的倉庫；對閉源 AI 程式開發工具在企業環境裡做流量稽核和供應鏈評估；保留版本、安裝包與配置記錄，以便事後核驗。
為什麼用 AVL Code 做這個驗證
這次分析是 AVL Code 一個典型的使用場景：手上只有一個離線安裝包，沒有原始碼，要回答的問題是「傳言裡那套上傳機制到底在不在這個二進位裡」。這需要的不是寫程式的能力，而是安全分析的能力——解壓與算熵、字串與 IOC 擷取、PE / ELF / Mach-O 解析、反組譯與反編譯、YARA 比對，再加上會話式推理把證據串成一條路徑。AVL Code 把這些能力內建在一個程式開發 agent 裡，於是「從外部傳言出發、回到本機樣本上逐項核驗」可以在同一個工作區裡一次做完。
還有一層不必迴避的對照。這次事件暴露的那個錯位——讀取能拒絕、上傳攔不住；金鑰檔案在被 git 追蹤時隨 bundle 離境——恰恰是我們在設計 AVL Code 時劃死的一條線：金鑰類敏感檔案在任何配置下都不上傳，威脅情報預設只做雜湊查詢、不外發檔案內容，樣本內容確需外發時另有獨立確認環節；工作區之外的目錄要顯式附加、分唯讀與讀寫兩檔。這些設計寫在《AVL Code 的設計如何避免發生"GPT-5.6 一鍵清空創業者全盤資料"》裡，也和我們上一次對 Claude Code 隱式標記機制的核驗是同一種立場：高權限工具的資料邊界，要能被外部稽核，而不是只能靠信任。
需要克制的是，這不代表「用了 AVL Code 就絕不出問題」——沒有任何工程能作此承諾。它代表的是：邊界被明確劃出來、寫進產品、可以被核驗，而不是散落在一個使用者看不見也關不掉的伺服端標誌裡。
不止一個樣本：大模型時代，安全需要敏捷的技術實證
透過 AVL Code 對這份離線樣本的分析，我們與 cereblab 的初始爆料形成了一次相互印證：版本 0.2.93、那條獨立於模型對話的上傳通道、grok-code-session-traces 儲存桶、devstorage.full_control 憑證權限，在程式碼層面確實一一存在。而就在同一天，安天研究院發布了長篇報告《從論文"預告"到行為越界——Anthropic 事件從實證到倫理的分析》，對 Claude Code 採集主機資訊、以隱式環境標記上傳的事件做了從實證到倫理的系統研判——那起事件，也正是我們上一篇文章核驗的對象。兩件事放在一起看，指向的是同一種結構性風險：少數高權限、封閉的大模型用戶端，正透過使用者看不見、也難以關閉的通道收集與外發資料。在缺乏足夠透明與外部約束的情況下，這類風險已經不再是個案，而是全球使用者在大模型時代要共同面對的處境。
在 AI 能力大爆發的時代，安全工作者要面對的，已經不只是傳統意義上的攻擊載荷和行為分析，還有越來越龐雜的 IT 工具鏈與生態——AI 程式開發工具、MCP、智慧體、雲端後端彼此交織，新事件、新傳言密集湧現，真偽一時難辨。這對安全團隊提出了一個新要求：具備敏捷、快速的驗證能力，能在傳言出現時迅速回到樣本和證據本身。我們堅持對每一起傳言都做真實樣本分析，也正是因為——大模型生成的內容讓資訊真偽愈發難分，一旦脫離技術實證，討論極容易滑進以訛傳訛的循環；能被複核的證據，是這個循環唯一的出口。
而 Grok Build CLI 並不是一個小工具：解壓後約 152 MB，內含 Linux ELF，硬編碼了 150 餘個 GROK_* 環境變數，以及成套的上傳、遙測、認證邏輯。如果純靠人工完成這次核驗——解壓、定位二進位、擷取字串與 IOC、比對端點與權限、再把它們串成一條汙點路徑——需要相當的時間與人力，還容易在龐雜的字串裡漏掉關鍵一環。當前面提到的那套安全分析能力被放進同一個工作區、由會話統一驅動，這件事才得以在可控的時間內做完，並留下可複核的記錄。網路安全工作要既快，又可驗證——這正是我們打造 AVL Code 的初衷之一。
最後結論
基於對這份離線樣本的靜態分析，可以給出三個結論。
第一，用戶端上傳鏈路存在。儲存桶 grok-code-session-traces、上傳端點 POST /v1/storage、上傳開關、devstorage.full_control 憑證權限、git bundle 打包能力，都實打實在 v0.2.93 二進位裡，與傳言一一對應。
第二，權限與上傳的錯位存在。讀取拒絕只作用在 agent 讀取這一步，攔不住檔案被打進 bundle；本地唯一確定有效的過濾是 .gitignore。這是「讀取控制 ≠ 上傳控制」的結構性缺陷，不是配置問題。
第三，動態行為與伺服端策略仍需外部證據。上傳在某次會話中是否真的發生、規模多大，依賴 cereblab 的封包擷取；伺服端是否、何時關閉了上傳，離線樣本無法判定。但樣本能確認一件事：上傳能力編譯在用戶端裡，使用者無法從本地移除。
因此，這件事最值得關注的不是某個單一數字，而是資料邊界與透明度。對能讀檔案、改程式碼、執行命令、還能整庫打包外發的 AI 程式開發工具來說，上傳的範圍、通道和開關都應當清楚揭露、可稽核、可控制。只有這樣，開發者和企業才能在知情的前提下決定用不用、怎麼用。
我們在 avlcode.cn 等你，騎著賽博野驢——可驗、可控，韁繩始終在你手裡。
附錄：完整證據索引
下列證據分兩類來源：標註「樣本」的來自本次對 grok-build-0.2.93~3880d629a6.pkg 的靜態分析（可複核），標註「封包擷取」的來自 cereblab 的公開動態證據（交叉驗證）。兩類分開列出，便於各自追溯。
A. 樣本指紋（雜湊與體量）
| 項 | 值 |
|---|---|
| 檔名 | grok-build-0.2.93~3880d629a6.pkg |
| 檔案大小 | 44,869,412 位元組（約 42.8 MB） |
| 壓縮格式 | Zstandard，魔數 28 b5 2f fd |
| 解壓後大小 | 159,472,640 位元組（約 152 MB） |
| 套件格式 | FreeBSD pkg（tar + 中繼資料），內含 Linux ELF，經 Linuxlator 執行 |
| 版本 | grok-build 0.2.93 |
| 建置時間 | 2026-07-12T22:15:16 UTC |
| 建置系統 | poudriere-git-3.4.8，maintainer yuri@FreeBSD.org，相依 linux_base-rl9 9.7 |
| SHA256（原始） | 3880d629a6bb438531b777aabadafc1a1bd9258e90de6d575daed1ed0711260e |
| SHA256（解壓後） | e337cb55caf253c2d19b8fd26560808fe94bb9b87709d81edb1fdf06edf1e448 |
| 平均熵（原始 / 解壓後） | 7.999 / 6.24（解壓後區間 2.0–7.9） |
B. 核心網路端點
| 端點 | 用途 |
|---|---|
https://api.x.ai/v1 |
主 API 端點（模型 /v1/responses、儲存 /v1/storage、設定 /v1/settings） |
https://auth.x.ai |
OAuth / OIDC 認證 |
https://accounts.x.ai/sign-in |
帳戶登入 |
https://console.x.ai |
Web 主控台 |
https://cli-chat-proxy.grok.com/v1 |
CLI 聊天代理 |
https://code.grok.com/ws/code-agent |
Code Agent WebSocket |
https://assets.grok.com |
靜態資源 |
https://app-builder-deployer.grok.com / …gcp.mouseion.dev |
部署器 |
http://explorer-service-prod.global.svc.cluster.local:80 |
內部 K8s 服務（意外暴露在字串中） |
C. GCS 與雲端儲存憑證（核心）
| 類別 | 證據 | 含義 |
|---|---|---|
| 上傳桶 | gs://grok-code-session-traces |
會話追蹤上傳目標桶（原始串中與 event 相鄰出現） |
| 產物桶 | storage.googleapis.com/grok-build-public-artifacts |
公開建置產物儲存 |
| 環境變數 | GROK_TRACE_UPLOAD_BUCKET |
追蹤上傳目標桶 |
| 環境變數 | GROK_TRACE_UPLOAD_ENDPOINT_URL |
上傳端點 URL |
| 環境變數 | GROK_TRACE_UPLOAD_REGION / GROK_TRACE_UPLOAD_CREDENTIALS_FILE |
上傳區域 / 憑證檔案路徑 |
| 環境變數 | GROK_TELEMETRY_TRACE_UPLOAD |
追蹤上傳總開關 |
| 環境變數 | GROK_TELEMETRY_GCS_BUCKET |
遙測資料 GCS 桶 |
| 環境變數 | GROK_WORKSPACE_DATA_COLLECTION_DISABLED |
工作區資料收集開關（伺服端可覆蓋） |
| OAuth Scope | https://www.googleapis.com/auth/cloud-platform |
雲端平台存取 |
| OAuth Scope | https://www.googleapis.com/auth/devstorage.full_control |
GCS 儲存桶完全控制 |
D. 遙測與錯誤回報（旁路通道）
| 端點 | 協定 | 控制變數 |
|---|---|---|
https://grok.com/_data/v1/events |
HTTPS | GROK_TELEMETRY_ENABLED / GROK_TELEMETRY_EVENTS_URL |
https://api.mixpanel.com/track |
HTTPS | GROK_TELEMETRY_MIXPANEL_ENABLED / GROK_TELEMETRY_MIXPANEL_TOKEN |
o4508179396558848.ingest.us.sentry.io（project 4508179396558848） |
HTTPS | GROK_ERROR_REPORTING / GROK_CRASH_HANDLER |
localhost:4317（gRPC）/ localhost:4318（HTTP） |
OpenTelemetry | GROK_INTERNAL_OTLP_TRACES_ENDPOINT |
E. 認證與憑證機制
| 機制 | 證據 |
|---|---|
| 部署金鑰 | GROK_DEPLOYMENT_KEY（字串硬編碼 + 安裝資訊） |
| 本地憑證 | ~/.grok/auth.json |
| OAuth / OIDC | client_id=grok-cli，GROK_OAUTH_ENABLED / GROK_OIDC_CLIENT_ID |
| Bearer Token | Authorization: Bearer 標頭 |
| 內部服務標頭 | x-sa-bearer-token |
| 認證繞過開關 | GROK_DISABLE_API_KEY_AUTH |
F. 推斷的關鍵模組（字串 → 功能）
| 推斷模組 | 字串證據 | 功能推斷 |
|---|---|---|
repo_packager |
# v2 git bundle、git bundle、git clone |
呼叫 git bundle create 打包整庫 |
storage_uploader |
GROK_TRACE_UPLOAD_BUCKET、storage.googleapis.com、devstorage.full_control |
建構 multipart POST 到 /v1/storage |
settings_fetcher |
/v1/settings、trace_upload_enabled |
拉取伺服端控制標誌 |
permission_checker |
--deny、--always-approve、blocked by a permission policy |
本地讀取權限檢查（不攔上傳） |
telemetry_dispatcher |
GROK_TELEMETRY_EVENTS_URL、api.mixpanel.com/track |
按環境變數決定是否回報 |
auth_provider |
GROK_DEPLOYMENT_KEY、auth.x.ai、client_id=grok-cli |
處理 OAuth 與 Bearer |
G. 關鍵字串證據索引（速查）
# 上傳目標
gs://grok-code-session-traces
storage.googleapis.com/grok-build-public-artifacts
# 上傳通道開關（獨立於模型通道）
GROK_TRACE_UPLOAD_BUCKET
GROK_TRACE_UPLOAD_ENDPOINT_URL
GROK_TELEMETRY_TRACE_UPLOAD
GROK_WORKSPACE_DATA_COLLECTION_DISABLED
# 雲端憑證權限
https://www.googleapis.com/auth/devstorage.full_control
# 打包與復原
# v2 git bundle
git bundle
git clone
# 本地權限（只作用於讀取）
--deny
--always-approve
blocked by a permission policy
# 端點
https://api.x.ai/v1 (/v1/responses, /v1/storage, /v1/settings)
https://grok.com/_data/v1/events
o4508179396558848.ingest.us.sentry.io
其他發現：樣本中還存在 150 餘個
GROK_*環境變數，以及 AWS S3 相容支援（s3.、s3-fips.、s3.dualstack.、s3-accelerate.等端點、sts.amazonaws.com）與雲端中繼資料位址（169.254.169.254、169.254.170.2、metadata.google.internal:80）——表明其儲存後端可切換至 S3 相容物件儲存。
H. cereblab 封包擷取實測資料（外部動態證據，非本次樣本）
| 測量項 | 數值 | 說明 |
|---|---|---|
| 測試倉庫大小 | 64 MB – 12 GB | 多組測試 |
| 儲存通道上傳量 | 約 5.10 GiB | 整庫 bundle（封包擷取在此處被截斷，非自然結束） |
| 模型通道上傳量 | 192 KB | 同一會話實際模型上下文 |
| 上傳 / 模型比 | 約 27,800 : 1 | 證明上傳通道獨立且成規模 |
| 儲存請求 | 約 82 次 POST /v1/storage（約 73 個 75 MB 分片） |
全部 HTTP 200 |
| 儲存失敗 | 0 | 唯一失敗來自模型配額（402 / 429），與儲存無關 |
| 金絲雀驗證 | CANARY-XR47P2-NEVERREAD |
未被讀取的檔案從復原的倉庫中原樣取出 |
| Bundle 魔數 | # v2 git bundle |
從上傳 POST body 中擷取 |
參考資料：cereblab，《grok-build-exfil-repro》復現倉庫與《Gist dc9a40bc》完整分析；鈦媒體報導。相關背景另見安天研究院《從論文"預告"到行為越界——Anthropic 事件從實證到倫理的分析》。本文基於對離線樣本 grok-build-0.2.93~3880d629a6.pkg 的靜態分析，結合上述公開動態封包擷取證據交叉驗證；具體實現可能隨 Grok Build CLI 版本與伺服端策略變化。
AVL Code，AVL 安全引擎，與智慧隨行。安天瀾砥團隊出品。