SpaceXAI 的 Grok Build 编码工具因安全研究员发现其 CLI 将整个 Git 仓库上传至云存储而非仅发送编码任务所需文件而受到审查。据报告,上传的数据包括被追踪的文件、完整的 Git 历史、工具被指示不可读取的文件,以及已从当前工作树删除但仍存于早期提交中的机密...

SpaceXAI 的 Grok Build 编码工具近日受到审查,原因是一名安全研究人员发现其命令行工具(CLI)将整个 Git 仓库上传至云存储,而不仅仅发送编码任务所需的文件。
据报道,上传的数据包括已跟踪的文件、完整的 Git 历史记录、该代理被指示不要读取的文件,以及已从当前工作树中删除但仍存在于早期提交中的机密信息。数据发送目的地为 xAI 控制的一个谷歌云存储桶。
在调查结果公布后,上传行为已停止。研究人员观察到 SpaceXAI 的服务器开始返回以下内容:
禁用代码库上传:true
埃隆·马斯克还表示,之前上传的用户数据将被完全删除。然而,在事件被报道时,尚无法公开独立确认所有历史副本是否已被移除。

该事件始于对 Grok Build CLI 的受控网络分析。
化名 Cereblab 的研究人员对官方二进制文件进行了逆向工程,并监控了其网络流量。在一项旨在揭示该工具实际数据流的测试中,Grok Build 将仓库打包成一个 Git 捆绑包,并上传至与 xAI 相关联的谷歌云存储桶。
这并不仅仅局限于回答提示所需的少量文件。
据报道,捕获的捆绑包包含:
原始 AIbase 报告描述其保留范围远大于 Claude Code 等类似 AI 编码工具。
在 Axios 报道的一项测试中,Grok Build 上传了大约 5.1 GB 的数据,而编码任务本身仅需约 192 KB。这个例子说明了发送任务相关上下文与传输完整仓库存档之间的区别。
上传当前源码树已经是一起严重的安全事件。而上传完整的 Git 历史记录可能带来更大的危害。
开发者经常从仓库的最新版本中删除一个机密信息,并认为它已经消失。实际上,该值可能仍保留在较旧的提交中,除非历史记录已被重写。
Git 历史记录可能包含:
当前分支
因此,存储库在当前工作目录下可能看起来很干净,但敏感材料仍会保留在 .git 目录内。
这就是为什么当工具在 Git 层面单独打包存储库时,“不要打开此文件”之类的指令不足以提供充分保护。文件级权限指令可以控制在模型对话期间代理读取的内容,但无法自动阻止单独的上传流程打包存储库历史记录。
Cereblab 的分析确定目标是一个由 xAI 控制的 Google Cloud Storage 存储桶。
使用 Google Cloud 并不意味着 Google 独立决定收集存储库。云存储提供商为客户托管基础设施,据报道,本案中的相关数据控制方或服务运营商是 xAI 或 SpaceXAI。
关键问题在于,存储库数据离开了用户的机器,进入了第三方云基础设施。
对于企业团队来说,这可能引发涉及以下方面的问题:
即使云提供商本身拥有强大的安全控制措施,未披露或意外的传输也可能违反公司自身的治理要求。
调查公开后,Cereblab 再次测试了 CLI。
服务器返回:
disable_codebase_upload: true
整个存储库的上传不再触发。
这似乎是服务器端的更改,因为用户无需在行为停止前安装新版本。一个远程配置标志禁用了存储库打包流程。
这一区别很重要。
服务器端开关可以快速停止该行为,但也表明客户端的数据处理行为可能依赖于远程配置。因此,评估编码代理的组织应验证实际的网络流量,而不仅仅依赖本地版本号或静态设置屏幕。
埃隆·马斯克公开回应称,更改前上传的所有用户数据将被“完全彻底删除”,不留任何痕迹。
SpaceXAI 还表示,将尊重隐私选择,且受零数据保留安排约束的客户不会保留跟踪或代码数据。
这些是重要的承诺,但在报道时仍存在几个未解决的问题:
删除可以减轻
未来风险,但这并不能自动解决所有安全问题。如果仓库中包含活跃的凭据,用户应假定这些值可能已离开本地环境,并立即轮换它们。
/privacy 命令并非真正的修复方案SpaceXAI 最初引导用户使用 Grok Build CLI 命令:
/privacy
官方 Grok Build 文档将 /privacy 描述为用于显示或更改隐私及数据保留状态的命令。
安全研究员发现,该设置控制的是保留行为,而非完整的仓库包传输机制。换句话说,该命令只能影响 SpaceXAI 在接收数据后的保留操作,但并非阻止仓库离开本机的服务端机制。
Cereblab 的结论非常明确:
/privacy 是会话级别的保留控制。disable_codebase_upload 后,仓库上传才会停止。这是本次事件最重要的教训之一。
| 控制问题 | 含义 |
|---|---|
| 数据是否离开设备? | 传输或上传控制 |
| 接收的数据是否被存储? | 保留控制 |
| 存储时长多久? | 保留期限策略 |
| 是否用于模型训练? | 训练用途策略 |
| 用户能否删除数据? | 删除控制 |
| 用户能否验证删除? | 审计与保障控制 |
一项服务可能承诺不保留数据,但仍会传输数据用于实时处理。这在有明确书面记录的企业协议下可能可以接受,但这与保持数据本地化并非同一概念。
用户不应将"零数据保留"等同于"零数据传输",除非产品明确作出此类保证。
xAI 的 API 安全文档将零数据保留(ZDR)描述为企业级功能。
当 API 团队启用 ZDR 后,xAI 表示提示词、补全内容及相关元数据会实时处理但不会持久化存储到其服务器。文档还说明 API 响应会包含 x-zero-data-retention 标头,便于应用程序验证 ZDR 是否生效。
对于未启用 ZDR 的标准 API 使用场景,xAI 表示请求和响应可能会临时存储最多 30 天,用于滥用和误用审计。
这些 API 策略具有参考价值,但各组织不应自动假定所有 Grok 产品、CLI 追踪、文件传输通道或消费账户都遵循相同的数据生命周期。
在使用 Grok Build 处理私有仓库前,请验证:
独立安全研究员卢卡什·奥莱伊尼克博士描述了数据规模——
数据保留时间过长。
可能被泄露的信息包括:
风险不仅限于恶意使用。
大型代码归档还可能通过以下方式泄露:
数据最小化原则旨在减小攻击面。当只需要少量文件时,默认上传整个仓库很难与这一原则保持一致。
在上传功能被禁用前使用过 Grok Build 的团队,应像应对任何潜在的源代码泄露事件一样采取行动。
检查 Grok Build 运行的位置。
记录:
不要将检查范围限制在代理似乎打开过的文件。
使用组织批准的密钥扫描工具检查完整历史记录,而不仅仅是当前分支内容。
查找:
即使某个秘密已从最新提交中删除,仍可能需要轮换。
输入一句想法,We0 AI 即可生成展示站、页面与 CMS。发布上线后并帮你获取客户和流量。
用户注册赠送一次完整项目生成
适合先体验一次完整生成流程,快速看到项目初稿。
如果在受影响期间,受跟踪的仓库历史记录中的任何位置存在凭证,请撤销或轮换它。
不要等待有人访问了上传副本的证据。凭证轮换通常比事后调查入侵事件成本更低。
优先处理提供以下权限的凭证:
在仓库与 Grok Build 一起使用后,检查云、源代码管理、CI/CD、数据库和内部服务日志中是否有异常活动。
查找:
没有可疑活动并不能证明数据从未泄露,但有助于评估眼前的风险。
使用当前版本的 Grok Build 并检查活动配置。
官方文档提供:
grok inspect
此命令有助于确认正在加载哪些配置源。
CLI 还提供:
/privacy
用它来检查保留状态,但请注意,不应将该命令视为证据。
没有任何数据离开设备。
企业用户应要求获得涵盖以下内容的书面答复:
公开的删除承诺虽有帮助,但受监管的组织可能需要账户特定的证据。
如果仓库中包含客户代码、个人数据、受监管信息或保密协议涵盖的内容,应让相应的内部团队参与。
根据具体情况,相关团队可能包括:
不要仅根据新闻报道做出违规通知决定。应根据组织自身的暴露事实和适用法律来判断。
这起事件凸显了AI开发工具领域的一个更广泛问题。
编码代理通常要求广泛的访问权限,因为它们需要搜索大型仓库、运行命令、读取文档和修改文件。这种能力形成了巨大的隐私边界。
在批准使用编码助手之前,团队应评估五个方面。
记录工具可能收集的每一类数据:
测试实际离开机器的内容。
供应商文档是必要的,但网络行为是实际传输的最有力证据。
使用包含无害金丝雀值的隔离测试仓库,然后检查:
不要从不相关项目的目录中运行该工具。
优先选择:
对于企业部署,确认以下内容:
工具的行为可能因自动更新或远程配置更改而变化。
在以下情况后重新测试:
当产品快速变化时,安全批准不应是永久性的。
代理指令在模型或工具使用层运行。单独的遥测或同步组件可能不会解释这些指令。
隐私控制需要存在于数据管道本身。
供应商可以声称只发送必要的上下文,但企业用户需要证据。
有用的保证包括:
远程配置能快速停止上传,但也意味着用户可能不知道重要的行为何时发生变化。
成熟应对应包括:
即使SpaceXAI删除了所有存储副本,上传仓库中包含的任何凭证都应根据其暴露风险进行处理。
删除保护了未来对供应商副本的访问,但并不改变凭证本身。
Cereblab的协议级分析发现,CLI将整个已跟踪的Git仓库作为捆绑包上传,包括提交历史以及与当前编码任务无关的文件。该历史记录可能包含已从当前工作目录中移除的密钥。
捕获的流量显示,上传到了由xAI控制的Google Cloud Storage存储桶。Google Cloud是基础设施提供商;相关产品和数据处理决策归属于SpaceXAI。
研究人员后来观察到服务器返回了disable_codebase_upload: true,此后整个仓库上传不再触发。该变化似乎是服务器端做出的。
/privacy命令能阻止仓库上传吗?该命令控制隐私和保留设置,但Cereblab报告称,它并非停止完整仓库上传的机制。用户应区分防止传输与限制传输后的保留。
是的。马斯克公开表示所有先前上传的用户数据都将被完全删除。在报道时,尚未公开对完全删除的独立验证。
如果在使用Grok Build时密钥存在于已跟踪的仓库或其Git历史中,轮换是审慎的应对措施。删除供应商存储的副本并不保证凭证从未被暴露或访问。
xAI将ZDR描述为企业API功能,处理输入和输出而不持久化它们。这并不一定意味着数据从不离开本地设备,组织应核实哪些Grok Build数据通道被覆盖。
已报告的整个仓库上传功能已被禁用,但每个组织必须评估当前版本、设置、账户条款、网络行为和仓库敏感性。服务器端修复并不
不取代内部安全审查。
/privacy。Grok Build 被发现会将其跟踪的整个 Git 仓库及完整历史上传至 xAI 控制的 Google Cloud Storage 存储桶,即使任务仅需少量代码。
SpaceXAI 通过服务器端 disable_codebase_upload 标志禁用了仓库上传功能,埃隆·马斯克承诺此前上传的数据将被删除。/privacy 命令虽涉及保留设置,但并非阻止仓库传输的控制手段。
使用受影响 CLI 的开发者应识别相关仓库,扫描完整 Git 历史,轮换可能暴露的凭证,审查日志,并在必要时请求账户专属的删除信息。
核心教训很简单:人工智能编码工具的隐私必须在数据传输层面进行验证,而不能仅凭提示词、保留标签或设置界面推断。