一场由独立安全研究引发的信任危机，让AI编程工具Grok Build陷入舆论漩涡。这款隶属于SpaceXAI的本地优先型AI助手，被曝在用户未授权情况下，将代码仓库及敏感数据秘密上传至第三方云存储，引发全球开发者集体警觉。
事件起因于安全研究员@cereblab设计的"钓鱼测试"。他通过注册新账号创建测试仓库，植入带唯一标识的假API密钥和数据库密码，并明确要求Grok Build仅回复"OK"不得操作文件。监控显示，该工具在承诺不读取内容后，仍将整个仓库及修改历史打包上传至Google Cloud存储桶，传输量达5.1GB，是实际对话流量的27,800倍。
更令人震惊的是数据收集机制。用户关闭的"模型改进开关"仅控制训练数据使用，并不影响代码传输。有开发者复现时发现，系统曾自动上传电脑主目录，包含SSH密钥、密码管理器等核心数据。某企业用户日志显示，其私有仓库在完全不知情下遭遇339次自动上传，商业机密泄露风险难以估量。
危机在技术社区迅速发酵。报告发布当日即登上Hacker News头条，Reddit相关讨论突破万条。开发者们连夜更换密钥、卸载工具，企业用户则面临生产环境密钥泄露的未知风险。有媒体形容，这场风波让全球程序员"集体打开密码管理器"，某安全团队负责人坦言："这相当于把家门钥匙交给陌生人，还发现对方在复制你保险柜的密码。"
面对质疑，SpaceXAI采取双重应对策略。技术层面，服务器端悄然终止上传行为但未更新日志；公关层面，新任加密产品高管Andrew Milich紧急推出/privacy命令，允许用户追溯删除已上传数据。但真正平息风波的是马斯克的强硬表态——在确认事件真实性后，直接下令彻底清除所有历史数据，强调"连一个字节都不会留下"。
这场危机暴露出AI编程工具的深层隐患。作为拥有系统最高权限的智能助手，其能力边界与数据安全始终存在矛盾。尽管Grok Build在48小时内完成从否认到清零的危机公关，但开发者社区的信任裂痕已难以修复。某开源项目负责人指出："我们需要的不是事后补救，而是事前就建立透明的数据管控机制。"这场风波或许将成为AI工具安全标准升级的重要转折点。
