代码生成能力大爆发的时代，智能体的行为更需要可见、可控。
北京时间 7 月 12 日前后，安全研究者 cereblab 公开了一份对 Grok Build CLI 的抓包分析，随后被多家中文媒体转述。核心指控只有一句：当你在一个仓库里运行 Grok Build CLI v0.2.93，它会把整个仓库、连同完整的 git 历史打包成 git bundle，通过一条独立于模型对话的通道上传到 xAI 的 Google Cloud Storage 存储桶 grok-code-session-traces——即便你明确要求它不要读取任何文件，即便你在设置里对敏感文件配置了拒绝读取。
cereblab 的抓包给了这句指控一个量级：一个 12 GB 的测试仓库，一次会话里真正用于模型对话的流量只有 192 KB，后台却静默外发了约 5.10 GiB 的完整仓库包——两者相差约 27,800 倍。他还预先在仓库里放了一个明确标记「不要打开」的诱饵密钥文件，事后从云端抓到的包里 git clone 出来，那个文件原样还在：上传通道里没有任何文件过滤。
这类指控适合用技术手段核验，而不是停留在转述。我们拿到了 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 安全引擎，与智能随行。安天澜砥团队出品。