Grok Build 被曝静默上传完整代码仓库：AI代码助手的隐私红线究竟在哪

七月中旬开发者圈子里炸开了一锅。安全研究员 Cereblab 抛出一组 wire-level 分析结果直指 xAI 旗下的 Grok Build CLI 存在一个让人脊背发凉的默认行为——它会在开发者毫不知情的情况下把整个本地代码仓库打包上传到 Google Cloud Storage。不是片段不是当前打开的文件而是完整的 Git 仓库连同历史提交记录、.env 里的密钥、甚至那些被明确告知不要读取的文件一并塞进了云端的存储桶。这件事之所以引发轩然大波倒不是因为人们对 AI 工具上传数据这件事本身有多意外。毕竟任何云端代码助手要想干活总得把代码片段发给模型。真正让人不安的是量级和隐蔽性。Cereblab 的测试显示一个 12GB 的测试仓库Grok Build 实际用于模型推理的数据只有约 192KB但往云端存储桶里塞了整整 5.1GB。这中间的差距不是几倍、几十倍而是将近两万八千倍。换句话说模型真正需要的代码连上传总量的零头都算不上。为了验证这个发现Cereblab 在测试仓库里埋了几只金丝雀——在 .env 文件里放了假密钥在从未被读取的文件里塞了唯一标记。结果这些标记原封不动地出现在了网络抓包里而且出现在两个不同的通道里。第一个通道是模型交互通道也就是大家预期中的那个Grok Build 把当前任务相关的文件内容发给模型获取回复。这个通道虽然也会把 .env 里的密钥明文传上去但至少还在为了完成当前任务的合理范围内。第二个通道才是问题的核心。Grok Build 会把整个仓库打包成一个 Git bundle通过 POST /v1/storage 接口上传到名为 grok-code-session-traces 的 Google Cloud Storage 桶。这个上传行为完全独立于模型实际读取了哪些文件。Cereblab 甚至做了一个极端测试给 Grok Build 的指令是只回复 OK不要打开任何文件结果仓库照样被完整上传。更离谱的是从抓包里克隆出来的 Git bundle 里那个被明确告知不要读取的文件完好无损连同完整的四次提交历史、四十七个文件全部在云端留了底。这意味着什么意味着你仓库里的所有内容——包括那些已经 git rm 掉但还在历史记录里的旧密钥、包括那些你不小心提交过又删掉的配置文件、包括你还没来得及开源的内部算法——全都被 xAI 的服务器收了一份。而且这个过程不需要你点任何同意也不需要你手动选择上传范围。很多开发者看到这儿的第一反应大概是我不是关了改进模型的选项吗问题就出在这儿。Grok Build 的隐私设置里确实有个Improve the model的开关关掉之后理论上 xAI 不会用你的数据训练未来的模型。Cereblab 专门测试了这个场景——关掉开关重新运行 CLI结果 /v1/storage 的上传通道纹丝不动服务器返回的 trace_upload_enabled 依然是 true。也就是说那个你以为在保护隐私的开关只管数据会不会被用来训练根本不管数据会不会被传走。这是两个完全不同的控制层面。训练授权决定的是数据上传之后的用途传输授权决定的是数据能不能离开你的机器。Grok Build 只给了用户前者却把后者藏在了服务器端的 HTTP 请求头里。在漏洞曝光之前那个请求头的值是 disable_codebase_upload: false也就是默认允许上传。开发者界面里连个影子都看不到。事件发酵之后xAI 在社交媒体上给出了回应。他们的说法大致是企业用户本来就有零数据保留ZDR策略普通用户可以通过 /privacy 命令开启隐私模式开启后会删除之前同步的所有数据。马斯克甚至亲自发推承诺所有此前上传的用户数据将被彻底删除不留任何痕迹。听起来像是亡羊补牢但细想之下漏洞百出。首先/privacy 命令和代码库上传根本是两个系统。Cereblab 的复测证实/privacy 只控制遥测通道每次大约 18KB 的产品改进数据对那个动辄几个 GB 的仓库上传通道毫无影响。xAI 的公开声明把这两个通道混为一谈很难说不是有意模糊焦点。其次所谓的修复是服务器端的静默开关。漏洞曝光后xAI 在服务器端把 disable_codebase_upload 改成了 true上传行为确实停了。但客户端的 0.2.93 版本二进制文件里上传代码原封不动地还在。这意味着 xAI 随时可以在不推送任何更新的情况下重新打开这个开关。没有补丁没有版本升级没有安全公告只有一个远程可控的阀门。开发者连自己的代码什么时候会被再次上传都不知道。更关键的是xAI 至今没有解释为什么要收集完整仓库。一个可能的推测是性能优化——把完整仓库放到云端模型在思考时就不用反复回客户端取文件减少延迟。但这个推测从未得到官方确认。至于那些已经上传到 grok-code-session-traces 桶里的数据有多少、保存了多久、有没有被备份、有没有进入训练流水线xAI 一个字都没提。这件事给所有用 AI 编程工具的人敲了一记闷棍。Grok Build 不是第一个云端代码助手也不会是最后一个但它可能是第一个被实锤默认上传完整仓库的主流工具。Cereblab 在横向对比里测试了 Claude Code、Codex 和 Gemini CLI这些工具都没有出现类似的整仓上传行为。Grok Build 在这个维度上确实是个异类。对于已经在用 Grok Build 的开发者眼下最务实的做法不是等 xAI 发公告而是立刻行动。把仓库里所有可能暴露的密钥、数据库密码、API Token 全部轮换一遍。Git bundle 带着完整历史你删掉的文件照样在提交记录里躺着。用 mitmproxy 或 Charles Proxy 这类工具自己抓包验证。Grok Build 没有证书固定任何人都能复现 Cereblab 的测试看看自己的数据到底在往哪飞。如果还在用 Grok Build至少跑一遍 /privacy 命令虽然它管不了仓库上传但能关掉遥测数据。同时检查网络出口对 grok-code-session-traces 这个域名做拦截。长期来看敏感项目尽量用本地优先的开源方案比如 OpenCode 这类 API 直连工具数据走不走、走多少自己说了算。Grok Build 这件事暴露的不仅是某个产品的隐私设计缺陷而是整个 AI 编程助手行业的信任赤字。当工具厂商把本地优先隐私保护挂在嘴边实际行为却由服务器端的一个隐藏开关决定时开发者凭什么相信界面上的勾选框Cereblab 的分析之所以在 Hacker News 上引发上百条讨论正是因为它提供了一种可复制的验证方法。不需要越狱不需要 root一个 mitmproxy 就能让工具的底裤暴露无遗。这或许才是这件事最有价值的副产品——它证明了一个道理在 AI 工具越来越深的介入开发流程的今天信任但验证不再是安全团队的专利而是每个开发者都应该养成的肌肉记忆。xAI 最后会不会彻底移除仓库上传的代码路径、会不会发布正式的安全公告、会不会给受影响的用户一个交代目前都是未知数。但有一点是确定的那个曾经默认开启的云端上传通道已经让无数开发者的代码仓库在不知情的情况下裸奔了一程。这段历史删不删得干净恐怕只有 xAI 服务器上的日志知道。