鱼鱼连线 YYLX.IO｜AI中转站博客

鱼鱼连线 YYLX.IO｜AI中转站 博客

Grok Build CLI 被曝上传整个 Git 仓库

紧急提醒：Grok Build CLI 被曝上传整个 Git 仓库，包含私钥和机密的项目请立刻处理！

如果你正在私有仓库、公司项目或带有历史密钥的代码库里使用 Grok Build CLI，建议先暂停。

2026 年 7 月 11 日，Reddit 的 r/LocalLLaMA 出现一份针对 Grok Build CLI v0.2.93 的第三方抓包报告。报告作者称，Grok Build 不只会把模型实际读取的文件内容发送给 xAI，还会把整个 Git 仓库打包上传，其中包括所有已跟踪文件和完整提交历史。

更值得警惕的是：作者在关闭 “Improve the model” 后重复测试，仓库上传仍然发生。

Grok Build 不只会把模型实际读取的文件内容发送给 xAI，还会把整个 Git 仓库打包上传

先把结论说在前面：这是一份有复现步骤和抓包证据的独立研究报告，但目前不是 xAI 官方安全公告，也不能直接证明 xAI 使用这些代码训练模型。 它证明的是在作者的测试环境中，代码和 Git 历史离开了本机，并被服务端以 HTTP 200 接收。

在 xAI 给出明确解释或修复说明前，不建议把 Grok Build CLI 直接运行在包含商业代码、客户数据、NDA 项目、生产配置或历史密钥的仓库中。

报告到底发现了什么？

原作者在 macOS Apple Silicon 上测试了 grok 0.2.93，使用 mitmproxy 检查客户端的 HTTPS 流量，并在测试仓库中放入可识别的假密钥和 canary 文件。

报告给出的核心发现有三项。

1. 整个 Git 仓库被打包上传

作者向 Grok Build 发出的提示词是：只回复 OK，不要读取任何文件。

即便如此，抓包仍捕获到一个发送至 cli-chat-proxy.grok.com/v1/storage 的 Git bundle。作者把捕获的 bundle 重新 git clone 后，恢复出了那个明确要求不要读取的 canary 文件，同时也恢复出了仓库的完整 Git 历史。

这意味着该次上传并不只包含模型为了回答问题而打开的上下文，而是覆盖了仓库中所有已被 Git 跟踪的文件和历史提交。

作者随后在第二个无关仓库中重复测试，再次从上传的 Git bundle 中恢复出从未被 Agent 读取的 canary 文件。

2. 被读取的 .env 内容会原样进入请求和会话归档

测试仓库中有一个带假 API_KEY 和 DB_PASSWORD 的 .env / secrets.env 文件。当 Grok Build 读取该文件后，作者在 /v1/responses 模型请求和上传至 /v1/storage 的 session_state 归档中找到了完整、未脱敏的 canary 值。

这里必须说清楚一个边界：这次测试里的 .env 文件已被 Git 跟踪。原作者没有单独证明一个被 .gitignore 忽略、且从未被 Agent 读取的 .env 也会进入 Git bundle。

但这并不能让人放松。真实项目经常在早期提交、误操作、合并记录或旧分支中留下密钥。即使现在的工作区已经删除，完整 Git 历史仍可能把旧密钥一起带走。

3. 关闭“Improve the model”没有停止上传

报告作者关闭了 Grok 的 “Improve the model” 选项后重新测试，Git bundle 仍被上传，服务端设置中也仍显示 trace_upload_enabled: true 和 upload_enabled: true。

这和 xAI 官方 FAQ 的表述并不矛盾：官方把“Improve the model”定义为是否允许把新对话用于模型训练。它不是一个“禁止任何数据离开本机”的开关。

换句话说：

  • 退出训练，不等于本地运行；
  • 退出训练，不等于不上传；
  • 不用于训练，也不等于服务端不会为了推理、会话、同步、安全或其他产品功能处理和保存数据。

5.1 GiB 抓包意味着什么？

报告还用一个约 12 GB、主要由随机文件组成的仓库做了压力测试。在抓包被手动停止前，/v1/storage 已经成功接收约 5.10 GiB 数据，模型请求通道同期只有约 192 KB。

这个约 27,800 倍的体积差，是作者判断“后台上传和模型实际读取文件无关”的重要依据。

但也不要把它误读成“完整 12 GB 已经全部上传成功”。原始报告明确说明：测试在上传仍在继续时被中止，能够确认的是至少 5.10 GiB 已发送并返回 200。

为什么完整 Git 历史比当前代码更危险？

很多开发者检查当前目录后会觉得：.env 已经删了，密钥也已经换到环境变量里，应该没事。

可 Git 历史可能仍然保存着：

  • 早期提交过的 API Key、数据库密码和云厂商凭据；
  • 被删除的生产配置、证书、私钥或内部域名；
  • 客户名称、测试数据、工单编号和内部注释；
  • 尚未发布的功能、算法实现和商业逻辑；
  • Git 作者邮箱、分支信息、提交说明和事故修复记录；
  • 因合规、NDA 或客户合同不得离开指定环境的代码。

当前工作区“看起来干净”，不代表仓库历史干净。把完整 Git bundle 上传到第三方云端，风险范围远大于只发送当前任务相关的几个文件片段。

xAI 官方目前说了什么？

xAI 的消费者条款把代码、文件、文件夹甚至驱动器都列为可能提交给服务的 Input，并授予 xAI 为提供和改进服务而处理、存储和传输用户内容的广泛权利。隐私政策也明确把文件等输入归入 User Content。

但这些宽泛条款并不等于 Grok Build 的安装页已经清楚告知用户：客户端会默认创建并上传包含完整历史的 Git bundle。

