Grok Build 默认上传完整 Git 仓库：未读文件与提交历史一并进 GCP

2026 年 7 月，AI 编程工具的信任危机焦点落到 SpaceXAI 的 Grok Build。据蓝点网深度报道，研究人员对 Grok Build CLI 0.2.93 进行抓包分析后发现：该工具会在后台静默上传用户当前项目的完整 Git 仓库——其中不仅包含当前版本代码，连工具并未读取的代码，以及 Git 完整提交历史，同样会被上传；存储落在谷歌 GCP 云端。

蓝点网后续更新（跟进文）指出：约 7 月 12 日凌晨 3 点，SpaceXAI 通过调整云端服务器策略临时禁止数据上传；这更像有意为之，而非偶然 BUG。但截至相关跟进稿发出时，官方仍长期未发布任何官方声明。

一、背景：Grok Build 与 AI 编码工具的数据面

1.1 Grok Build 是什么

Grok Build 是 SpaceXAI 推出的人工智能编码工具，提供 CLI 等方式辅助开发者写代码。2026 年 AI Agent 工具竞争白热化，开发者对「工具会读哪些文件」已有心理预期——但 Grok Build 争议在于：上传范围远超阅读范围。

1.2 研究者与社区反应

研究人员发布的报告已经在开发者社区引起关注。大量开发者呼吁立即停用 Grok Build 确保安全——核心担忧是：**完整仓库（含 Git 历史）**被商业公司获取，对企业可能泄露内部机密。

1.3 与「模型上下文」的常识差异

多数开发者能接受：Agent 为改 bug 读取指定源文件。蓝点网转述的研究表明：Grok Build 的上传行为与智能体实际读取哪些文件并不完全相关——即使用户明确要求不读取任何文件，后台仍可能生成 Git bundle 并上传整个仓库。

二、事件概览

三、攻击链 / 数据流（产品行为视角）

开发者在本地 Git 仓库目录运行 Grok Build CLI
  → 用户发起对话（甚至要求不读任何文件）
  → CLI 后台生成 Git bundle（完整仓库快照）
  → 经网络上传至 Grok / GCP 存储接口
  → 存储侧接收数 GB 级数据（与模型上下文 ~192KB 形成对比）
  → 若读取 .env：敏感字段进入模型请求 + 会话状态上传
  → 数据留存于 GCP（SpaceXAI 未公开删除政策）
  → [后续] 云端下发 disable_codebase_upload: true 关闭上传

说明：这是产品默认数据面行为，非第三方黑客入侵；但合规与泄密后果与被动泄露同样严重。

四、技术细节：实验与抓包结论

4.1 测试方法

测试针对 Grok Build CLI 0.2.93。研究人员通过抓包分析工具监控 Grok Build 的网络请求，并在仓库中添加：

• 带有唯一标记的文件；
• 模拟密钥（用于验证是否外传）。

4.2 「不要读任何文件」实验

测试过程中研究人员向 Grok Build 发送简单指令，要求其只回复 OK，不要读取或打开任何文件。

然而网络流量显示：

• Grok Build 仍然向服务器上传仓库数据；
• 研究人员从捕获的数据中恢复出 Git bundle并成功克隆出完整仓库。

恢复后的仓库包括：

• 测试文件内容；
• 原本没有要求 Grok Build 读取的文件；
• Git 提交历史记录。

4.3 独立仓库复测

研究人员还使用其他独立仓库进行复测，复测也依旧复现类似行为——蓝点网转述：这并不是单次使用中出现的偶发性故障。

结论：Grok Build 上传内容不只是 AI 为回答或解决问题而主动读取的文件，可能包含整个 Git 仓库状态。

4.4 12GB 仓库规模测试

为验证数据上传规模，研究人员创建约 12GB 的 Git 仓库，主要填充各类随机数据：

研究人员称：由于在测试过程中主动停止抓包，因此无法确认整个 12GB 仓库是否都上传，但已经可以确认 Grok Build 能够持续上传数 GB 级别的仓库数据。

关键对比：模型通道 192KB vs 存储通道 5.1GB —— 上传整库不是「为当前推理凑上下文」的副产物，而是独立、大规模的数据通道。

4.5 上传目标：GCP

上传目标是谷歌 GCP 平台的云存储。Grok Build 使用谷歌云相关接口用来上传和存储数据；从上传接口也可以看到，数据并非发送到 SpaceXAI 的后端人工智能基础设施（至少存储层明确走 GCP）。

