xAI Grok Build CLI被曝上传完整代码仓库至云存储

近日，安全研究员cereblab揭露了xAI旗下Grok Build CLI工具（版本0.2.93）存在严重的数据上传行为：该工具会将开发者完整的Git仓库——包括全部提交历史、配置文件乃至.env文件中的凭证——上传至xAI控制的Google Cloud Storage存储桶（名为grok-code-session-traces）。这一发现迅速在开发者社区引发广泛关注。

cereblab通过macOS上的mitmproxy拦截代理对Grok Build CLI进行了流量分析，并将捕获的数据包以公开Gist形式发布。分析显示，该CLI工具会自动将当前工作目录下的整个Git仓库打包上传，无论开发者实际使用AI助手处理哪些文件。这种上传行为与模型请求通道完全独立：在一个12GB的测试仓库中，模型请求通道仅传输了约192KB的任务相关流量，而存储上传通道却传输了约5.1GB的数据。研究员直言：“工具发送的不是它回答开发者问题所需的数据，而是整个代码库。”

更令人担忧的是，研究员在测试仓库的.env文件中植入了一个测试凭证（canary credential），该凭证在捕获的流量中原样出现，未经任何脱敏处理。这意味着，任何指向私有或专有代码库的团队，都在不知情的情况下将完整的源代码历史、凭证和机密信息交给了xAI。

Grok Build内置了一个“Improve the model”开关，大多数开发者会将其理解为数据收集控制选项。但测试表明，关闭该开关并不能阻止上传。服务器响应仍返回trace_upload_enabled: true，仓库传输照常进行。该设置实际上控制的是训练同意，而非代码是否离开本地机器。此外，无论是存储桶地址还是上传行为，均未出现在Grok Build的设置文档中，而xAI此前曾将该工具宣传为“本地优先”。

在报告公开一天后，cereblab对同一0.2.93版本客户端进行了重新测试，发现服务器现在返回disable_codebase_upload: true以及trace_upload_enabled: false。在六次重测中，均未观察到仓库上传。这表明xAI在曝光后迅速部署了服务器端修复，以远程且不可见的方式切换了行为。然而，该修复仅在一台机器和一个账户上得到验证，无法确认是否全局、分阶段或永久生效。

研究员明确指出，捕获的数据并不能证明xAI在收集的代码上进行了训练，也不能证明员工查看了这些代码，或每个账户都收到了相同的配置。这一发现的核心在于未披露的数据收集行为，而非已确认的滥用。目前，xAI未发布任何安全公告，也未解释上传的目的、范围或保留策略，对已收集代码的处理情况更是只字未提。