摘要：2026 年 7 月 12 日，安全研究员 cereblab 发布 wire-level 分析，证明 xAI 的 Grok Build CLI（v0.2.93）会在用户不知情的情况下，将完整 Git 仓库（含提交历史、未读文件、.env 密钥）打包上传至 Google Cloud Storage bucket grok-code-session-traces。关闭「Improve the model」隐私开关后上传行为依然继续。本文梳理事件时间线、技术证据、竞品对比与开发者应急措施。

2026 年 7 月 12 日，一篇附带完整网络抓包证据的技术分析，让 xAI 的 AI 编程工具 Grok Build 陷入了数据隐私风暴。

安全研究员 cereblab 通过 mitmproxy 对 Grok Build CLI 0.2.93 进行 wire-level 审计，发现该工具在正常解答编码问题之外，还悄悄执行着另一项任务：将用户本地 Git 仓库的完整内容——包括从未被读取的文件、完整提交历史、以及未脱敏的 .env 密钥——打包上传至 Google Cloud Storage bucket grok-code-session-traces。

更关键的是，用户界面上的隐私开关对此毫无作用。

一、事件时间线

时间 事件
2026-07-12 cereblab 发布 GitHub Gist 技术分析，公布完整网络抓包与可复现步骤
2026-07-13 分析登上 Hacker News 首页；Elon Musk 在 X 承诺删除所有已上传数据
2026-07-13 cereblab 复测发现 /v1/storage 上传已停止，服务器返回 disable_codebase_upload: true
2026-07-14 多家安全媒体报道；分析版本 0.2.99 二进制文件中上传代码仍存在，仅靠服务器 flag 阻止

二、技术证据：三个关键发现

2.1 整个仓库被上传，而非仅任务相关文件

cereblab 的测试使用了 mitmproxy 对 Grok Build 进行中间人抓包，方法无需越狱、无需提权：

  1. 安装 mitmproxy 并信任其 CA 证书
  2. 通过 HTTPS_PROXY 环境变量路由 Grok Build 流量
  3. 记录所有请求的方法、路径、响应状态、请求体大小

在 12 GB 的测试仓库中（内容为 agent 从未读取的随机文件），两个通道的数据量形成了鲜明对比：

  • 模型推理通道（POST /v1/responses）：仅 192 KB
  • 存储上传通道（POST /v1/storage）：5.10 GiB，分 73 个 ~75 MB 的 chunk，全部返回 HTTP 200

两者比例约为 27,800:1。这意味着即使模型根本不需要这些数据，它们仍然离开了本地机器。

2.2 未读文件与密钥被完整打包

为了证明上传范围不限于「模型读取过的文件」，cereblab 在仓库中放置了 canary 文件：

  • src/_probe/never_read_canary.txt：明确告诉 agent 不要打开此文件
  • .env：包含格式化的 API_KEY=CANARY... 和 DB_PASSWORD=CANARY...

在直接提示 “Reply exactly: OK. Do not read or open any files.” 的测试中，cereblab 成功从上传的 Git bundle 中恢复出 never_read_canary.txt 的完整内容，并保留了唯一标识符。该 bundle 同时携带了仓库的完整 Git 历史（4 次提交、47 个文件）。

这一发现意味着：你告诉 Grok Build 不要读的文件，它仍然会上传。

2.3 隐私开关无法阻止上传

这是最具误导性的部分。Grok Build 用户界面中唯一的隐私控制是 「Improve the model」（允许模型改进）开关。

cereblab 将该开关关闭后复测，结果令人震惊：

  • /v1/settings 接口仍返回 trace_upload_enabled: true
  • 存储上传通道继续正常工作
  • 完整仓库 Git bundle 仍然被接受（HTTP 200）

原因：这个开关控制的是训练授权（xAI 是否可将数据用于改进模型），而不是数据传输控制（数据是否离开你的机器）。这是两个完全独立的机制，而 Grok Build 只暴露了前者给用户。

三、上传的目的地：Google Cloud Storage

二进制文件中硬编码了目标存储桶名称：

  • Bucket：grok-code-session-traces
  • 路径格式：gs://grok-code-session-traces/repo_changes_dedup/v2/supplemental/sha256_…

