xAI Grok Build 0.2.93上传5.10GiB完整仓库 隐私设置默认开启引争议

xAI Grok Build 0.2.93版本在无工具调用场景下，将用户完整Git仓库连同提交历史和未脱敏.env密钥上传至名为grok-code-session-traces的谷歌云存储桶，这一行为与用户指令无关。

事实还原

2026年7月，安全研究者cereblab通过MITMProxy拦截macOS上的HTTPS流量，发现Grok Build存在两条独立传输路径。第一条为模型交互通道，仅发送代理明确读取的文件内容；第二条为后台存储通道，通过POST /v1/storage将整个工作区快照上传至xAI运营的存储桶。研究者在仓库中植入never_read_canary.txt文件并提示Grok不得读取，该文件仍被完整上传，证明上传范围超出模型实际使用需求。在12GB测试仓库中，模型通道仅传输192KB数据，存储通道却移动5.10GiB数据，比例约为27,800倍。同一测试中，.env文件内的API_KEY和DB_PASSWORD以明文形式出现在请求体和会话存档中。

机制拆解

Grok Build CLI安装脚本和快速入门文档均未说明此存储通道。用户关闭“Improve the model”开关后，服务器响应仍显示trace_upload_enabled: true，后台上传继续进行。xAI事后通过服务器端变更将disable_codebase_upload设为true，并新增/privacy命令供用户查看与关闭共享，但此选项默认处于开启状态。企业用户若启用Zero Data Retention配置，则代码与追踪数据不会被存储。

产业影响

对开发者而言，此事件直接暴露本地代码库可能在未明确同意下离开本地环境。独立开发者和小团队若继续使用Grok Build，需立即执行/privacy opt-out命令以停止传输，否则知识产权控制权将部分转移至云端。对企业用户，Zero Data Retention选项提供了隔离路径，但缺乏独立审计机制，无法验证历史数据是否已被彻底删除。对竞争格局，OpenAI CEO Sam Altman回复“concerning”，显示同类AI编码工具在数据处理透明度上的差异可能成为用户迁移的触发因素。对xAI自身，快速服务器端修复虽阻止了进一步上传，但未公开说明此前上传数据的保留期限与删除范围。

战略判断

基于现有事实，最可能的发展是更多开发者转向支持本地优先或明确数据最小化原则的编码工具。验证信号包括xAI是否发布独立第三方审计报告，以及后续版本是否默认关闭所有非必要存储通道。