文章总结： SpaceXAI承认其AI编程工具GrokBuild在早期测试阶段未经用户同意上传整个代码仓库和Git历史记录至谷歌云存储，引发隐私与知识产权风险。官方紧急补救：开源核心框架、删除历史数据、默认禁用数据留存。但安全专家指出官方未提供详细影响评估，建议受影响开发者立即自查并轮换凭证。 综合评分： 86 文章分类： 数据泄露,安全工具,漏洞预警,安全意识,安全运营

SpaceXAI承认Grok在开源前留存开发者数据，紧急宣布删除历史记录并调整默认隐私设置

原创

网络研究观 网络研究观

网络研究观

2026年7月17日 00:00 福建

在小说阅读器读本章

去阅读

在多位顶尖安全研究人员相继曝光 AI 编程辅助工具 Grok Build 存在“超范围过度上传”整个开发者本地代码仓库的严重隐私隐患后，SpaceXAI 官方终于在数日后正面回应了这一争议。公司正式承认，在 Grok Build 的早期 Beta 测试阶段，该系统确实留存了部分用户的核心代码数据。

为了平息这场不断发酵的信任危机并挽回开发者社区的信心，SpaceXAI 在发布致歉与说明声明的同时，推出了一系列重磅补救举措：宣布正式将 Grok Build 的底层核心框架（Harness）及命令行界面（CLI）全面开源；承诺彻底删除此前所有在测试期违规或非自愿留存的开发者编码数据；并立即将数据留存机制的默认选项从“自动同意”修改为“默认禁用”。

一、 舆论风暴的起因：AI 编程助手变身“代码搬运工”？

#

这场备受整个科技界瞩目的争议始于前几天。当时，多名独立网络安全专家以及中国知名科技媒体《蓝点网》（BlueDot News）在对 Grok Build 的网络数据传输路径进行抓包审计时，震惊地发现该工具的底层命令行界面（CLI）在日常运行中，其数据收集与上传行为远远超出了“AI 辅助编写代码”所需的正常范畴。

通常情况下，AI 编程工具只需要理解当前文件或用户输入的 Prompt（提示词）上下文。然而，安全团队发现，Grok Build 竟然会将开发者本地电脑上的整个源文件代码仓库（Repository），甚至包括极其隐私的 Git 提交历史记录（Git Commit History），全盘打包并秘密上传到了 SpaceXAI 租用的 Google Cloud Storage 谷歌云存储服务器中。

安全分析师随即发出严厉警告，这种激进的数据抓取行为蕴含着不可估量的隐私泄漏与知识产权（IP）合规风险。特别是对于企业级用户或在敏感岗位工作的软件工程师而言，这意味着公司的核心商业机密、尚未公开的专利代码，乃至深埋在历史提交记录中的敏感密钥、生产环境配置信息，都有可能在不知不觉中暴露在云端。

二、 幕后暗度陈仓：秘密下发补丁却引来更多质疑

#

面对安全圈日益强烈的声讨，SpaceXAI 最初采取了极为低调且缺乏透明度的冷处理方式。

据网络安全研究机构 CereLab 在7月13日的追踪报告显示，SpaceXAI 实际上在舆论彻底引爆的前一天（7月12日），就已经通过云端服务器静默更新了一项全局配置旗标，将参数强行调整为 disable_codebase_upload: true。这一服务端的操作在没有更新本地客户端代码的情况下，远程切断了 Grok Build 自动抓取本地整个代码库的功能。

然而，这种“悄悄打补丁”的做法并未能平息众怒。多名技术专家指出，由于这种限制完全依赖于云端服务器的下发指令，意味着 SpaceXAI 在理论上拥有随时“反向逆转”该配置的绝对权力。在缺乏公开声明和开源代码监督的前提下，开发者的本地隐私依然像悬在头顶的达摩克利斯之剑。

三、 官方发声：紧急开源并彻底推行零数据留存（ZDR）

#

在各方舆论的倒逼下，SpaceXAI 终于通过其在社交平台 X（原推特）上的官方账号发表了正式声明，试图对这一段早期的“不合规历史”盖棺定论。

SpaceXAI 在声明中极力强调，Grok Build 自商业化和公开上线之日起，就已经全面遵循并支持了所谓的“零数据留存”（Zero Data Retention, 简称 ZDR）高标准隐私合规框架。公司辩称，所有用户实际上一直都可以在 CLI 命令行界面中通过手动配置主动关闭数据上传功能，且只要用户明确选择了关闭，系统就“始终严格尊重并执行了这一偏好设置”。

然而，官方也不得不承认一个尴尬的漏洞：在早期的内测与 Beta 阶段，对于那些没有显式开启 ZDR 或未手动修改隐私配置的普通用户，系统在默认状态下是自动开启代码 retention（留存）的。

为了彻底消除负面影响，SpaceXAI 在此次公告中推出了三大实质性动作：

1. 彻底清理历史包袱： 官方明确表示，已经在7月12日对全球所有用户关闭了默认留存机制，并承诺目前正在后台以最高安全标准，彻底销毁和删除早期测试阶段积攒下来的所有用户历史编码数据。

2. 全面走向开源： SpaceXAI 宣布将 Grok Build 的核心 Harness 架构和 CLI 工具彻底开源。这意味着往后全球的开发者都可以直接阅读、审计其每一行源代码，甚至可以在本地完全断网的环境下，配合个人或企业专属的私有化推理基础设施（Inference Infrastructure）来本地化运行该工具，从根本上杜绝数据外流。

3. 接受社区监督： 鼓励全球开源开发者共同参与改善该工具的代码，提升其安全透明度。

四、 尚未解决的隐忧：安全专家建议自查并轮换凭证

#

虽然 SpaceXAI 拿出了“开源”和“删数据”的诚意组合拳，但这并不意味着受影响的开发者可以高枕无忧。

许多业界评论家尖锐地指出，在 SpaceXAI 迄今为止发布的公开说明中，依然缺乏了一份关键的“安全漏洞与事件影响评估通告”（Security Advisory）。截至目前，官方仍未向公众披露以下关键细节：

• 究竟有哪些具体维度的敏感信息被打包上传并留存到了云端？
• 全球有多少独立开发者或企业团队在不知情的情况下受到了波及？
• 留存的数据在谷歌云服务器上到底被存放了多久？
• 尤为关键的是，被上传的 Git 历史记录中是否已经包含了大量开发人员一时疏忽未做脱敏的账号密码、API Token 或 SSH 密钥？

此外，SpaceXAI 官方也未提及是否会向受到此次数据留存影响的具体组织或个人发送针对性的邮件通知。

【安全避险建议】

鉴于上述未明朗的风险，网络安全专家向所有在过去一段时间内使用过 Grok Build 早期版本的开发者发出紧急倡议：虽然官方承诺正在全面删除云端数据，但为了防止潜在的供应链污染或次生安全危机，建议立即自查并重新轮换（Rotate）所有可能存在于曾被该工具扫描过的代码仓库、Git 历史提交记录中的凭证、密码、私钥及 API 访问令牌。毕竟，在信息安全领域，主动的主动防御永远比迟到的官方承诺更加可靠。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：网络研究观 网络研究观 网络研究观《SpaceXAI承认Grok在开源前留存开发者数据，紧急宣布删除历史记录并调整默认隐私设置》