该机制并未出现在 Grok Build 的安装脚本或快速入门文档中。上传通过一个独立的 Rust crate（xai-data-collector）在后台协调，与模型推理通道分离。

cereblab 还发现了一个副作用 bug：~/.grok/upload_queue 会在每次运行时 staging 约 3 GB 的仓库快照，高负载下可能增长到数十 GB，耗尽本地磁盘空间。

四、竞品对比：Grok Build 是唯一「全量上传」者

在披露后，cereblab 对主流 AI 编程工具进行了同样的 wire-level 对比测试：

工具 上传行为
Grok Build 上传整个仓库（Git bundle + 完整历史），即使文件未被读取
Claude Code 仅上传实际打开的文件
Codex CLI 仅上传实际打开的文件
Gemini CLI 空闲测试中无仓库上传；真实任务测试被 quota 阻断

Grok Build 是测试范围内唯一一个将整个工作区打包上传的工具。其他工具的行为符合用户预期：只发送完成当前任务所需的代码片段。

五、xAI 的回应与修复

5.1 临时缓解

2026 年 7 月 13 日，在事件曝光约 24 小时后，xAI 通过服务器端 flag 停止了上传行为：

  • 服务器开始返回 disable_codebase_upload: true
  • /v1/storage 上传通道停止响应

值得注意的是：这是静默的服务器端切换，没有客户端软件更新，没有 changelog 条目，没有安全公告。

5.2 新命令：/privacy

xAI 同时推出了 /privacy CLI 命令，允许用户：

  • 选择退出数据保留
  • 触发对已同步数据的「追溯删除」

但 cereblab 的后续测试显示，/privacy 控制的是数据保留，而非数据传输。这意味着在 7 月 13 日之前上传的数据已经离开了用户的机器。

5.3 Elon Musk 的承诺

Elon Musk 在 X 上表示，所有在修复之前上传的用户数据将被「完全、彻底删除，什么都不留」。截至 7 月 14 日，这一承诺尚未经独立验证。xAI 未公布：

  • 删除时间线
  • 受影响用户数量
  • 已存储仓库的清单

5.4 代码仍留在二进制中

对版本 0.2.99 的分析（cereblab 及 weklund）显示，上传代码仍然存在于编译后的二进制文件中，只是被服务器 flag 暂时阻止。这意味着 xAI 可以在不发布客户端更新的情况下，随时为任意用户重新启用上传。

六、开发者应立即采取的措施

6.1 轮换所有密钥（最高优先级）

如果曾在包含真实密钥的仓库上运行过 Grok Build：

  • 立即轮换 API key、数据库密码、云 token、SSH key、webhook secret
  • 不要只删除本地 .env 文件——Git 历史中的密钥仍然可能已被上传
  • 检查 .env 是否曾被 commit 过；如果是，视为已泄露

6.2 运行 /privacy 并启用 ZDR

  • 在 Grok Build 中执行 /privacy 命令
  • 企业用户应确认已启用 Zero Data Retention (ZDR) 配置
  • 注意：ZDR 目前仅覆盖企业团队和 API 密钥用户；个人 SuperGrok / X Premium Plus 订阅者依赖 /privacy 命令

6.3 审计网络流量

mitmproxy 是免费、开源的工具，无需提权即可使用。任何处理敏感代码库的组织都应在部署 AI 编程工具前进行 wire-level 审计。

cereblab 的复现仓库已公开：github.com/cereblab/grok-build-exfil-repro

七、深层问题：AI 编程工具的数据边界

7.1 「本地优先」营销 vs 实际行为

Grok Build 事件揭示了一个行业-wide 的认知偏差：许多开发者默认「AI 编程工具只发送我让它读的文件」。实际上：

  • 云编码工具的第一通道（发送代码到远程模型）是预期内的
  • 但第二通道（将整个工作区打包上传）不是

Grok Build 的 27,800:1 比例表明，这不是「顺便多传了一点」，而是一个独立的、默认开启的全量收集机制。

7.2 隐私开关的「双轨欺骗」

