马斯克的AI，把你的整个代码库连锅端走, 连密钥都不放过！！！

关注飞总聊IT，了解IT行业的方方面面。

一个安全研究人员，一个叫mitmproxy的抓包工具，一台Mac，就把马斯克旗下xAI的编程助手Grok Build按在地上曝了个底掉——你以为它只是在帮你写代码，其实它顺手把你整个项目连根拔起，打包送去了自己的云端服务器,一个字节都没留下。

研究者以cereblab为化名（X平台账号是@cereblab，本人叫Hari）在7月12日公布了这份分析报告：Grok Build版本0.2.93在处理编程任务的时候，会在后台把整个被Git追踪的项目仓库——连同完整的提交历史，也就是你代码库里所有曾经写过、又删掉的秘密——打包成一个Git bundle,悄悄上传到一个叫grok-code-session-traces的谷歌云存储桶里，这个存储桶归xAI管理。

这件事最要命的地方，不是"AI编程工具会上传代码"这件事本身——这本来就是云端编程助手的常规运作方式，为了完成任务，把相关代码片段发给远程模型是必要的。

问题出在"上传范围"上。 cereblab用一个12GB的测试仓库做了对比实验，结果相当离谱：真正跑去模型那边、用来完成编程任务的流量只有大约192KB，但走存储通道上传出去的数据却高达5.1GB，两者相差大约27800倍。

换句话说，Grok Build压根不是"发送任务需要的文件"，而是把整个代码库原封不动地打包带走了。

为了把这个结论钉死，cereblab还做了一个更狠的验证——他在测试仓库里埋了两个"金丝雀"标记：一个.env文件里写着一串明显是伪造的API密钥和一个模拟数据库密码，另外还有一个文件他明确告诉Grok Build"不要读取"。

结果呢？那串伪造密钥原封不动地出现在了截获的网络流量里，而那个被明令禁止读取的文件，最后也被他从截获的Git bundle里成功克隆了出来，内容一字不差。

也就是说，AI根本没打开那个文件去"学习"，但上传程序照样把它一并打包带走了。

这就是"连密钥都不放过"这句话的真正分量所在——Git提交历史里往往藏着早就已经从工作目录里删除、但从未从版本历史里彻底清除的敏感信息，比如某个开发者手滑提交过又删掉的密钥、内部接口地址、客户数据。你以为删掉了就是删掉了，但只要它曾经被提交过，这类"历史遗留污点"就会随着完整的Git bundle一起，原封不动地被连锅端走。

更让人后背发凉的是接下来这部分。xAI一直对外宣传Grok Build"会话期间代码库中的任何内容都不会传输到xAI服务器"，产品文档里也把它包装成一款"本地优先"的工具。

cereblab专门去测试了这句承诺——他关掉了Grok Build里那个面向用户的核心隐私选项"改进模型"（Improve the model），照理说这应该能阻止数据外传。

结果重新运行之后，服务器的/v1/settings接口依然稳稳地返回trace_upload_enabled: true，存储通道该传照传，一个字节都没少。

原因说穿了很简单：这两个开关根本管的不是一回事。"改进模型"这个选项，控制的是"你的数据会不会被用来训练未来版本的模型"；而真正决定"你的代码会不会离开这台机器"的，是另一个完全独立、且从未暴露给用户的技术开关。

用户以为自己关掉了阀门，实际上关的只是隔壁那根根本不相干的水管。

横向一对比，问题更清楚 cereblab没有止步于揪出Grok Build一家，他用同样的抓包方法，把Claude Code、Codex、Gemini这几款同类竞品也测了一遍。

结果是：Claude Code和Codex都只发送AI实际打开过的文件，那个被埋进去的"不要读取"标记文件，一次都没有离开本地机器；Gemini在空闲状态测试中也没有发送任何仓库打包数据，虽然它在更贴近真实场景的测试里因为触发了配额限制没能完整跑完。

这个对比结果说明,把整个代码库连同完整历史打包上传,并不是这类工具的行业惯例,而是Grok Build独有的问题。

报道曝光之后,xAI没有走正式安全公告的流程,而是通过社交媒体做出了回应——马斯克亲自确认了这次上传行为的存在,并表示公司会删除此前所有Grok Build收集到的用户数据。

技术层面,xAI通过服务器端悄悄下发了一个新的标志位disable_codebase_upload: true。cereblab在报告发布一天后重新测试了同一个0.2.93客户端,发现服务器现在返回的是disable_codebase_upload: true加上trace_upload_enabled: false,连续六次重测都没有再观察到仓库上传行为,这说明xAI确实在服务器端做了一次静默的远程修复。

但这个修复目前只在cereblab自己的一台机器、一个账号上得到验证，没有办法确认这个修复是不是已经全局生效、是分阶段推送还是永久性的。

而且截至目前，xAI既没有发布正式的安全公告，也没有说明此前那些已经上传到grok-code-session-traces存储桶里的代码库究竟会被怎么处理、留存了多久、是否已经被员工查看过。

官方更新日志里，7月12日发布的0.2.98版本，只字未提这次仓库上传的问题。

cereblab在报告里也很坦诚地划清了证据边界：这些抓包数据只能证明"未经披露的传输和存储确实发生了"，并不能证明xAI用这些代码训练过模型，也不能证明有员工查看过这些数据，或者所有账号都遭遇了同样的配置问题。

但反过来看，这恰恰也是问题所在——除了社交媒体上一句简短的确认，xAI几乎没有给出任何实质性的答案。

Grok Build是xAI今年伴随Grok 4.5一同推出的编程工具，本意是对标Claude Code和Cursor，试图在企业开发者市场里抢下一席之地。

对于一款刚刚起步、急需赢得企业开发者信任的产品来说，这次曝光的时机相当致命。

对普通开发者而言，这件事其实是一记警钟：云端AI编程工具打的"数据安全"广告牌，光看营销文案和一个孤立的隐私开关是不够的。

开发者应该假定但凡接入这类工具的代码仓库，就存在被超出预期范围上传的可能，尤其是那些藏在Git历史深处、早已从工作目录删除但从未真正清除的敏感信息，才是最容易被忽视、也最难被追回的部分。

推荐飞总知识星球，在私域场合里畅所欲言，聊聊职场发展的事情，和飞总提问交流，这么低 的价格不会一直保留，机会难得，一定不要错过这个的机会。