安全研究团队Cereblab本周披露，xAI旗下编程工具Grok Build（v0.2.93版本）会把用户整个代码仓库打包成Git bundle上传到云端，其中包括被明确告知“不要打开”的文件，甚至已经从提交历史里删除的敏感内容。研究员在测试一个大型仓库时记录到，存储通道传输的数据量约为5.1 GiB，而同一时间模型推理请求只用了约192 KB——两者相差两万多倍。这不是上下文注入的正常损耗，是另一条独立通道在悄悄搬家。
一次被抓包的"隐形通道"
Cereblab的测试流程很直接：抓包监控Grok Build CLI在处理代码任务时的网络请求，结果发现除了正常的模型请求外，还有一路流量把整个仓库连提交历史一起打包送到了云存储。这个现象在第二个仓库测试中被复现，说明不是偶发。面对一个12GB的仓库，研究员甚至没等传输跑完就主动中止了测试。
真正让人意外的是"改进模型"开关完全挡不住这件事。很多用户以为关掉这个选项就等于数据不出本机，但它控制的其实是训练和数据使用许可，跟数据会不会离开设备是两套独立机制。这个认知误区，很可能是问题拖了一段时间才被发现的原因之一。
官方文档和实测数据在打架
xAI公开文档写得很明确：Grok Build不会自动把整个仓库上传到通用云存储，只有被选中或读取为上下文的代码内容才会通过TLS传输到推理服务。可Cereblab的抓包证据摆在那里——5.1GB的存储通道流量，完整的Git bundle，被明确排除的文件也在其中。文档承诺和实际行为，这次是正面冲突，不是滞后或误读能解释的。
一个开关能骗过多少用户，就能拖多久的问题
xAI最初的回应也没说到点子上，声称"/privacy"命令能禁用数据保留并删除已同步数据。Cereblab随即指出，这个命令只是单次会话的保留开关，不是修复漏洞的那个控制项。真正起作用的，是服务器端下发的"disable_codebase_upload: true"标志，以及本地配置里同名的开关。
谁该在意，接下来看什么
对已经用Grok Build处理过私有仓库的团队，最实际的动作是两件事：确认本地配置里disable_codebase_upload = true已经生效，再回头审查Git历史里是否曾经提交过密钥或凭证——即便当时删掉了，只要提交历史存在，就可能已经跟着仓库一起被打包传走。
- 风险.目前只能确认数据被传输并被服务器接收，无法确认xAI是否读取、存储或用于训练，这部分仍需要独立审计验证。
xAI在服务器端下发了禁用标志，理论上上传行为已经停止；马斯克在X上表态称此前上传的数据会被"彻底删除"，但目前没有第三方审计确认删除已经完成。启用了零数据保留（Zero Data Retention）条款的企业客户，理论上不受推理层持久化影响，普通消费者账号的风险敞口则完全是另一回事。
这件事对整个AI编程工具品类的杀伤力，未必在于Grok Build一家做错了什么，而在于"默认沙盒关闭、默认信任用户配置"这套行业惯例本身就留了空子。GitHub Copilot、Claude Code这类工具的核心卖点之一就是"只传相关文件"，这次的对照恰恰说明，这条承诺能不能兑现，光看文档是不够的，还得有人愿意抓包去验证。