Grok Build 不是只读代码，它一度把整个 Git 仓库上传到云端
作者：韩启明
韩启明
OC 原创示意图。
据 International Cyber Digest 报道，安全研究者 cereblab 在检查 Grok Build CLI 0.2.93 的网络流量时发现，这个工具会把项目中被 Git 跟踪的文件连同完整提交历史打包，上传到一个 Google Cloud Storage 存储桶。上传动作并不取决于 Agent 实际打开了哪些文件。
一句话结论： 目前能确认的是 Grok Build 曾经发生过范围远超推理所需的代码上传，不能确认的是这些数据被用于训练；对开发者来说，真正的警报是产品界面、隐私开关和实际网络行为之间出现了明显落差。
研究者做了一个很直观的对照实验：一个大约 12GB 的测试仓库，发给模型的请求只有约 192KB，但后台上传量达到 5.1GB。放在测试仓库里的诱饵 .env 凭据也原样出现在上传内容中。换句话说，这不只是“云端模型当然要看到你发过去的代码”，而是客户端额外收集了几乎整个仓库。
这两件事很容易被混在一起。使用云端编码 Agent，本来就意味着你主动提供的上下文会离开本机；但用户通常会理解为“Agent 读了什么，就上传什么”。完整 Git 历史里可能留着已经删除的密钥、旧客户数据、未发布功能和曾经回滚的内部实现，它的敏感范围往往比当前工作区更大。
OC 原创解释图：模型请求与仓库上传是两条不同的数据路径。
更值得注意的是，研究者关闭了“Improve the model”后，上传仍然发生。这个开关从字面上控制的是内容是否用于改进模型，并不等于零数据留存，也不等于代码不会离开设备。类似的措辞在 AI 产品里已经越来越常见，但普通用户很容易把“不同意训练”理解成“数据不上传”。如果产品还有调试追踪、会话恢复或质量分析通道，就应该把用途、范围、保留时间和删除方式单独写清楚。
报道发布后，研究者观察到服务端配置变成了 disable_codebase_upload: true 和 trace_upload_enabled: false。同一版本客户端随后连续六次测试都没有再上传，说明 xAI 可以在不更新软件的情况下关闭这个行为。不过，这项验证只覆盖一台机器和一个账号，不能证明所有用户此前都受到影响，也不能证明修复已经向所有账号生效。xAI 目前仍欠缺一份完整说明：上传为何发生、保留了多久、哪些用户受影响，以及历史数据是否已删除。
本站编辑韩启明认为，这件事的重点不是把“上传”夸大成“偷代码训练”，而是开发工具正在获得越来越大的本机权限，厂商却仍沿用消费级聊天产品那套模糊开关。对团队用户来说，隐私政策不该替代技术验证：应该检查 Agent 的出站域名和流量，把密钥移出仓库与 Git 历史，并优先选择能提供组织级零数据留存、审计日志和明确数据边界的方案。
开发者还需要接受一个不太舒服的现实：只要工具能读取仓库，仓库里的任何内容都应该被视为“可能离开本机”。网络隔离、最小目录授权和临时凭据，不是等厂商出事以后才补的安全措施，而应该成为高权限 Agent 的默认运行方式。
评论
围绕这篇文章补充信息、提出问题或分享观察。