Grok Build 被曝整库上传：你的 SSH 密钥，正被悄悄传上云

马斯克这边刚把 Grok Build 开源，那边就被人扒出了一桩隐私丑闻。安全研究者 cereblab 用网络抓包工具复现了 Grok Build 0.2.93 版的行为，结果让人后背发凉：哪怕你只让 AI 回复一句「OK」，它也会把整个代码仓库——连同 Git 历史里早就删掉的密钥——一股脑传上 xAI 的 Google Cloud Storage。

数字更刺眼。模型交互本身只用了约 192 KB 的任务内容，存储通道却一口气上传了 5.10 GB 数据，按 75 MB 一块切了 73 份，比例高达实际需求的 27800 倍。上传的是 Git 打包文件，里面装着仓库的完整提交历史，不只是当前文件。

最吓人的案例来自其他用户：有人整个用户目录都被打开上传，里面躺着 SSH 密钥和密码管理器数据库。研究还发现，即便你关掉了「改进模型」的开关，上传行为也不会停——那个开关管的是数据「保留」，不是数据「发送」。xAI 后来推给用户的 /privacy 命令，也只是按会话清理 retention，并不是真正拦住上传的那个开关。

真正拦住上传的，是服务端一个静默的全局标志 disable_codebase_upload: true，用户 opt-in 还是 opt-out 都拦不住它重新打开。xAI 在事件曝光后改了服务端配置，六次复测都没再出现存储请求，但开源出来的代码里，那段上传逻辑依然原封不动地留着。

这事给所有用云端编程 Agent 的人提了个醒：Claude Code 和 Codex 都只上传真正打开的文件，整仓收集是 Grok Build 独有的行为。但更根本的是，凡是跑在云端的工具，都会上传它实际接触到的文件。如果你曾经把密钥 commit 进仓库、后来又删了，别以为就安全了——Git 历史里还在。

把视线拉远一点，Agent 越能干，它「能碰到的东西」就越多。默认就该是「不传」，而不是「传了再说、被抓才改」。对开发者来说，现在最实在的动作是：轮换每一个曾经进过仓库的凭证，不管它今天还在不在工作区里。