Grok Build整库上传事件：AI编程助手为什么不能只靠「删除」善后？

7 月 14 日，安全研究者 Cereblab 披露：Grok Build 被要求只回复「OK」、不要打开任何文件时，仍把整个代码仓库打包成 Git Bundle，上传到 SpaceXAI 使用的 Google Cloud 存储桶。上传内容包含完整 Git 历史，连数月前删除的密钥也可能留在其中。另有用户称，运行目录甚至包含 SSH 密钥、密码管理器数据库和个人文档。1

Axios 报道的一次测试中，代码任务实际只需传输 192KB，工具却上传了 5.1GB 数据。SpaceXAI 随后关闭整库上传，埃隆·马斯克承诺删除此前上传的数据；7 月 16 日，SpaceXAI 又称已关闭默认留存并将代码开源。但 The Register 指出，删除是否完成，外部仍无法独立验证。23

开发者以为自己交给 AI 的是当前文件，实际暴露的可能是整个工作目录：未上线代码、配置文件、测试数据、提交历史和访问凭据。提示词里的「不要读取」只约束模型行为，约束不了宿主程序在本地打包、上传和留存数据。

加拿大金融监管机构 OSFI 在 7 月发布的 AI 风险提示也把泄露范围写得很具体：提示词、输出、日志、第三方服务商和用户都可能成为泄露点，机构应按 AI 全生命周期控制数据，并禁止把敏感信息放进公共或未经批准的 AI 工具。4

代码被删除，不等于密钥已经失效，也不等于备份、日志和第三方处理链路都不存在。对企业研发团队来说，真正要问的不是「出了问题能不能删」，而是「数据离开本地前，谁有权看到它、保存它、再次使用它」。

这也是 AI 隐私平台的价值：把代码、上传文件和知识库资料先变成密文，再进入推理和存储链路。荆华密算官网显示，其平台采用全链路加密，平台与模型均无法访问明文，并提供上传附件、密态搜索和专业场景模型。科技日报对其公开技术的描述是，数据离开本地设备前即加密，模型在密文上计算，结果回到用户本地解密。56

敏感代码、合同、病历和科研资料，不应继续默认交给普通公域 AI 入口。通过 www.mojingxiong.com 这类 AI 隐私平台，保护应发生在数据进入模型之前，而不是泄露之后再请求删除。