Grok Build 把你的整个代码库都上传了，连 .env 密钥都没放过

后台存储路径则是更令人担忧的发现。该 CLI 工具独立于 AI 代理实际打开了哪些文件，会将 整个 Git 仓库——包括完整的提交历史——打包成一个 Git bundle，并通过 POST /v1/save-session 接口上传至一个名为 grok-code-session-trace 的 Google Cloud Storage 存储桶 ^1NA。即使研究员指示该工具“只需回复'OK'，不要读取任何文件”，它仍然会上传完整的仓库包 ^N。

安全研究员 Hari 通过逆向工程独立证实了这一点，他表示 Grok Build 在未经明确许可的情况下上传了用户的整个目录 ^T。在一次使用一个 11.2 GiB 仓库的测试中，至少有 5.1 GiB 的数据通过存储路径被截获并传出，而实际的编程任务只需要大约 192 KB ^NXY。上传的内容包含了完整的 Git 历史记录、.env 中的密钥以及仓库中的所有文件，而不仅仅是编程任务所需的那一小部分 ^ENA。

马斯克和 xAI 如何回应

伊隆·马斯克 公开确认了问题，在 X（原 Twitter）上以“True”开头回应 ^TK。他随后承诺：“作为预防措施，所有之前上传到 SpaceXAI 的用户数据将被完全、彻底地删除。一个字节都不会留下。” ^TKI

xAI 发布公开声明，称非常重视用户隐私，并指出使用 零数据保留 (ZDR) 功能的企业客户，其代码或训练数据从未被使用过 ^T。该公司还实施了一项 服务器端变更，禁用了 /v1/save-session 接口，从而停止了后台的仓库上传行为 ^OK。截至 2026 年 7 月 13 日，上传行为已经停止 ^OK。

修复后仍存的隐忧

尽管 xAI 的回应阻止了主动的数据外泄，但仍有几个问题悬而未决。

1. 修复是服务器端的，而非客户端。 研究员指出，Grok Build CLI 客户端（版本 0.2.93）本身从未更新——xAI 仅仅是在其服务器上关闭了接收数据的接口 ^OK。这意味着客户端代码中仍保留着上传整个仓库的能力；如果该接口被重新启用，此行为可能会再次发生。

2. xAI 的隐私选择退出未能阻止上传。 研究员测试了所谓的“隐私模式”或数据保留退出命令，发现它 并没有阻止 后台的全量仓库上传 ^O1A。研究员明确指出：“xAI 的隐私命令并不是解决问题的关键” ^O。相反，是一个名为 disable_codebase_upload 的隐藏服务器端标志被设置为 true ^TX。

3. 未就变更进行公开沟通。 xAI 在未通知用户、也未发布更新日志的情况下就禁用了上传功能 ^QN。

4. 数据删除未得到确认。 尽管马斯克承诺删除，但截至相关报道发布，尚无独立方核实之前存储在 grok-code-session-trace 存储桶中的用户数据是否确实已被清除 ^OT。

5. 已经泄露的数据无法撤回。 任何在修复前已传输的敏感凭证、专有代码或机密信息，都已存储在 xAI 的云基础设施上 ^1N。研究员截获了上传数据，能够克隆 Git 包，并恢复了 AI 代理被明确告知不要读取的文件 ^ET。

关键事实摘要

这对开发者意味着什么

Grok Build 事件凸显了开发者在使用 AI 编程助手时面临的一种日益增长的风险。许多此类工具会向云端服务器发送代码进行处理，但传输和存储的范围往往不透明。在此案例中，该工具发送的数据远超必要范围——并且即使用户尝试明确阻止，它依然照传不误。

在 xAI 发布客户端更新并提供数据删除的独立核实之前，使用过 Grok Build 的开发者应假设其仓库中存在的任何凭证、专有代码或敏感信息可能已经被传输至 xAI 的云基础设施中。