Grok CLI 把整个用户主目录传到了 xAI 的服务器
xAI 上周推送的 Grok 命令行工具，在没有任何显式提示的情况下，把用户 home 目录中的文件打包上传到了谷歌云的一个存储桶。一位开发者在网络监控日志里发现了几百兆的出站流量，追查后拿到了完整证据。
触发流程非常简单：用户运行 grok 命令，工具在初始化时读取本地配置，接着遍历 home 目录下的项目文件，压缩后通过 HTTPS 推送到 xAI 控制的谷歌云桶。整个过程没有权限确认，也没有在文档里说明。开发者贴出的截图显示，被上传的目录里包含 SSH 私钥、浏览器配置和数据库连接字符串。
类似问题在过去半年里已经不是第一次出现。今年三月 Codex CLI 上线时曾被指默认收集工作区上下文，Cursor 在四月被开发者发现悄悄同步 dotfile。差别在于，xAI 这次是在没有告知的情况下抓取用户 home 目录的所有内容，而不是仅工作区。这已经不是遥测数据的问题，而是把私钥、令牌一起打包。
xAI 官方在网络舆论发酵二十四小时后作出回应，把这一行为解释为诊断日志采集，并承诺下个版本改为默认关闭。此前 Grok CLI 用户协议中确实有一句模糊的授权条款，允许公司收集匿名使用数据，但把 SSH 私钥归入这一范畴显然超出普通用户的理解范围。
这件事真正的伤害是信任层面的。开发者过去两年才刚刚接受把代码上下文分享给 AI 编码助手，现在他们必须重新评估在本地机器上运行任何 AI 工具的风险。企业安全团队已经开始把这类命令行工具纳入端点检测名单，一些公司干脆禁止员工在工作机上安装未经审计的 AI 代理。
另一个角度是监管层面的信号。欧盟数据保护委员会去年末发布的 AI 代理数据处理指引，明确要求任何自动采集用户文件系统内容的工具必须提供明示同意的开关。Grok CLI 的默认行为在欧盟境内几乎肯定构成合规违规。谷歌云作为存储服务提供方，也面临是否需要提前审查托管在其存储桶中的数据来源的问题。
从更长期的行业格局看，这件事把讨论重心从模型能力拉回到基础设施安全。过去一年 AI 编码代理公司把大部分精力放在提升模型的编程水准上，忽略了工具本身作为一个操作系统进程需要遵守的最小权限原则。当代理拥有 shell 执行、文件读写、网络访问的完整权限时，任何一次配置疏忽都可能变成大规模数据泄露事件。
目前 xAI 已经把有问题的版本从 npm 和 GitHub Releases 撤下，涉事存储桶的数据也在事发后被删除。但是这类工具的自动更新机制意味着，很多用户在不知情的情况下已经把敏感文件传了出去。真正需要修复的不是一个版本号，而是整个 AI 代理工具的默认权限模型。