Elon Musk 承认 Grok Build 上传了用户代码，SpaceXAI 承诺彻底删除数据
Elon Musk 已承认，即使用户关闭了“帮助改进模型”选项，Grok Build 仍会将完整的代码仓库上传至由公司控制的云存储空间。
这一发现来自 Cereblab，一名使用化名、未声明与任何供应商有关联的独立 AI 安全研究人员。在一项可复现的网络传输层演示中，该研究人员在 macOS 上测试了 Grok Build CLI v0.2.93，并通过安装了本地可信证书的 mitmproxy 转发其 HTTPS 流量。一个 12GB 的测试仓库通过 73 个数据分块产生了 5.1GiB 的存储流量，而模型对话仅使用了约 192KB。
随后，Musk 承诺将删除此前上传的用户数据。SpaceXAI 还建议用户使用 /privacy 控件管理数据留存；该公司的官方命令文档称，该命令可显示或切换隐私和数据留存状态。
这一事件凸显了一个控制范围上的缺口：管理模型训练的控件与代码是否会离开用户设备是两个不同的问题。因此，那些认为关闭该选项就能阻止上传的开发者，可能误解了它的适用范围。
该事件给 SpaceXAI 带来了压力，要求其证明服务器端的更改确实阻止了仓库传输，并且已删除留存的材料。它还引发了一个更广泛的问题：开发者应如何评估那些需要远程访问部分代码才能回答提示词的云端编程代理。
Grok Build 是 SpaceXAI 推出的终端 AI 编程代理。尽管一些报道将其称为“xAI 工具”，但目前的官方产品资料将 Grok Build 标识为 SpaceXAI 的产品，并托管于 x.ai 域名下。因此，本文使用“SpaceXAI”作为公司名称，Grok Build 是产品，而 Grok 则是其所属的底层产品系列。
Cereblab 最具说服力的测试使用了提示词“回复 OK，不要打开任何文件”。尽管如此，Grok Build 仍通过 POST /v1/storage 发送了一个 Git 包；克隆捕获的有效载荷后，恢复出了 47 个文件、四次提交、完整历史记录，以及一个代理已被明确要求不得读取的金丝雀文件。据报道，传输目的地是一个名为 grok-code-session-traces 的 Google Cloud Storage 存储桶。
该传输使用 HTTPS 在传输过程中进行了加密，但研究人员在安装本地可信证书后仍能检查其内容。公开证据无法确定该存储桶的静态数据加密配置、访问历史、地理位置或留存期限。
另一位用户名为 @a_green_being 的用户报告称，在四个仓库中发现了 339 条 repo_state.upload.enqueued 日志事件，其中一个事件记录的仓库路径是该用户的主目录。这一说法支持了可能存在更广泛数据收集的推测，但它只是用户报告，而非经过独立审计的取证结果。
在这些披露之后，Musk 作出了回应。Axios 报道称，他承诺彻底删除公告发布前上传的数据。SpaceXAI 表示，零数据留存客户的跟踪记录或代码数据均未被留存，之后还禁用了默认留存。目前尚无独立审计证实数据已被删除。
核心矛盾在于，用户从可见的训练选项中作出的合理推断，与测试显示的实际情况并不一致。Cereblab 发现，最初关闭模型改进选项并不能阻止仓库打包或传输：服务器仍报告 trace_upload_enabled: true。
这一区别非常重要。公司可以不将代码用于训练，却仍然为了调试、跟踪记录存储或其他运营目的而传输或留存代码。SpaceXAI 表示，数据留存有助于调试，并称其遵守了零数据留存协议，但该公司尚未发布完整的事件报告，以解释为何默认收集完整仓库和 Git 历史记录。
这些证据也存在局限性。Cereblab 仅在两个受控仓库上测试了早期的 CLI 版本 v0.2.93，并未覆盖所有操作系统、账户等级、配置或版本。这些测试证明了特定条件下的行为，但无法确定有多少客户受到影响，也无法确认 SpaceXAI 员工或第三方是否访问过存储的代码。
在 SpaceXAI 将服务器设置更改为 disable_codebase_upload: true 和 trace_upload_enabled: false 后，Cereblab 随后使用同一二进制文件重复进行了六次测试，均未观察到存储上传。这表明服务器端的缓解措施已经生效，但无法证明此前留存的数据已被删除。
在运行过受影响版本 Grok Build 的设备上拥有专有代码的开发者，是受影响最直接的群体。实际上，仓库包中可能包含的不只是当前检出版本里可见的文件：Git 历史记录可能保留已删除的凭据、内部端点、客户标识符或尚未发布的源代码。
用户可以检查 ~/.grok/logs/unified.jsonl 中的 repo_state.upload 事件，并确认 Grok 将哪一路径视为仓库根目录。任何发现机密信息可能已离开设备的人都应轮换相关凭据；即使从云存储中删除数据，也无法撤销此前可能发生的访问。
要复现原研究人员的这一小范围测试，调查人员需要 Grok Build v0.2.93、一个包含唯一金丝雀标记的临时 Git 仓库，以及一个仅安装在隔离测试环境中的 HTTPS 检查代理。测试提示词应要求代理不要读取文件，之后调查人员可以比较模型流量与 /v1/storage 请求，并尝试克隆任何捕获到的 Git 包。绝不能在生产仓库上执行此测试。
SpaceXAI 尚未披露受影响账户的总数、上传功能的完整运行时间段、存储桶访问日志或第三方删除验证。其企业条款通常允许在数据删除义务方面存在某些例外，而该公司表示，签有零数据留存协议的 Grok Build 用户不受数据留存影响。
/privacy 命令提供了一个更清晰的控制点，但它管理的是数据留存，并不能证明代码不会为了推理或其他处理目的而传输。用户应同时验证网络行为和账户级留存状态，而不应将该命令视为离线模式。
Cereblab 报告称，对 Claude Code、OpenAI Codex 和 Gemini 进行的同类空闲提示词测试没有产生完整的仓库包；这些工具只传输了它们打开的文件。这是一项有参考价值的受控比较，但并非全面的安全性排名，而且结果可能会随版本和配置而变化。
此后，SpaceXAI 已将 Grok Build 框架开源，使独立审查人员能够更清楚地了解仓库打包和上传路径。源代码审查可以提升问责能力，但服务器端配置和数据删除仍超出了客户端代码可验证的范围。
未来三个月，用户应关注三个信号。第一，详细的公司事件报告或独立审计，确认删除了哪些内容、何时完成删除，以及存储的仓库是否曾被访问。第二，明确区分模型训练许可、运营传输、调试留存和零数据留存行为的文档。第三，独立研究人员能否在当前版本上复现最初的 /v1/storage 传输。
如果这些信号均未出现，历史数据留存和删除情况仍将存在不确定性。如果 SpaceXAI 发布可验证的日志、精确定义数据留存政策，并且当前版本能够经受重复测试，那么它就可以开始缩小其声明政策与实际观察行为之间的差距。
对于正在评估 AI 编程代理的团队而言，实际教训并不是要彻底拒绝云端工具，而是应采取更有针对性的措施：在临时仓库中运行新的代理，将机密信息存放在其可访问工作目录之外，监控出站流量，并在授予私有代码访问权限前确认数据留存条款。