Grok Build 的隐私设置架构存在根本性问题：

  • 训练授权（Improve the model）：用户可见、可控制
  • 数据传输范围（整个仓库 vs 任务文件）：用户不可见、不可控制

当用户关闭训练开关时，他们以为自己选择了「更私密的模式」，但实际上数据仍然以相同规模离开机器。这种「双轨设计」在隐私政策文件中可能被宽泛表述所掩盖，但在实际行为上构成了误导。

7.3 Git 历史的隐藏风险

Git bundle 格式的一个特殊之处在于：它携带完整对象历史。这意味着：

  • 已从工作区删除的 .env 文件，如果在过去的 commit 中存在，仍然会出现在 bundle 中
  • 即使是「已删除的密钥」也等于「已上传的密钥」
  • 标准的 .gitignore 只能防止未跟踪文件进入仓库，无法保护历史中的敏感内容

八、与其他事件的对比

将 Grok Build 事件与本月另一桩 AI 隐私事件放在一起看，会看到一个有趣的对称：

事件 公司 行为 检测方式 公开性
Grok Build 仓库上传 xAI 默认上传整个仓库 + 密钥 独立研究员 wire capture 7/12 公开，无官方公告
Anthropic 隐写门 Anthropic 隐写术检测中国用户并编码进系统提示词 Reddit 逆向工程 6 月底公开，官方称「实验性」
Claude Code 对比测试 Anthropic 仅上传实际打开的文件 cereblab 对比测试 作为对照组公开

有趣的是，在 cereblab 的对比测试中，Claude Code 表现最为克制：仅上传模型实际读取的文件，且 never_read_canary.txt 从未离开本地。这与 Anthropic 「隐写门」事件中的争议行为形成了微妙的对照——一家公司可能在用户侧检测上采取激进手段，却在数据上传范围上保持克制；另一家公司（xAI）则在用户不知情的情况下进行了更大规模的数据收集。

九、尚未解答的问题

  1. 上传的原始目的是什么？ xAI 未解释为什么需要完整仓库快照。最合理的推测是「让模型在「思考」阶段访问整个代码库而不反复调用工具」，但这一推测尚未得到官方确认。
  2. 数据保留了多久？ 从 3 月上线的机制到 7 月 13 日关闭，仓库数据在 grok-code-session-traces 中存储了至少数月。xAI 未公布保留策略。
  3. 有多少用户受影响？ 未公布。Grok Build 的下载量和活跃用户数未知。
  4. Gitignored 文件是否也被上传？ cereblab 未单独测试此场景。从 file_access_tracker crate 的行为推断，上传机制似乎是「读取驱动」的，但这一结论需要进一步验证。
  5. Elon Musk 的删除承诺是否已兑现？ 截至 7 月 14 日，无独立审计确认。

十、结语

Grok Build 事件的核心不是「AI 工具会发送数据到云端」——这是云服务的固有属性。核心问题是：

默认发送的数据范围，远超用户完成任务所需的范围，且用户界面上的隐私控制对此毫无约束力。

当一个开发者要求 Grok Build「修复一个 bug」时，他预期的是相关文件被发送到 xAI 的模型。他没有预期的是：整个 Git 仓库、完整提交历史、以及任何曾经被 commit 过的密钥，都会以 Git bundle 的形式出现在 Google Cloud Storage 中。

更令人不安的是，这一行为被设计为默认开启、无需显式授权、且无法通过用户界面关闭。隐私开关控制的是「数据用途」，而不是「数据出境」。

对于企业开发者和独立贡献者而言，这条规则可能需要被永久铭记：

如果你在本地运行一个 AI 编程工具，并且你不清楚它打开了哪些网络连接，就假设它已经把你整个仓库发送了出去。

这不是对 xAI 的特别指责，而是对所有「本地优先」营销话术的普遍提醒。在 wire-level 审计证实之前，本地 ≠ 私密。

🤔 你怎么看 Grok Build 的「全量上传」行为？你认为 AI 编程工具的默认数据边界应该是什么？欢迎在评论区讨论。

本文基于 cereblab 的公开技术分析（GitHub Gist / cereblab.com）、The Hacker News、CyberNews、TechTimes 等报道综合整理。