后台存储路径则是更令人担忧的发现。该 CLI 工具独立于 AI 代理实际打开了哪些文件,会将 整个 Git 仓库——包括完整的提交历史——打包成一个 Git bundle,并通过 POST /v1/save-sessiongrok-code-session-trace 的 Google Cloud Storage 存储桶 。即使研究员指示该工具“只需回复'OK',不要读取任何文件”,它仍然会上传完整的仓库包
。
安全研究员 Hari 通过逆向工程独立证实了这一点,他表示 Grok Build 在未经明确许可的情况下上传了用户的整个目录 。在一次使用一个 11.2 GiB 仓库的测试中,至少有 5.1 GiB 的数据通过存储路径被截获并传出,而实际的编程任务只需要大约 192 KB
。上传的内容包含了完整的 Git 历史记录、
.env 中的密钥以及仓库中的所有文件,而不仅仅是编程任务所需的那一小部分 。
伊隆·马斯克 公开确认了问题,在 X(原 Twitter)上以“True”开头回应 。他随后承诺:“作为预防措施,所有之前上传到 SpaceXAI 的用户数据将被完全、彻底地删除。一个字节都不会留下。”
xAI 发布公开声明,称非常重视用户隐私,并指出使用 零数据保留 (ZDR) 功能的企业客户,其代码或训练数据从未被使用过 。该公司还实施了一项 服务器端变更,禁用了
/v1/save-session 接口,从而停止了后台的仓库上传行为 。截至 2026 年 7 月 13 日,上传行为已经停止
。
尽管 xAI 的回应阻止了主动的数据外泄,但仍有几个问题悬而未决。
1. 修复是服务器端的,而非客户端。 研究员指出,Grok Build CLI 客户端(版本 0.2.93)本身从未更新——xAI 仅仅是在其服务器上关闭了接收数据的接口 。这意味着客户端代码中仍保留着上传整个仓库的能力;如果该接口被重新启用,此行为可能会再次发生。
2. xAI 的隐私选择退出未能阻止上传。 研究员测试了所谓的“隐私模式”或数据保留退出命令,发现它 并没有阻止 后台的全量仓库上传 。研究员明确指出:“xAI 的隐私命令并不是解决问题的关键”
。相反,是一个名为
disable_codebase_upload 的隐藏服务器端标志被设置为 true 。
5. 已经泄露的数据无法撤回。 任何在修复前已传输的敏感凭证、专有代码或机密信息,都已存储在 xAI 的云基础设施上 。研究员截获了上传数据,能够克隆 Git 包,并恢复了 AI 代理被明确告知不要读取的文件
。
| 方面 | 详细信息 |
|---|---|
| 受影响工具 | Grok Build CLI 版本 0.2.93 |
| 发现日期 | 2026 年 7 月 12 日 |
| 上传内容 | 整个 Git 仓库、完整提交历史、未脱敏的 .env 密钥 |
| 存储目标 | Google Cloud Storage 存储桶 (grok-code-session-trace) |
| 研究员 | cereblab(独立研究员);Hari 独立证实 |
| 马斯克回应 | 公开确认;承诺删除所有之前上传的数据 |
| 修复措施 | 服务器端禁用 /v1/save-session 接口;设置隐藏的 disable_codebase_upload 标志 |
| 客户端是否更新? | 否 |
| 隐私退出是否有效? | 无效——即使用户选择退出,上传仍会继续 |
| 数据删除是否已核实? | 截至报道发布,尚无独立核实 |
Grok Build 事件凸显了开发者在使用 AI 编程助手时面临的一种日益增长的风险。许多此类工具会向云端服务器发送代码进行处理,但传输和存储的范围往往不透明。在此案例中,该工具发送的数据远超必要范围——并且即使用户尝试明确阻止,它依然照传不误。
在 xAI 发布客户端更新并提供数据删除的独立核实之前,使用过 Grok Build 的开发者应假设其仓库中存在的任何凭证、专有代码或敏感信息可能已经被传输至 xAI 的云基础设施中。