Grok Build 将完整代码仓库上传至谷歌云：事件经过与应对措施

引言

SpaceXAI 的 Grok Build 编码工具近日受到审查，原因是一名安全研究人员发现其命令行工具（CLI）将整个 Git 仓库上传至云存储，而不仅仅发送编码任务所需的文件。

据报道，上传的数据包括已跟踪的文件、完整的 Git 历史记录、该代理被指示不要读取的文件，以及已从当前工作树中删除但仍存在于早期提交中的机密信息。数据发送目的地为 xAI 控制的一个谷歌云存储桶。

在调查结果公布后，上传行为已停止。研究人员观察到 SpaceXAI 的服务器开始返回以下内容：

禁用代码库上传：true

埃隆·马斯克还表示，之前上传的用户数据将被完全删除。然而，在事件被报道时，尚无法公开独立确认所有历史副本是否已被移除。

Grok Build 发送的内容远超其使用的文件

该事件始于对 Grok Build CLI 的受控网络分析。

化名 Cereblab 的研究人员对官方二进制文件进行了逆向工程，并监控了其网络流量。在一项旨在揭示该工具实际数据流的测试中，Grok Build 将仓库打包成一个 Git 捆绑包，并上传至与 xAI 相关联的谷歌云存储桶。

这并不仅仅局限于回答提示所需的少量文件。

据报道，捕获的捆绑包包含：

• 整个已跟踪的仓库
• 完整的提交历史
• 代理未打开的文件
• 被明确告知不要读取的文件
• 已从当前版本删除但仍存在于 Git 历史记录中的机密信息
• 与当前请求无关的其他专有仓库内容

原始 AIbase 报告描述其保留范围远大于 Claude Code 等类似 AI 编码工具。

在 Axios 报道的一项测试中，Grok Build 上传了大约 5.1 GB 的数据，而编码任务本身仅需约 192 KB。这个例子说明了发送任务相关上下文与传输完整仓库存档之间的区别。

为何完整的 Git 历史记录尤其敏感

上传当前源码树已经是一起严重的安全事件。而上传完整的 Git 历史记录可能带来更大的危害。

开发者经常从仓库的最新版本中删除一个机密信息，并认为它已经消失。实际上，该值可能仍保留在较旧的提交中，除非历史记录已被重写。

Git 历史记录可能包含：

• API 密钥
• 云端访问凭证
• 数据库密码
• 私钥证书
• 内部服务 URL
• 客户标识符
• 公开披露前的安全修复补丁
• 已从

当前分支

• 基础设施图表和部署脚本
• 早期开发工作中的个人信息

因此，存储库在当前工作目录下可能看起来很干净，但敏感材料仍会保留在 .git 目录内。

这就是为什么当工具在 Git 层面单独打包存储库时，“不要打开此文件”之类的指令不足以提供充分保护。文件级权限指令可以控制在模型对话期间代理读取的内容，但无法自动阻止单独的上传流程打包存储库历史记录。

目标为 Google Cloud Storage

Cereblab 的分析确定目标是一个由 xAI 控制的 Google Cloud Storage 存储桶。

使用 Google Cloud 并不意味着 Google 独立决定收集存储库。云存储提供商为客户托管基础设施，据报道，本案中的相关数据控制方或服务运营商是 xAI 或 SpaceXAI。

关键问题在于，存储库数据离开了用户的机器，进入了第三方云基础设施。

对于企业团队来说，这可能引发涉及以下方面的问题：

• 保密协议
• 客户数据承诺
• 数据驻留
• 商业秘密保护
• 软件供应链规则
• 内部安全策略
• GDPR 或其他隐私要求
• 特定行业的合规义务

即使云提供商本身拥有强大的安全控制措施，未披露或意外的传输也可能违反公司自身的治理要求。

SpaceXAI 禁用了存储库上传

调查公开后，Cereblab 再次测试了 CLI。

服务器返回：

disable_codebase_upload: true

整个存储库的上传不再触发。

这似乎是服务器端的更改，因为用户无需在行为停止前安装新版本。一个远程配置标志禁用了存储库打包流程。

这一区别很重要。

服务器端开关可以快速停止该行为，但也表明客户端的数据处理行为可能依赖于远程配置。因此，评估编码代理的组织应验证实际的网络流量，而不仅仅依赖本地版本号或静态设置屏幕。

马斯克承诺删除之前上传的数据

埃隆·马斯克公开回应称，更改前上传的所有用户数据将被“完全彻底删除”，不留任何痕迹。

