Grok Build 会把整个代码仓库传给 xAI 吗？一次抓包实验把问题摆到了桌面上
分类：开发者工具与安全 Tag：xAI、Grok Build、代码隐私、AI 编程、数据安全 作者：陈墨｜OC 编辑
陈墨
一位开发者对 Grok Build CLI 0.2.93 做了网络层抓包，并在 GitHub Gist 公布实验过程和哈希校验信息。实验称，Grok Build 不仅会把它实际读取的文件送入模型请求，还会通过另一条存储通道上传包含已跟踪文件和 Git 历史的仓库快照。
一句话结论：这还不是“xAI 偷代码”的定案，却足以提醒开发者：把 AI 编程代理放进仓库，授权范围可能远大于聊天框里看到的那几段代码。
这次实验有价值的地方，在于作者没有只凭流量大小猜测。他准备了带有假密钥和唯一标记的测试仓库，用中间人代理记录请求，再从上传后的 Git bundle 中恢复出一个明确要求代理不要打开的文件。作者还在一个 12GB 的随机数据仓库上观察到，模型请求只传输了约 192KB，而存储接口已经接收超过 5.1GiB，上传当时仍未结束。
这里其实存在两条不同的数据通道。一条是模型工作时读取文件，把内容放进 /v1/responses；另一条是 /v1/storage，负责保存会话状态和仓库快照。关闭“Improve the model”只回答数据是否用于训练，并不自动等于停止完成任务所需的传输和存储。xAI 的消费者常见问题也把训练控制描述为对模型训练用途的选择，而不是一份针对 Grok Build 仓库上传行为的技术说明。
需要把边界说清楚。作者证明的是自己设备、自己账号和特定版本上的传输与存储，没有证明 xAI 用这些代码训练模型，也没有证明所有仓库、企业账号和后续版本都保持相同行为。xAI 目前公开的 Grok Build 页面 强调代码代理能力，但没有在快速介绍里醒目解释这套仓库快照机制。真正值得质疑的，是默认行为和用户预期之间的落差。
对团队来说，最实际的处理不是立刻禁用所有 AI 工具，而是把它当成会接触完整代码资产的第三方服务：不要在仓库中保存生产密钥；为代理使用独立工作区和最小权限凭证；敏感项目优先选择明确提供企业数据条款、保留周期和审计能力的方案。.gitignore 也不能被想当然地当成数据隔离边界，因为这次实验没有完整验证所有未跟踪文件的处理方式。
关键事实
- 实验对象是 Grok Build CLI 0.2.93，并非所有版本的普遍结论。
- 作者从已上传的 Git bundle 中恢复出未被代理读取的已跟踪文件及 Git 历史。
- 关闭“Improve the model”后，实验中的
trace_upload_enabled仍为开启状态。 - 实验没有证明上传内容被用于模型训练。
OC 判断
AI 编程工具的核心安全问题，已经从“提示词会不会泄露”升级为“代理获得了多大的工作区读取、打包和持久化权限”。训练开关、任务传输和诊断留存是三件事，产品不应把它们挤在一个模糊按钮后面。
为什么重要
- 对开发者：本地仓库不再天然等于本地数据，尤其要清理密钥和历史提交。
- 对企业：采购 AI 编程工具时，需要问清数据范围、留存时间、删除机制和企业账号差异。
- 对用户：隐私设置里的“不用于训练”，不一定代表“不上传”或“不保存”。
评论
围绕这篇文章补充信息、提出问题或分享观察。