2026 年 7 月 13 日，独立安全研究者 cereblab 更新了一份针对 xAI 官方 Grok Build CLI 0.2.93 的网络层分析：在其测试环境中，工具不仅会把智能体主动读取的文件送入模型请求，还会通过另一条存储通道上传整个 Git 代码库快照。对使用 Grok Build 处理私有仓库的团队来说，最稳妥的动作不是等待争论结束，而是先暂停在敏感仓库中运行该版本，检查网络流量和本地配置。
这项结论来自研究者自己的设备、测试账号与带有假密钥的诱饵仓库，并附有复现脚本、请求记录和哈希校验。它不是 xAI 的官方说明，也不能自动外推到所有账号、平台和后续版本。
两条数据通道需要分开理解
报告把观察到的传输分成两类。第一类是模型完成任务所需的上下文：被智能体读取的文件内容进入 /v1/responses 请求。研究者称，一个被读取且已纳入测试仓库的 .env 文件没有经过内容脱敏，其诱饵密钥出现在请求与会话归档中。
第二类更值得关注。即使提示词明确要求“只回复 OK，不要读取文件”，研究者仍捕获到经 /v1/storage 上传的 Git bundle；把该文件重新克隆后，可以恢复一个智能体从未打开的跟踪文件以及完整提交历史。另一次 12GB 随机数据仓库测试中，存储通道在实验被手动停止前已传输至少 5.10GiB，而模型对话通道总量只有约 192KB。这个差异支持“整库快照与模型按需读取是两套机制”的判断。
报告没有证明什么
上传和存储不等于用于模型训练。研究者明确表示，没有证据证明 xAI 使用这些代码训练模型，也没有穷尽所有账户、系统和配置组合。报告对“文档未披露”的判断，也只覆盖其检查过的安装与快速入门材料。因此，准确的表述应是“0.2.93 在特定实测条件下出现完整仓库上传”，而不是把数据用途或影响范围写成定论。
截至本文发布，xAI 尚未在公开文档中给出与这份报告逐项对应的说明。GitHub 讨论中有人给出了关闭遥测和代码库上传的配置项，但团队不应仅凭一条配置就假定风险已经消失，仍应通过抓包或出口审计验证实际行为。
开发团队现在应该做什么
- 不要让云端编码智能体直接接触生产密钥、客户数据和未披露源码；密钥应放在仓库外并定期轮换。
- 把智能体放进最小权限的临时工作区，只复制完成任务必需的文件，避免直接打开完整单体仓库。
- 为编码代理设置网络出口日志和域名白名单，升级版本后重新做一次传输范围验证。
- 如果已经用 0.2.93 处理过敏感仓库，按潜在外传事件盘点跟踪文件、历史提交中的密钥与访问令牌，并优先轮换可用凭据。
这次争议揭示的核心问题并非“云端工具会不会发送代码”——云端模型要工作，本就需要接收必要上下文。真正需要产品方说清的是：发送哪些文件、是否包含未读取内容、保存多久、训练开关是否同时控制存储，以及企业能否独立验证这些边界。
来源与说明
主要依据为研究者发布的 网络层分析 与 公开复现仓库；数据用途边界同时参考 xAI 隐私政策。本文将研究者实测、公开政策与编辑判断分别表述。