SpaceXAI 还表示，将尊重隐私选择，且受零数据保留安排约束的客户不会保留跟踪或代码数据。

这些是重要的承诺，但在报道时仍存在几个未解决的问题：

• 多少用户受到影响？
• 哪些 Grok Build 版本执行了上传？
• 该行为何时开始？
• 存储库数据保留了多久？
• 是否有任何数据被内部访问？
• 是否存在备份或副本？
• 用户如何验证删除？
• 受影响的组织是否会收到个别通知？
• SpaceXAI 是否会发布正式的事件报告？

删除可以减轻

未来风险，但这并不能自动解决所有安全问题。如果仓库中包含活跃的凭据，用户应假定这些值可能已离开本地环境，并立即轮换它们。

为什么 /privacy 命令并非真正的修复方案

SpaceXAI 最初引导用户使用 Grok Build CLI 命令：

/privacy

官方 Grok Build 文档将 /privacy 描述为用于显示或更改隐私及数据保留状态的命令。

安全研究员发现，该设置控制的是保留行为，而非完整的仓库包传输机制。换句话说，该命令只能影响 SpaceXAI 在接收数据后的保留操作，但并非阻止仓库离开本机的服务端机制。

Cereblab 的结论非常明确：

• /privacy 是会话级别的保留控制。
• 仅在启用 disable_codebase_upload 后，仓库上传才会停止。
• 保留与传输是两个独立的安全问题。

这是本次事件最重要的教训之一。

上传与保留是不同控制维度

控制问题	含义
数据是否离开设备？	传输或上传控制
接收的数据是否被存储？	保留控制
存储时长多久？	保留期限策略
是否用于模型训练？	训练用途策略
用户能否删除数据？	删除控制
用户能否验证删除？	审计与保障控制

一项服务可能承诺不保留数据，但仍会传输数据用于实时处理。这在有明确书面记录的企业协议下可能可以接受，但这与保持数据本地化并非同一概念。

用户不应将"零数据保留"等同于"零数据传输"，除非产品明确作出此类保证。

xAI 官方隐私文档说明

xAI 的 API 安全文档将零数据保留（ZDR）描述为企业级功能。

当 API 团队启用 ZDR 后，xAI 表示提示词、补全内容及相关元数据会实时处理但不会持久化存储到其服务器。文档还说明 API 响应会包含 x-zero-data-retention 标头，便于应用程序验证 ZDR 是否生效。

对于未启用 ZDR 的标准 API 使用场景，xAI 表示请求和响应可能会临时存储最多 30 天，用于滥用和误用审计。

这些 API 策略具有参考价值，但各组织不应自动假定所有 Grok 产品、CLI 追踪、文件传输通道或消费账户都遵循相同的数据生命周期。

在使用 Grok Build 处理私有仓库前，请验证：

1. 当前活动的是哪个账户或工作空间
2. 组织是否已签订合同级 ZDR 协议
3. 协议覆盖哪些数据通道
4. 代码包、会话追踪、提示词和工具输出是否被分别处理
5. 本地及远程设置当前激活了哪些功能
6. 当前二进制文件是否会执行额外上传操作
7. 删除请求如何被验证

研究人员识别的安全风险

独立安全研究员卢卡什·奥莱伊尼克博士描述了数据规模——

数据保留时间过长。

可能被泄露的信息包括：

• 专有源代码
• 安全漏洞细节
• 个人数据
• 内部基础设施信息
• 访问凭证
• 客户特定实施细节

风险不仅限于恶意使用。

大型代码归档还可能通过以下方式泄露：

• 配置错误的云存储
• 员工过度访问权限
• 被入侵的服务账户
• 备份保留
• 日志管道
• 法律请求
• 跨境传输
• 影响供应商的安全事件

数据最小化原则旨在减小攻击面。当只需要少量文件时，默认上传整个仓库很难与这一原则保持一致。

开发者现在应该做什么

在上传功能被禁用前使用过 Grok Build 的团队，应像应对任何潜在的源代码泄露事件一样采取行动。

1. 识别受影响的仓库

检查 Grok Build 运行的位置。

记录：

• 仓库名称
• 日期和时间
• Grok Build 版本
• 使用的账户或 API 密钥
• 存在的分支
• 仓库是否为私有
• 是否存在敏感历史记录

不要将检查范围限制在代理似乎打开过的文件。

2. 审计 Git 历史记录中的秘密信息

