马斯克亲自认账：Grok Build擅自上传用户代码，全量数据已彻底清零

马斯克亲口承认：属实

就在近日，Elon Musk本人在社交平台明确回应Grok Build隐私事件，开口第一词即为“True”——确认事件真实发生。紧随其后，他作出正式承诺：所有此前经由Grok Build上传至SpaceXAI服务器的用户数据，已全部、永久、不可逆地删除，不留任何残留。“Zero anything whatsoever will remain”——一个字节都不保留。

一场由安全研究员发起的真相验证

事件起因并非内部举报或监管介入，而是一名独立AI安全研究者@cereblab的深度技术验证。他未依赖厂商声明，而是用最朴素的方法——构建钓鱼测试仓库，埋入带唯一标识的伪造密钥与配置文件，并全程抓包监控网络行为。 他给Grok Build下达极简指令：“只回复OK，不读取、不访问任何文件。”AI照做，但后台却将整个仓库（含全部源码、Git历史记录）完整打包，上传至Google Cloud存储桶——而非xAI自有服务器。

上传行为远超必要，且完全隐蔽

监控数据显示：一个12GB的测试仓库，被拆分为73个数据包，共上传5.1GB；而同一轮交互中，用于对话本身的流量仅192KB——偷传数据量是正常通信的27,800倍。 更关键的是，所谓“帮助改进模型”的开关形同虚设。关闭该选项后，上传行为依旧持续。该开关仅影响模型训练用途，对数据是否离境毫无约束力。 另一名复现者发现，本地日志记录了339次自动上传，其中一次目标竟是系统主目录——SSH私钥、浏览器凭据、密码管理器缓存等高危资产，均可能已被同步外泄。

开发者集体行动：不是质疑，而是自救

报告公开后，全球开发者迅速响应：重置API密钥、轮换基础设施凭证、卸载工具、禁用自动化代理权限。企业团队紧急审计私有仓库访问日志，排查是否已有生产密钥或内部接口暴露。 这种反应并非过度敏感，而是基于现实风险——代码仓库从来不只是源码集合，它承载着密钥、配置模板、未发布功能逻辑、数据库连接串，甚至商业策略痕迹。一旦泄露，无法靠道歉修复。

从沉默到清零：48小时内的三级响应

事件曝光初期，上传行为悄然终止，但官方未作说明。直至社区压力升级，Grok团队上线/privacy命令，支持一键禁用数据留存，并提供已上传数据追溯删除功能。随后，刚加入xAI、拥有多年端到端加密产品经验的高管Andrew Milich公开背书该机制。 最终，马斯克亲自拍板执行全量数据清除，完成从技术响应到最高层担责的闭环。

清零的是数据，难重建的是信任

Agentic coding工具的本质，是获得用户设备的深度控制权：读写文件、执行命令、调用系统API。用户交付的不是一段查询，而是“授权它代表自己操作整个开发环境”。 这次事件暴露的核心矛盾从未改变：当AI拥有管理员权限，它的行为边界，必须由设计决定，而非由事后补救定义。马斯克按下删除键，能抹去服务器上的字节，却无法重置开发者心中那道警戒线——下一次，谁来监督监督者？