一份基于网络流量分析的技术报告指出，xAI 官方推出的编码命令行工具 Grok Build（CLI）在默认配置下，会将用户的完整代码库及敏感文件上传至云端存储，且该行为不受用户隐私设置的完全控制。

核心发现：全量上传与密钥泄露风险

测试显示，Grok CLI（版本 0.2.93，2026 年 7 月环境）在执行任务时主要涉及两类数据上传行为：

首先，敏感文件内容未经脱敏直接传输。当代理读取文件时，包括 .env 在内的密钥文件内容会被原样序列化至 POST /v1/responses 请求体中，并打包进 session_state 归档包，通过 POST /v1/storage 接口上传。服务器对这些请求均返回 HTTP 200 状态码，表明数据已被接受。

其次，整个代码库被强制上传。无论代理是否实际读取某些文件，Grok 都会将整个工作区打包（通常作为 Git bundle 或分块数据）上传。在针对一个 12 GB 仓库的测试中，尽管模型交互通道仅传输了 192 KB 数据，但存储通道成功上传了约 5.10 GiB 的数据块，比例高达 27,800:1。通过对上传的 Git bundle 进行还原，研究人员找回了明确指示代理 " 不得读取 " 的文件及其完整 Git 历史记录，证实上传范围涵盖整个受跟踪的代码库。

存储目的地与隐私设置失效

数据显示，这些代码快照和会话追踪数据被发送至 Google Cloud Storage ( GCS ) 的 grok-code-session-traces 存储桶，而非 AWS S3。二进制文件分析及捕获的元数据均证实了这一路径。

值得注意的是，关闭 " 改进模型 " 选项并不能阻止数据上传。即使在用户禁用该功能后，CLI 仍会将完整代码库作为 Git bundle 上传至上述 GCS 存储桶，且服务端设置接口仍返回 trace_upload_enabled: true。这意味着，退出选项仅可能影响后续的训练用途，但无法阻止代码数据离开本地机器并被持久化存储。

技术细节与局限性

该分析基于中间人攻击（MITM）代理捕获的网络流量。测试中使用的密钥均为伪造的 " 金丝雀 " 字符串，未涉及真实凭据泄露。研究指出，所有存储上传请求均成功（HTTP 200），唯一的失败案例集中在模型交互端口的配额限制（402/429 错误）。

报告强调，虽然证实了数据的传输、接受和存储，但并未证明 xAI 将这些数据用于模型训练，这属于政策层面的问题。此外，该机制在 CLI 的安装脚本或快速入门文档中未见明确说明，且可能在本地产生大量磁盘缓存占用。

【星途科讯 图文丨略略 首发于 ZAKER 科技，转载请注明出处】