使用组织批准的密钥扫描工具检查完整历史记录，而不仅仅是当前分支内容。

查找：

• 云密钥
• API 令牌
• 数据库凭据
• SSH 密钥
• 签名密钥
• 私有证书
• 嵌入凭证的内部 URL
• 客户凭证
• 临时开发秘密

即使某个秘密已从最新提交中删除，仍可能需要轮换。

3. 轮换可能泄露的凭证

如果在受影响期间，受跟踪的仓库历史记录中的任何位置存在凭证，请撤销或轮换它。

不要等待有人访问了上传副本的证据。凭证轮换通常比事后调查入侵事件成本更低。

优先处理提供以下权限的凭证：

• 生产环境访问
• 管理权限
• 客户数据访问
• 云控制平面访问
• 包发布权限
• CI/CD 权限

4. 检查日志中的可疑使用情况

在仓库与 Grok Build 一起使用后，检查云、源代码管理、CI/CD、数据库和内部服务日志中是否有异常活动。

查找：

• 新的登录位置
• 意外的令牌使用
• 无法识别的 API 调用
• 权限变更
• 新的服务账户
• 仓库克隆
• 包发布
• 基础架构变更

没有可疑活动并不能证明数据从未泄露，但有助于评估眼前的风险。

5. 更新 Grok Build 并检查配置

使用当前版本的 Grok Build 并检查活动配置。

官方文档提供：

grok inspect

此命令有助于确认正在加载哪些配置源。

CLI 还提供：

/privacy

用它来检查保留状态，但请注意，不应将该命令视为证据。

没有任何数据离开设备。

6. 联系SpaceXAI获取账户特定确认

企业用户应要求获得涵盖以下内容的书面答复：

• 用户的账户是否受到影响
• 哪些仓库或对象被存储
• 上传时间戳
• 保留期限
• 删除状态
• 备份处理情况
• 数据是否被访问
• 是否会发布正式事件通知

公开的删除承诺虽有帮助，但受监管的组织可能需要账户特定的证据。

7. 审查法律和客户义务

如果仓库中包含客户代码、个人数据、受监管信息或保密协议涵盖的内容，应让相应的内部团队参与。

根据具体情况，相关团队可能包括：

• 安全团队
• 法律团队
• 隐私团队
• 合规团队
• 客户成功领导层
• 网络保险团队
• 事件响应团队

不要仅根据新闻报道做出违规通知决定。应根据组织自身的暴露事实和适用法律来判断。

团队如何安全评估AI编码工具

这起事件凸显了AI开发工具领域的一个更广泛问题。

编码代理通常要求广泛的访问权限，因为它们需要搜索大型仓库、运行命令、读取文档和修改文件。这种能力形成了巨大的隐私边界。

在批准使用编码助手之前，团队应评估五个方面。

1. 数据发现

记录工具可能收集的每一类数据：

• 提示文本
• 源文件
• Git历史记录
• 终端输出
• 环境变量
• 工具结果
• 会话轨迹
• 上传的文件
• 诊断信息
• 遥测数据

2. 网络检查

测试实际离开机器的内容。

供应商文档是必要的，但网络行为是实际传输的最有力证据。

使用包含无害金丝雀值的隔离测试仓库，然后检查：

• 联系的域名
• 上传大小
• 请求时机
• 存储端点
• 是否包含忽略的文件
• 是否捆绑历史记录
• 隐私设置下的行为

3. 最小权限访问

不要从不相关项目的目录中运行该工具。

优先选择：

• 临时工作树
• 狭窄的仓库访问权限
• 沙盒环境
• 短期凭证
• 评估时使用只读模式
• 在可行的范围内设置网络限制

4. 合同控制

对于企业部署，确认以下内容：

• 数据处理条款
• 培训使用政策
• 保留期限
• ZDR资格
• 子处理者
• 数据位置
• 违规通知承诺
• 删除验证
• 审计权利

5. 持续重新验证

工具的行为可能因自动更新或远程配置更改而变化。

在以下情况后重新测试：

• CLI更新后
• 主要产品发布后
• 新的隐私设置后
• 企业条款变更后
• 网络端点变更后
• 供应商事件后
• 新的数据连接器后

当产品快速变化时，安全批准不应是永久性的。

AI编码代理的更广泛教训

“不读取”不等于“不上传”

代理指令在模型或工具使用层运行。单独的遥测或同步组件可能不会解释这些指令。

隐私控制需要存在于数据管道本身。

数据最小化必须可验证