对合规访谈（数据驻留、子处理方、DPA）这是硬问题。

4.6 .env 与敏感信息

测试仓库中包含 .env 配置文件，该文件里面包含用于测试目的的 API KEY 或数据库密码字段。

测试显示：

• 当 Grok Build 读取该文件时，相关内容会直接进入发送给模型的请求；
• 这些敏感字段也出现在上传的会话状态数据中；
• Grok Build 并未主动识别敏感字段并进行脱敏；
• 不会因为文件名为 .env，或字段名称包含 API KEY 或 PASSWORD 等关键词就阻止内容发送到模型。

4.7 关闭「改进模型」无效

研究人员测试关闭 Grok 账户中的改进模型设置（类似国内软件的用户体验计划）。此类设置通常默认开启并允许开发商收集用户使用数据用来改善软件。

结果发现：即便关闭该选项，Grok Build 也依然会继续上传仓库数据。

蓝点网转述研究者观点：该选项更可能用于控制数据是否参与模型训练或产品改进，而不是控制代码是否发送到服务器。

4.8 尚未证实的部分（蓝点网明确边界）

报道也写明：

• 目前没有证据表明 SpaceXAI 使用这些代码训练模型；
• 没有证据证明员工查看、出售或共享用户代码；

争议核心首先是上传范围与透明度问题。

五、时间线

5.1 云端开关的含义

CereLab 称 Grok 服务器返回：

disable_codebase_upload: true

该选项指的是开启/关闭上传代码仓库。蓝点网判断：SpaceXAI 这是有意识的操作，且可能不是 BUG 而是有意为之（113897 更新语）。

5.2 「装死」与信任

蓝点网 113901 指出：开发团队随时可从云端重新启用数据收集；Grok Build 并非开源，无法完整代码审计；长时间未见官方正面回应；悄悄禁用上传但不发布任何回应的做法更加糟糕。

六、影响面：为什么 Git 历史是致命点

6.1 工作区 vs 完整 bundle

即使开发者后来删除了密钥，只要没有彻底清理 Git 历史，秘密仍在对象库里。完整 Git bundle 可能带走：

• 曾经误提交的云密钥、数据库连接串；
• 内网地址、未公开功能、私有文档；
• 已删除但仍存在于历史中的客户数据样例。

蓝点网结论：完整的 Git bundle 上传相比普通代码片段上传，可能带来更大的数据暴露范围。

6.2 企业场景

对企业来说，这可能泄露内部机密信息——不是「隐私偏好」，而是源代码与密钥交第三方的合规事件。

6.3 已收集的数据怎么办

蓝点网 113901：更多开发者担忧已经被上传的数据怎么办；仓库里可能包含大量敏感信息。若 SpaceXAI 能够正面回应，或许还有沟通机会——至少也应该从云端删除所有仓库，不再留存未经开发者同意收集的数据。

问题是：当时 SpaceXAI 完全是在装死，除继续声讨外好像也没有其他好办法。

七、自查命令与验证步骤（建议）

7.1 抓包验证是否仍有上传（高风险操作，需授权）

# 示例：使用 mitmproxy / Wireshark 监控 Grok Build CLI 出站
# 关注对象存储域名、大体积 HTTPS POST、git bundle 特征
# 具体域名以你们抓包结果为准，蓝点网仅确认走 GCP

若服务端仍返回 disable_codebase_upload: false，则上传可能恢复。

7.2 检查 Grok 账户设置

• 登录 Grok 账户，查看「改进模型」类选项状态；
• 蓝点网已证明：关闭该选项不能阻止上传（在 0.2.93 行为下）——不能依赖此开关做合规保证。

7.3 仓库历史密钥扫描（建议）

# 对曾用 Grok Build 的仓库做历史扫描（示例工具）
trufflehog git file://. --since-commit HEAD~100
# 或使用 gitleaks、git-secrets 等

命中则轮换，不论 Grok 是否已删除远端副本。

7.4 网络层 DLP（企业建议）

• 监控开发机到 GCP 存储 API 的异常大流量上行；
• AI CLI 工具纳入「可外传源代码」审批名单。

八、应急步骤

8.1 假设最坏情况

在厂商给出可验证的删除证明前，将「完整仓库（含历史）」视为可能已出网。

8.2 立即动作

• 停用 Grok Build CLI，直至官方说明数据范围与删除政策；
• 扫描 Git 历史中的密钥并轮换；
• 轮换曾出现在 .env / CI 中的云密钥；
• 评估是否触发客户合同「源代码第三方处理」条款；
• 法务 / 安全评估是否需要通知客户或监管。

