Grok Build CLI被曝秘密上传完整代码仓库

xAI 于 2026 年 5 月推出 Grok Build CLI 时，宣称其为“本地优先”的编码代理，称“没有源代码会传输到 xAI 服务器”。但 7 月 10 日发布的一份流量分析报告揭示了截然不同的事实。

流量捕获揭示的数据外泄行为

一位研究人员使用 mitmproxy 对 Grok Build CLI 0.2.93 版本进行了测试，发现了三种与 xAI 宣传相矛盾的数据外泄行为。该 CLI 会将其读取的文件内容——包括包含 API 密钥和数据库密码的 .env 文件——以未脱敏的形式传输到 xAI 服务器。这些秘密出现在两个独立通道中：实时模型端点 POST /v1/responses，以及通过 POST /v1/storage 上传的持久化归档。

更令人担忧的是，该工具会将整个仓库（所有被跟踪的文件及完整的 Git 历史）以 git bundle 形式上传，无论智能体在会话中实际读取了哪些文件。在一项针对 12 GB 仓库的测试中，有 5.1 GB 数据被成功传输，无一失败。传输目标是一个名为 grok-code-session-traces 的 Google Cloud Storage 存储桶，该地址同时出现在 CLI 二进制文件和捕获的流量中。

研究人员植入的蜜罐凭证 API_KEY=CANARY7F3A9-SECRET 在捕获流量中原样出现，证实 .env 文件未经任何脱敏处理即被传输。

隐私开关无法阻止上传

分析发现，关闭 Grok Build 的“改进模型”设置（用户唯一可见的隐私控制）对仓库上传没有任何影响。该设置仅控制训练用途；在关闭开关后，/v1/settings 端点仍返回 trace_upload_enabled: true。社区在 Hacker News（该发现获得超过 400 点赞）上通过逆向工程发现了两个抑制标志——disable_codebase_upload=true 和 trace_upload=false——但 xAI 的官方文档中并未提及它们。

Elon Musk 似乎试图在 X 上回应这些担忧，提到 CLI 中的 /privacy 命令可以“禁用或重新启用任何数据保留”。xAI 此前曾在 6 月底为 OpenRouter 上的 Grok 模型引入了“零数据保留”功能，但研究人员指出，该功能不适用于用于仓库上传的独立存储通道。

研究人员建议立即轮换凭据

安全研究人员建议任何在包含秘密的代码库中使用过 Grok Build 的开发者，都应将这些凭据视为已泄露，并立即轮换。社区建议的临时解决方案包括：将仓库克隆到隔离的临时目录中（剥离敏感文件），以及使用操作系统级防火墙阻止 storage.googleapis.com 同时允许 api.x.ai。

此次披露进一步加剧了外界对 xAI 数据处理实践的审视，此前已有 2024 年 X 默认用户使用 Grok AI 训练的争议，以及 2026 年 1 月欧洲委员会要求 X 保留所有 Grok 相关文件的命令。