供应商可以声称只发送必要的上下文，但企业用户需要证据。

有用的保证包括：

• 已发布的数据流图
• 可配置的本地控制
• 网络允许列表
• 审计日志
• 明确的存储目的地
• 独立安全测试
• 合同限制

服务器端修复需要透明度

远程配置能快速停止上传，但也意味着用户可能不知道重要的行为何时发生变化。

成熟应对应包括：

• 安全公告
• 受影响版本
• 起止日期
• 技术根本原因
• 涉及的数据类别
• 修复详情
• 删除状态
• 客户指导

删除存储的数据并不轮换密钥

即使SpaceXAI删除了所有存储副本，上传仓库中包含的任何凭证都应根据其暴露风险进行处理。

删除保护了未来对供应商副本的访问，但并不改变凭证本身。

常见问题

Grok Build上传了什么内容？

Cereblab的协议级分析发现，CLI将整个已跟踪的Git仓库作为捆绑包上传，包括提交历史以及与当前编码任务无关的文件。该历史记录可能包含已从当前工作目录中移除的密钥。

仓库上传到了哪里？

捕获的流量显示，上传到了由xAI控制的Google Cloud Storage存储桶。Google Cloud是基础设施提供商；相关产品和数据处理决策归属于SpaceXAI。

SpaceXAI是否已停止上传？

研究人员后来观察到服务器返回了disable_codebase_upload: true，此后整个仓库上传不再触发。该变化似乎是服务器端做出的。

/privacy命令能阻止仓库上传吗？

该命令控制隐私和保留设置，但Cereblab报告称，它并非停止完整仓库上传的机制。用户应区分防止传输与限制传输后的保留。

埃隆·马斯克是否承诺删除上传的数据？

是的。马斯克公开表示所有先前上传的用户数据都将被完全删除。在报道时，尚未公开对完全删除的独立验证。

开发者是否应轮换密钥？

如果在使用Grok Build时密钥存在于已跟踪的仓库或其Git历史中，轮换是审慎的应对措施。删除供应商存储的副本并不保证凭证从未被暴露或访问。

什么是零数据保留？

xAI将ZDR描述为企业API功能，处理输入和输出而不持久化它们。这并不一定意味着数据从不离开本地设备，组织应核实哪些Grok Build数据通道被覆盖。

Grok Build现在使用安全吗？

已报告的整个仓库上传功能已被禁用，但每个组织必须评估当前版本、设置、账户条款、网络行为和仓库敏感性。服务器端修复并不

不取代内部安全审查。

相关工具

• Grok Build：SpaceXAI 的编码代理，支持交互式终端、无头模式和 ACP 工作流。
• Grok Build CLI 参考：Grok Build 的官方命令行参考文档。
• Grok Build 设置：本地、项目、托管和企业配置的官方文档。
• Grok Build 企业部署：企业安全控制、配置和数据生命周期的官方指南。
• Gitleaks：用于检测 Git 仓库及提交历史中敏感信息的开源工具。
• TruffleHog：一种秘密扫描工具，可检查仓库、云存储及其他数据源中暴露的凭证。

相关链接

• Cereblab 线路级分析：关于 Grok Build 仓库及跟踪上传行为的主要技术调查。
• Cereblab 事件摘要：研究人员对服务器端上传禁用确认的总结与更新。
• xAI API 安全常见问题：关于 API 数据保留、零数据保留和验证标头的官方信息。
• Grok Build 模式与命令：CLI 命令的官方文档，包括 /privacy。
• Grok Build 企业文档：面向组织的官方部署与安全信息。
• The Verge 报道：关于上传行为、关停及删除承诺的独立报道。
• The Register 技术报告：关于调查及 SpaceXAI 回应的补充报道。

总结

Grok Build 被发现会将其跟踪的整个 Git 仓库及完整历史上传至 xAI 控制的 Google Cloud Storage 存储桶，即使任务仅需少量代码。

SpaceXAI 通过服务器端 disable_codebase_upload 标志禁用了仓库上传功能，埃隆·马斯克承诺此前上传的数据将被删除。/privacy 命令虽涉及保留设置，但并非阻止仓库传输的控制手段。

使用受影响 CLI 的开发者应识别相关仓库，扫描完整 Git 历史，轮换可能暴露的凭证，审查日志，并在必要时请求账户专属的删除信息。

核心教训很简单：人工智能编码工具的隐私必须在数据传输层面进行验证，而不能仅凭提示词、保留标签或设置界面推断。