公开的 Grok Build 企业部署文档目前把 storage.googleapis.com 描述为 CLI 安装包的备用 CDN，并称通过 npm 安装后，该域名只在安装或更新时需要；其“数据生命周期”章节描述了文件内容经推理代理发送给模型，却没有说明消费者客户端会把完整仓库快照保存到名为 grok-code-session-traces 的存储桶。第三方抓包报告观察到的行为与这套公开说明之间存在需要 xAI 澄清的明显空白。

截至 2026 年 7 月 12 日，我们没有在 xAI 的 Grok Build 公开更新日志中看到针对这份报告的修复说明。当前公开更新日志列出的最新版本是 v0.2.94，但没有提到仓库快照上传、Git bundle 或敏感文件脱敏。因此，也不能仅凭版本号变化就假设问题已经解决。

已经在私有仓库里运行过，马上做什么？

如果你已经用 Grok Build 打开过敏感仓库，建议按“代码和历史可能已经离开本机”的标准处理。

第一步：立刻轮换凭据

优先更换可能出现在当前文件或 Git 历史中的：

  • 云厂商 Access Key；
  • GitHub、GitLab、npm、PyPI 等访问令牌；
  • 数据库账号和连接串；
  • SSH 私钥、部署密钥和签名密钥；
  • 支付、邮件、短信、对象存储等第三方 API Key；
  • 内部服务 Token、Webhook Secret 和 CI/CD 凭据。

不要只删除文件。凭据一旦可能泄露，删除不等于失效，轮换或吊销才是关键。

第二步：扫描完整 Git 历史

不要只扫描当前工作区。使用 Gitleaks、TruffleHog 或企业内部密钥扫描工具检查全部提交、分支和标签，并结合云平台审计日志确认是否出现异常调用。

即使扫描没有命中，也要人工检查历史上曾经使用过的高价值凭据。自动扫描器不一定认识公司内部 Token 格式。

第三步：记录受影响范围

列出运行过 Grok Build 的仓库、时间、客户端版本、当时登录的账号，以及仓库涉及的客户、系统和凭据。企业环境应尽快通知安全、法务或合规负责人，由内部流程判断是否构成安全事件或数据出境问题。

第四步：再处理 Git 历史

如果历史中确实有敏感内容，可以使用 git filter-repo 等工具清理并强制更新远端。但顺序不要反：先轮换凭据，再清理历史。历史重写只能减少后续暴露，不能让已经外泄的凭据重新安全。

现在还要测试 Grok Build，最低限度怎么隔离？

最安全的临时措施是：不要在真实敏感仓库里运行。

如果必须评估，可以准备一个不含 .git、不含凭据、不含客户数据的脱敏副本，例如只导出当前提交：

mkdir -p ../grok-sanitized
git archive HEAD | tar -x -C ../grok-sanitized

然后在运行前再次进行密钥扫描，并把它放进一次性容器或虚拟机。注意：git archive 仍会导出当前提交中的所有已跟踪文件，所以它只能去掉 Git 历史，不能自动替你删除当前版本中的秘密。

还要注意以下几点：

  • .gitignore 是基本卫生措施，不是已经被本次报告证明有效的数据防泄漏边界；
  • 提示词里的“不要读文件”无法阻止报告中观察到的后台仓库上传；
  • Agent 的文件权限和 Shell 审批不能天然约束客户端自身的遥测或上传线程；
  • 单纯关闭“Improve the model”不能作为网络隔离措施；
  • 社区已有人给出关闭 telemetry、trace upload 和 codebase upload 的配置项，但目前不应在未抓包验证的情况下把它们当成可靠修复。

对于企业环境，真正可靠的控制应来自独立的沙箱、脱敏副本和出站网络策略，而不是只相信客户端界面的开关。

AI 中转站能解决这次问题吗？

不能直接解决。

这次争议指向的是 Grok Build CLI 客户端本身的仓库打包和上传行为。即使你更换模型、API Key 或中转入口，也不能自动证明官方客户端的后台上传逻辑已经关闭。

如果你的目标只是通过 API 使用 AI 模型，可以选择支持自定义 Base URL、目录白名单和沙箱策略的其他客户端，再接入 YYLX.IO 鱼鱼连线 等兼容 API 服务。这样可以把“模型入口”和“本地客户端权限”分开选择。

但无论使用官方 API 还是中转站，云端 AI 编程工具都会发送完成任务所需的上下文。中转服务也必须被纳入数据安全评估。对不能离开内网的代码，应优先使用本地模型、企业合约明确的数据通道，或完全离线的审查流程。

我们的建议

在 xAI 对仓库上传机制、默认行为、数据用途、保存周期、关闭方式和已上传数据删除路径作出明确说明前：

  1. 不要在生产仓库、公司私有仓库和 NDA 项目中直接运行 Grok Build CLI；
  2. 已经运行过的，按可能泄露完整已跟踪仓库与 Git 历史处理；
  3. 立即轮换历史中可能出现的密钥，并检查审计日志；
  4. 测试只使用脱敏、无历史、无真实凭据的一次性副本；
  5. 不要把“退出模型训练”误解成“数据不会上传”。

AI 编程工具拥有的本地权限越来越高。真正需要审查的不只是模型回答了什么，还包括客户端在后台读取了什么、打包了什么、发给了谁，以及用户是否拥有一个真正有效的关闭开关。

参考资料

说明：本文基于 2026 年 7 月 12 日可获取的公开资料整理。第三方报告测试的是 Grok Build CLI v0.2.93，行为可能随后续版本变化。本文不主张 xAI 已将相关代码用于模型训练，也不把单一研究者的测试等同于官方确认。

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注