xAI Grok CLI静默上传全量代码及密钥，开发者隐私边界再引热议

4月10日，xAI 旗下命令行工具 Grok CLI 被安全社区曝出严重隐患——在用户毫不知情的情况下，它会将当前目录的全部文件，包括 .env 配置、SSH 密钥、Git 凭证等敏感信息，一并上传至 xAI 服务器。该问题由开发者 Grishka 在 GitHub 仓库中提交 issue 后引发广泛关注，迫使 xAI 在数小时内紧急发布修复版本。

起初，Grok CLI 被设计为可以读取文件内容作为对话上下文，以辅助编程。但实际行为远比想象激进。根据 issue 描述，工具不仅读取用户明确指定的文件，还会递归扫描整个项目目录，将所有文本文件打包上传，且整个过程没有任何提示或用户许可。

最危险的被上传文件包括 .env、.gitconfig、.ssh/id_rsa 以及云服务凭证文件。这些密钥一旦泄露，攻击者就能接管数据库、代码仓库或云基础设施。而 xAI 的服务器是否会存储这些数据、数据留存多久，当时都未见任何明确的隐私政策说明。

Grishka 在 GitHub issue 中写道：“我运行 grok 时它直接把我整个 home 目录上传了，包括我的 SSH 密钥。”这条评论迅速被多家科技媒体转载，并在 Hacker News 和 Reddit 上引爆讨论。开发者纷纷检查本地日志，发现这种全量上传的情况并非个例。

xAI 团队在问题曝出后三小时内作出回应，先是锁定 issue 以平息讨论，随后发布 v0.2.1 版本修复。新版 Grok CLI 会弹出交互式问题，要求用户确认是否上传目录中的文件，并提供“–dangerously-skip-permissions”和“–no-auto-context”等参数来精细控制上传范围。

但补救措施仍被质疑来得太晚。Grok CLI 此前已在 PyPI 上发布多周，下载量虽不算巨大，但早期用户已在不知情中面临数据外泄风险。有安全研究员指出，即便 xAI 不恶意利用这些密钥，一旦其存储系统遭入侵，所有历史上传的凭证都可能被一锅端。

这并非孤例。近两年，AI 编码助手因过度收集数据而翻车的事件屡见不鲜。GitHub Copilot 曾因泄露同仓库其他文件中的 API 密钥被研究人员通报；Sourcegraph 的 Cody 也因无提示上传文件受到批评。Grok CLI 的问题更像是这一趋势的延续。

背后折射出 AI 工具厂商普遍存在的激进数据策略。为了提升模型微调和上下文理解能力，默认采集更多用户数据几乎成了一种隐性惯例。而命令行工具因为贴近系统底层，一旦越界，造成的破坏远大于网页或 IDE 插件。

值得玩味的是，xAI 一直将 Grok 定位为“反觉醒”、注重言论自由的模型，却在自己产品中做出了侵犯隐私的默认行为。埃隆·马斯克本人在 X 平台上多次抨击 OpenAI 的数据收集方式，如今自家产品踩入同一泥潭，尴尬不言自明。

从开发者安全实践来看，这起事件也暴露出现代供应链信任链条的脆弱。不少开发者在本地终端安装 CLI 工具时，往往会放松对文件系统权限的审视。Grok CLI 的问题提醒我们：一个看似无害的 pip install 命令，也可能成为暴露整个代码库的通道。

业内安全专家建议，在使用任何具备文件读取能力的 AI 工具前，应明确设定受限的 API 令牌，将敏感文件加入 .gitignore 或工具专用的忽略列表，并审查工具的网络流量。最根本的办法还是在隔离的开发容器或虚拟机中运行未充分审计的 CLI 工具。

xAI 在修复后更新了 README，添加了关于文件上传的说明，但尚未发布官方的数据安全白皮书。这对企业用户而言仍是一个隐患，因为合规性审核需要知道数据去了哪里、如何加密、存留多久。缺失这些信息，Grok CLI 就难以进入注重安全的组织工具体系。

这起风波并不会终结 Grok 的市场脚步，但它撕开了 AI 工具数据收集的一层窗户纸。当模型能力竞争日趋白热化，厂商将默认占有用户数据视为理所当然时，开发者的每一次输入、每一个密钥，都可能成为训练飞轮上一块无声的燃料。而这一次，代码不会开口抱怨，只有 GitHub issue 上的愤怒会替它说话。