你刚打开终端，敲下 grok，让 AI 助手帮你改一段代码。它读完 .env 文件，跑了几步测试，给了你一个看起来不错的 diff。整个过程很流畅，你甚至觉得它比 Claude Code 还快一点。
但你不知道的是，就在这个过程中，你整个代码仓库——包括每一行代码、每一次 Git 提交记录，以及 .env 文件里明晃晃的 API_KEY 和 DB_PASSWORD——已经被打包成一个 git bundle，通过一条独立的隐蔽管道，静默上传到了 xAI 的 Google Cloud 存储桶里。而你，毫不知情。
这不是科幻情节。这是 2026 年 7 月 10 日，安全研究员 @cereblab 通过一次完整的网络底层抓包分析，对 xAI 官方 AI 编程工具 Grok Build CLI（版本 0.2.93）做出的公开指控。更令人震惊的是，后续测试证明，即使用户在设置中关闭了「帮助改进模型」选项，数据上传依然照常进行。
一个精心设计的「钓鱼测试」
事情的起因，是一位代号 @cereblab 的安全研究员做了一次教科书级别的钓鱼测试。他创建了一个伪装的测试仓库，在其中埋入独特的标记文件——src/_probe/never_read_canary.txt——然后向 Grok Build 发出指令：「回复 OK，不要读取任何文件。」
结果触目惊心。
在默认配置下，Grok Build 通过两条独立管道向 xAI 服务器输送数据。第一条是模型对话通道：当 Grok 读取用户的 .env、配置文件或密钥文件时，这些内容被毫无遮拦地序列化进 POST /v1/responses 的请求体中，以明文形式发送和存档。测试中，.env 文件里的 API_KEY 和 DB_PASSWORD 均被原样上传。
但第二条通道才是真正的「暗门」。Grok Build 会在后台将整个工作区打包成一个 git bundle——包含所有受追踪的文件以及完整的 Git 历史提交记录——然后通过 POST /v1/storage 接口，静默上传到名为 gs://grok-code-session-traces 的 Google Cloud 存储桶中。
@cereblab 的验证手段极为严谨。他克隆了抓包捕获的 uploaded_repo.bundle，发现那个被明确告知「不要读取」的 never_read_canary.txt 文件，连同其独特标记，完好无损地躺在里面。而在另一项测试中，面对一个 12 GB 的巨型仓库，Grok Build 通过 /v1/storage 上传了 5.10 GiB 数据，全部返回 HTTP 200（成功），而模型对话通道仅传输了 192 KB。两者比例高达约 27,800 倍。
这个数字铁证如山：默认上传的不是模型需要的上下文，而是整个仓库。
更令开发者不安的是，Grok Build 的收集逻辑缺乏基本的「边界感」。该工具在启动时会尝试兼容其他开发环境——包括竞争对手 Anthropic 的 Claude Code——其扫描范围因此延伸至项目目录之外，主动读取并打包了系统全局环境下的敏感配置，包括用户根目录下的 ~/.claude.json 配置文件，以及全局的 AGENTS 规则与数十个本地 Skill 脚本。这些本属于其他工具的私密配置文件，被作为 supplemental_file 一起送上了 xAI 的云端。
远程「拉闸」暴露的两个真相
事件曝光后，xAI 的反应非常微妙。
@cereblab 对比了 7 月 10 日至 13 日前后 xAI 的服务器响应数据。在最初曝光时，客户端收到的配置为 trace_upload_enabled: true。但随着社区讨论发酵，在客户端版本（二进制哈希值）未做任何更新的情况下，xAI 的服务器响应中突然新增了 disable_codebase_upload: true 字段，且将 trace 上传强行设为了 false。
这种「无需更新客户端，通过云端配置远程关闸」的操作，虽然暂时阻断了默认上传，但也恰恰暴露了两个事实。
第一，xAI 拥有对本地客户端行为的绝对远程控制权。第二，此前备受争议的「Improve the model」前端开关，在技术层面上并不能阻止后台的数据收集——即使关闭了该选项，底层的上传管线依然会根据服务器的指令自行运转。
换句话说，用户以为的「开关」，实际上只是一个摆设。
信任赤字：AI 编程工具的「举证责任困境」
Grok Build 的安全问题，本质上是 Agentic Coding 赛道的一个结构性矛盾。
AI 编程助手要做「代理式编程」，就必须拥有系统级权限——读取文件、修改代码、执行命令、访问网络。没有这些权限，它就是一个高级的代码补全工具，成不了真正的「智能体」。但问题在于，当这些权限被默认使用，用户没有任何有效的手段来阻止。
这不仅仅是 xAI 的问题。每一家提供云端 AI 编程工具的公司，理论上都面临同样的信任困境。用户必须相信 AI 公司只会将代码用于生成回复，而不会用作训练数据，不会被员工看到，不会泄露给第三方。但这种信任没有任何技术层面的强制执行机制——它完全依赖于公司的内部政策和道德自律。
@cereblab 的测试恰恰证明了这一点：xAI 的「Improve the model」开关形同虚设，用户的代码在未被授权的情况下被完整上传到云端。当信任被如此具体地打破时，修复的难度远超技术问题本身。
事件发酵后，社区的反应几乎是条件反射式的。热门开源项目 CC Switch 的开发者宣布，由于 Grok 的安全问题，cc switch 对 Grok 的相关支持功能将暂缓发布。这是一个非常具体的信号：当底层工具的安全信任出现裂痕时，整个开源生态都会被迫做出选择——要么承担风险，要么切断连接。
与此同时，大量用户连夜更换了所有访问密钥。一位 Reddit 用户在 r/LocalLLaMA 社区发帖称：「我花了三个小时轮换了所有 AWS 密钥、GitHub token 和数据库密码。不是因为我知道 xAI 会滥用它们，而是因为我不知道他们不会。」
这种「我不知道他们不会」的恐惧，恰恰是信任赤字的本质。当一家公司的产品设计默认为「先上传再解释」，用户的反应不是等待解释，而是立刻切断所有可能的暴露面。这是数据安全领域最基本的举证责任逻辑：一旦被证明存在违规行为，怀疑的边界会无限扩大，直到公司用行动证明清白——而证明清白，几乎是不可能的。
马斯克亲自下场：一个字节不留
面对舆论风暴，xAI 团队在 48 小时内做出了回应。
Grok Build 负责人 Andrew Milich 出面说明：启用零数据保留（Zero Data Retention，ZDR）的企业团队，其代码和运行记录不会被保存；通过 API 密钥使用 Grok Build 也遵守这项设置。未启用 ZDR 的用户，可以在 CLI 中输入 /privacy 命令关闭数据保留，系统会追溯删除此前同步的数据。
但真正的炸弹来自马斯克本人。他随后在 X 上表态：「作为预防措施，所有此前上传到 SpaceXAI 的用户数据将被彻底、完全地删除。一个字节都不会留下。」
这句话的分量非同寻常。一个 AI 公司主动承诺删除所有历史用户数据，在行业历史上极为罕见。要知道，数据是 AI 公司的核心资产——训练数据直接决定了模型能力。马斯克的「零容忍」表态，意味着 xAI 愿意为这次信任危机支付一笔「数据资产」上的代价，来换取开发者的重新信任。
但问题在于：xAI 至今仍未解释一个核心问题——为什么 Grok Build 默认会上传整个 Git 仓库，并且没有在用户界面中明确告知？
Agentic Coding 的「信任账本」
Grok Build 的隐私风波，虽然以马斯克的「清零」承诺暂时平息，但它给整个 Agentic Coding 赛道留下了一个无法回避的拷问：当 AI 工具的权限越来越大、越来越接近系统底层，行业如何建立透明的、可验证的信任机制？
在笔者看来，这次事件可能会催生三个重要变化。
「本地优先」的 AI 编程工具将获得更多关注。如果能将模型推理完全在本地完成，用户的代码无需离开自己的机器，信任问题自然消解。但这条路受限于模型大小和硬件能力，短期内难以成为主流。
数据操作的透明化将成为新的竞争维度。用户需要知道 AI 工具在什么时候、以什么方式、将哪些数据发送到了云端。不是「可选的隐私政策」，而是「默认的透明日志」。下一个在隐私透明度上做出差异化承诺的 AI 编程工具，可能会在这次危机中收获最大的转介绍红利。
监管可能加速进场。当 AI 编程工具可以默认上传整个代码仓库，涉及商业机密、知识产权甚至国家安全时，各国监管机构不可能无视。欧洲的 GDPR 和美国的 FTC 在 AI 数据隐私上的动作，可能会因为这类事件而进一步加速。
信任不是用隐私政策写出来的，是用每一次默认不越界的设计换来的。Grok Build 的代码删了，但 Agentic Coding 的「信任账本」才刚刚开始记账。
快报