摘要xAI 的 AI 编程助手 Grok Build 因被研究员用抓包工具抓到「静默上传用户完整 Git 仓库到 GCS 云桶」而引发轩然大波。事件爆发 72 小时后xAI 以 Apache 2.0 将 84 万行 Rust 代码全量开源。但开源能洗白一次数据泄露吗我认认真真把这件事从头读了一遍说说我的看法。事情的起点一个研究员的抓包报告2026 年 7 月 10 日一位署名cereblab的 AI 安全研究员在 GitHub Gist 上发布了一份报告标题很直接*What xAI Grok Build CLI actually sends to xAI — a wire-level analysis*。他用的工具很朴素mitmproxy一个中间人代理把 Grok Build CLI 的所有 HTTPS 流量明文截下来。结果让他自己都吓了一跳。Grok Build 在运行时对外发起了两条上传通道通道 A预期行为POST /v1/responsesAI 读了哪些文件就把文件内容附在模型上下文里发出去。这是所有云端 AI 编程助手的标准做法没什么问题。通道 B问题所在POST /v1/storage这条通道把整个 Git 仓库打成一个 git bundle完整上传——不管 AI 有没有读过那些文件不管你有没有打开任何功能一律上传到 xAI 控制的 Google Cloud Storage 桶桶名叫grok-code-session-traces。cereblab 做了一个非常干净的实验来证明这一点Prompt:reply OK, do not read any files就这一句提示词什么都不让 AI 干。结果呢POST /v1/storage → HTTP 200整个仓库的 git bundle 还是安安静静地传了出去。他把抓到的包git clone下来找到了一个他明确叫 AI 不要打开的金丝雀文件src/_probe/never_read_canary.txt——内容原封不动全部在里面。更吓人的数字是这个通道上传量通道 A模型上下文192 KB通道 B完整仓库5.10 GiB比值约 27,800 倍在一个 12 GB 的仓库里面全是 AI 从没被要求读的文件上通道 B 传了 5.1 GiB 出去73 个 ~75 MB 的分块全部 HTTP 200。.env文件也没能幸免cereblab 在测试仓库里放了一个.env文件里面有API_KEY和DB_PASSWORD的假金丝雀值。结果这个文件的内容原文无删减地出现在了两个地方通道 A 的模型请求体里AI 读文件时带上去的通道 B 的session_state存档里整仓库打包上传时带走的更令人沮丧的是把「优化模型」的开关关掉没用。关掉之后服务器返回的/v1/settings响应里trace_upload_enabled的值仍然是true。整仓库照样上传没有任何变化。有人在 Home 目录里运行了它这个事情被独立核实之后社区里开始有人分享自己的遭遇。其中有一位用户——他把 Grok Build 在自己的用户主目录~里运行了。他的主目录里有什么SSH 私钥密码管理器数据库文档、照片、视频……全都在 Git 追踪范围内全都被打包上传。这不是极端场景。很多开发者习惯在 Home 下建一个大 repo 来管理 dotfiles或者直接把工作目录放在 Home 里。Grok Build 的设计就是在项目目录下运行但它没有告诉你「整个目录会被上传」。xAI 的应对先打补丁再开源事情闹大之后xAI 的反应速度还算快。7 月 13 日马斯克在 X 上发帖As a precautionary measure, all user data that was uploaded to SpaceXAI before now will be completely and utterly deleted. Zero anything whatsoever will remain.作为预防措施所有此前上传到 SpaceXAI 的用户数据将被彻底、完全删除零残留。同时 xAI 推了一个服务端变更把disable_codebase_upload全局设为true。cereblab 重新抓包验证通道 B 的上传消失了。但这里有一个很微妙的地方xAI 同时在 CLI 里加了一个/privacy命令宣称用户可以用它来控制数据保留。问题是cereblab 的验证发现——/privacy是一个数据「保留」开关不是数据「发送」开关。真正让上传停下来的是服务端那个全局 flag跟/privacy没关系。7 月 15 日事件爆发约 72 小时后xAI 宣布将 Grok Build 以 Apache 2.0 协议开源仓库地址github.com/xai-org/grok-build。Publishing the code is the most direct way to build toward a robust and reliable harness. You can read the source to see exactly how it works, from context assembly to tool-call dispatch.Grok Build 是什么简单说一下既然开源了也值得认真介绍一下这个工具本身。Grok Build命令行工具名叫grok是 xAI 的终端 AI 编程助手定位对标 Claude Code 和 Cursor。它的主要特点是全屏 TUI用 Rust 写的颜值在同类工具里算高的支持鼠标交互理解代码库上下文能编辑文件、执行 Shell 命令、搜索 Web支持长任务管理三种运行模式交互式 TUI / 无头模式脚本/CI/ 编辑器嵌入ACP 协议支持 MCP 服务器、Skills、Plugins、Hooks、子 Agent技术栈上整个仓库有844,530 行 Rust 代码不含注释和空行其中只有大约 3% 是 vendored 的第三方代码自研比例极高。仓库结构路径内容crates/codegen/xai-grok-pagerTUI 核心滚动区、提示框、模态窗、渲染crates/codegen/xai-grok-shellAgent 运行时 入口点crates/codegen/xai-grok-tools工具实现终端、文件编辑、搜索…crates/codegen/xai-grok-workspace文件系统、VCS、执行环境、检查点从技术角度这是一个做工相当扎实的 TUI 框架。HN 上的骑墙派评论很典型Really good TUI harness, its a shame with the other news.TUI 框架真不错可惜出了那档子事。从源码安装的话# 安装前置依赖cargo install dotslash# 构建并启动 TUIcargo run -p xai-grok-pager-bin# 构建 release 版本cargo build -p xai-grok-pager-bin --release开源能证明什么不能证明什么这是整件事里我最想深挖的部分。能证明的代码可读你现在可以读crates/codegen/xai-grok-shell/src/upload/gcs.rs看看那个传说中的 GCS 上传例程长什么样。upload/trace.rs里的upload_session_state()函数现在返回一个硬编码错误session_state_upload_unavailable——上传出口被堵死了。本地优先成为可能你现在可以把 Grok Build 编译成本地二进制指向自己的本地推理服务所有流量都不出本机。这是一个之前不可能做到的事。安全研究有了基础HackerOne 上的漏洞奖励计划也同步启动20,000正式把安全报告渠道标准化了。不能证明的历史可审计性为零整个仓库是一个 squashed 提交从 xAI 内部 monorepo 周期性同步过来的镜像。没有 commit 历史没办法看那个上传功能是什么时候加进去的、经过了哪些人的 review、曾经有没有更宽松的版本。Kill switch 在服务端不在代码里让上传停下来的那个全局 flagdisable_codebase_upload是部署在 xAI 服务器上的不是你git pull能看到的东西。开源告诉你代码能做什么但不告诉你服务端现在开着哪些开关。Simon Willison 的评论说得很准*A public repo cannot audit a server-side switch.*删除未经独立验证马斯克说完全删除到目前为止没有任何第三方能验证这件事。外部贡献不接受README 里明确写了External contributions are not accepted.这不是真正意义上的社区开源是 publish-only。你能读能 fork但没有任何 PR 路径不会有外部维护者成为实质贡献者。Digital Applied 的总结我觉得很到位A squashed mirror with contributions disabled is not a development history. Upload stubs that return hard-coded failures are not deletions. And no GitHub page can show the state of the server-side flag that is what actually turned the uploads off.社区的反应两极分化但理性HN 上这个帖子拿了 90 票、100 评论基调是理性的怀疑。一方的声音Ill probably never use this, but at least theyre not delusional enough to attempt to justify keeping their coding agent closed-source, especially after their recent>另一方xai is now in pure damage control mode, after they caught exfiltrating data from users.还有人把这件事放进更大的竞争格局里看If you have an LLM with less than 1% of the share to begin with, you suffer from bad rep and you got caught uploading user data, one of the very few remaining tactical moves to try to climb out of it is this.欧洲那边更直接已经有四分之一的欧洲企业直接封禁了所有 Grok 相关产品原因不止这一次——Grok 之前就有用 X 用户数据未经同意训练模型的问题被欧盟监管机构认定为very likely违反了 GDPR。如果你现在想用 Grok Build该怎么保护自己先说底线如果你的仓库里有任何不能外泄的内容公司私有代码、.env、SSH 密钥、任何 secrets我不建议你现在用官方二进制版本。如果非要用或者只是想研究这个工具以下是目前社区摸索出来的防护层最强防护从源码编译 本地推理# 构建本地二进制cargo build -p xai-grok-pager-bin --release# config.toml 里指向本地推理端点# 这样流量完全不出本机次强config.toml 硬关上传在~/.grok/config.toml里加[harness] disable_codebase_upload true [features] telemetry false [telemetry] trace_upload false社区验证[harness] disable_codebase_upload true是整个上传管线末端的硬 veto即使其他配置强制开启上传也能挡住。再加一层环境变量包裹exportGROK_TELEMETRY_TRACE_UPLOADfalseexportGROK_TELEMETRY_ENABLEDfalse优先级顺序环境变量 config.toml 服务端远程配置gitignore 是最后防线git bundle 只打包被 Git 追踪的文件。对于绝对不能出门的文件确保它在.gitignore里。这是唯一在任何上传机制下都能保护该文件不被带走的方式。我的看法我对这件事的结论是这样的xAI 做了一件技术上错误的事——不管是有意设计还是疏于审查把「上传整个仓库」设计成默认行为、并且没有在任何安装文档里说清楚这是对用户信任的严重透支。关掉训练数据采集的开关却不关传输本身更像是在玩文字游戏。开源本身是好事但这次开源的背景让人很难纯粹地鼓掌。72 小时的极速开源——在一场可复现的、经过多方独立验证的数据泄露曝光之后——更像是一次教科书级的危机公关操作而不是 xAI 从一开始就有的开放承诺。开源只是让代码可见了但那个能随时重新打开上传通道的服务端开关依然在 xAI 手里。最耐人寻味的细节开源代码里那些上传例程——gcs.rs、trace.rs——一行都没删只是upload_session_state()函数改成了返回一个硬编码的错误。代码还在那机器随时可以重启。Grok 4.5 模型本身的能力可能是好的。HN 上有开发者说它比某些竞品更强。如果你真的想用这个模型更安全的方式是通过 API 直接调用或者接到你自己信任的 agent 框架里——而不是使用官方 CLI。开源降低了门槛却没有重建信任。信任不是靠一次开源建立的是靠日复一日的行为建立的。谢谢你阅读我的文章~我是顾北我们下期再见PS本文部分内容由AI辅助创作