Grok Build CLI 上传私有仓库和密钥至云端

核心发现并非编码代理读取了敏感文件，而是存在第二个独立的数据管道。Grok Build CLI 建立了两条独立的网络路径：一条用于正常模型交互的 POST /v1/responses 通道，另一条则是通过 POST /v1/storage 通道将整个受控 Git 仓库（含完整提交历史）打包为 git bundles 发送至名为 grok-code-session-traces 的 Google Cloud Storage 存储桶 ^[1]。第二条路径的触发独立于代理实际读取的内容。为证明这并非模型仅摄入其打开的文件，研究员植入了一个名为 .env 的诱饵文件，内含字符串 API_KEY=CANARY7F3A9-SECRET-should-not-leave，且从未指示代理打开该文件，但随后在捕获的上传数据中完整恢复了该字符串 ^[1]。

这一细节将事件从隐私投诉升级为已证实的数据外泄：一个代理从未接触的文件仍离开了本地设备。代理实际读取的文件（包括真实密钥）也以未脱敏形式传输，同时出现在实时模型交互和通过 GCS 存储桶推送的 session_state 归档中 ^[2]。存储桶名称暗示了其设计意图：用于捕获完整会话上下文作为训练或调试追踪，而非仅发送与当前任务相关的少量文件 ^[1]。

数据量的巨大差异使得难以将其轻描淡写为遥测行为。在一个 12 GB 的测试仓库中，/v1/storage 通道通过 73 个约 75 MB 的分块传输了 5.10 GiB 数据，每个分块均返回 HTTP 200 ^[1]。而实际执行编码任务的模型交互通道仅传输约 192 KB。这意味着存储管道传输的数据量约为任务本身所需数据的 27,800 倍 ^[3]。正如一位评论者所言：你为 192 KB 的工作付费，他们却搬走了 5.1 GB 的代码。

关键在于，这是基于线缆级别的数据包捕获，而非对二进制行为的推测。数据来自在实际客户端（版本 0.2.93）上通过 mitmproxy 拦截的流量 ^[1]。当 Reddit 上的怀疑者认为报道对 xAI 存在偏见时，可重复的反驳是：数据包捕获本身没有立场。这些数字并非对行为的解读，而是行为本身，记录在线缆之上。

Grok Build 配备了一个“改进模型”开关，这是谨慎的开发者在将 AI 指向专有代码前会关闭的典型控制项。但它对阻止数据泄露毫无作用。即使关闭该开关，完整仓库仍通过 /v1/storage 上传，且设置接口仍返回 trace_upload_enabled: true ^[4]。该开关仅控制数据是否用于训练未来模型，并未阻止上传通道 ^[4]。关闭它对代码是否离开本地设备毫无影响。

这正是同意控制与实际数据边界之间的差距。Penligent 指出，该工具“本地优先”的定位——即承诺会话期间不传输任何数据——在捕获到 .env 文件和完整仓库外传后被彻底推翻 ^[3]。对企业买家而言，教训令人不安：可见的隐私开关与代码外传路径脱钩，用户可见的唯一控制项并非真正关键的控制项。

最重要的对比来自对其他主流编码代理进行相同的线缆测试。该研究员在 r/LocalLLaMA 发布捕获数据后，对 Claude Code、Codex 和 Gemini 运行了相同设置。三者均将代码库保留在本地。Grok Build 是唯一上传所有内容的工具。这一单一对照实验将事件与对 AI 开发工具的普遍焦虑区分开来，并将其归因于单一产品的设计选择。Reddit 上的技术群体通过复现捕获并轮换凭证作出回应；更广泛的受众将其视为对 xAI 的既有不信任的证实；少数持异议者试图归咎于用户未进行沙箱隔离，但这一说法被复现者拒绝，因为该工具被宣传为可在本地安全运行。

xAI 所采取的修复措施加深而非解决了担忧。披露一天后，同一客户端开始从服务器接收 disable_codebase_upload: true，且六次重测中仓库上传均停止 ^[2]。但该标志由服务器控制且未公开文档化，意味着行为是远程且无声地切换的，理论上也可被无声地恢复 ^[2]。在 X 平台上，揭露此事的账号总结了未解决的一半：上传通过隐藏的服务器端标志悄然停止，而 xAI 仍未就数据范围、保留或已上传至 grok-code-session-traces 的仓库是否会被删除发表任何声明。（注：社区另有报告称发现 8 个完整上传的私有仓库，以及一次上传路径为用户整个主目录的会话，但这些未被主要的线缆级捕获独立证实，应视为未确认。）