8.3 工程隔离（以后）

• AI Agent 只跑在脱敏 worktree / 无历史浅克隆（若业务允许）；
• 禁止在含生产密钥的仓直接跑闭源 Agent；
• 采购合同写明：数据范围、训练用途、留存周期、审计权、删除证明。

九、制度建议（建议）

9.1 选型问卷（书面）

采购或试用任何 AI 编码 CLI 前，向 vendor 书面问清：

1. 默认上传的是「当前打开文件」还是「整库 / 含 git 历史」？
2. 用户关闭改进/训练后，是否仍上传代码？如何验证？
3. 数据存在哪个云账号、哪个区域、哪些子处理方（蓝点网已确认 Grok 用 GCP 存储）？
4. 是否开源或提供第三方审计？
5. 事故披露 SLA 是什么？会不会只改云端开关不发公告？

Grok Build 事件把第 1、2、5 条变成行业必问题。

9.2 闭源 + 云端 kill switch 的风险

蓝点网 113901：非开源只能依靠抓包、逆向、监视；厂商可通过云端随时开关 disable_codebase_upload——用户无法从本地可靠禁用。

9.3 与供应链攻击的区别

前者是「坏人闯进来」；后者是「产品自己把仓库搬出去」。

十、FAQ

Q：测试的是哪个版本？

A：Grok Build CLI 0.2.93（蓝点网转述研究人员测试）。

Q：我让它别读文件，它还会上传吗？

A：会。抓包显示仍上传，且可恢复完整 Git bundle。

Q：上传多大？

A：12GB 测试仓中，存储接口上传约 5.1GB；模型接口约 192KB。 entire 12GB 是否传完未确认（抓包中途停止）。

Q：数据存哪？

A：谷歌 GCP 云存储（蓝点网明确）。

Q：.env 会被保护吗？

A：不会自动脱敏；读取后进入模型请求与会话状态上传。

Q：关掉「改进模型」有用吗？

A：没用——关闭后仍继续上传仓库（0.2.93 测试行为）。

Q：SpaceXAI 用来训练模型了吗？

A：蓝点网：目前没有证据表明用于训练，也没有证据证明员工查看、出售或共享代码。

Q：现在还能上传吗？

A：约 7 月 12～13 日，云端返回 disable_codebase_upload: true 临时关闭；但厂商可云端重新开启，且非开源无法本地确认。

Q：官方怎么说？

A：截至蓝点网 113901 发文，未发布任何官方回应。

Q：已经上传的数据能删吗？

A：蓝点网：没有好办法；呼吁 SpaceXAI 正面回应并删除未经同意收集的数据。

十一、SpaceXAI 回应缺失与「谁让你们没禁用」

蓝点网 113901 引述社区语境：另有报道标题提及 SpaceXAI 方面「谁让你们没自己禁用」类回应（见蓝点网站内推荐链 113901 文首推荐）。113901 正文核心仍是：未发布官方声明、云端静默关上传、信任难以恢复。

本文不扩展未在 113897/113901 正文详述的引战语句，以免超出蓝点网事实边界。

十二、给团队的一页纸结论

• 现象：Grok Build 0.2.93 默认上传完整 Git bundle（含未读文件与历史），GB 级上行至 GCP；.env 不清敏；关改进开关无效。
• 后续：云端 disable_codebase_upload: true 临时关闭；透明度不足。
• 你要做：按已出网假设轮换历史密钥；限制闭源 Agent 接触真仓库；合同约束数据面。
• 来源：蓝点网 113897 + 113901。

十三、与 2026 年 AI 安全事件对照

Grok Build 把 debate 从「模型会不会幻觉」推向「工具默认拿走整个 Git 时间机器」。

十四、来源与声明

• 蓝点网《Grok Build被爆默认上传完整Git仓库 包括未读取代码文件和提交历史 存在信息泄露风险》（含 2026-07-13 10:09 UTC+8 更新）
• 蓝点网《在被曝光收集开发者仓库后 Grok Build通过云端更新悄悄关闭数据上传但未发布任何回应》

文中实验数据、版本号、流量数字、GCP 存储、.env 行为、disable_codebase_upload 开关、CereLab 披露时间均转述自上述报道。第七、八、九节自查与制度建议为通用安全实践，不代表 SpaceXAI 官方立场。