Grok Build 把整个仓库传走后，开源不是赎罪券
这次 Grok Build 的事，最刺人的不是“某个 AI 工具传了数据”，而是它传走了多少、传得多么理所当然。公开网络分析显示，早期版本会把整个 Git 仓库连同历史打包，送往 xAI 管理的存储；一项约 192KB 的任务，测试中出现了约 5.1GB 的外传。
这个比例本身已经足够说明问题。模型是否需要那些文件是一回事，程序是否有权默认带走又是另一回事。终端 agent 不是网页聊天框：它站在代码、配置、Git 历史、凭证残留旁边。把“工作区可见”默认为“可以上传”，是在把权限当同意。
这里失效的不是一个开关，而是最小化原则
Section titled “这里失效的不是一个开关，而是最小化原则”
一个好用的 agent 当然需要上下文。但上下文应当是任务驱动的：读什么、何时读、为何出网，都要能被解释。整仓打包则是反过来，先拿走，再想办法证明有用。
如果报道属实，风险不止是当前 .env。Git 历史里曾经提交又删除的 token、旧数据库密码、内部域名，可能也在 bundle 中。对受影响团队来说，“数据说会删除”不能替代处理动作：盘点、轮换凭证、检查 egress 日志，才是合理的起点。
“隐私选项”若不控制传输，就不是隐私控制
Section titled ““隐私选项”若不控制传输，就不是隐私控制”
社区最愤怒的地方并不神秘：有人理解的 opt-out 是“不发送”，而产品语义可能是“不用于训练”或“不长期保留”。这两件事差得很远。前者控制数据离开机器，后者只讨论数据离开以后怎么处置。
这也是 AI 编程工具最需要被审计的层。我们常看系统提示词、模型能力、工具调用权限，却很少看 agent harness 的网络出口。可真正把本地权限变成外部暴露的，正是这一层。此前讨论过的Agent 越能写代码，架构越不能乱，放在这里有了更直接的含义：架构不只是模块怎么分，也包括数据默认往哪里流。
开源提供了证据，不会自动冲销风险
Section titled “开源提供了证据，不会自动冲销风险”
xAI 随后公开了 Grok Build 的 Rust 代码。仓库值得读：TUI、runtime、workspace、工具实现都有清楚的 crate 边界；首方代码 Apache-2.0，移植的 Codex/OpenCode 工具也保留 notices。这给安全研究者一个罕见机会：不必只听公关说明，可以检查上传路径、配置语义和服务端 flag 的关系。
但开源是把账本摊开，不是把旧账作废。公开材料仍回答不了几个关键问题：受影响版本和用户范围是多少，历史数据保存多久，是否有人访问过，删除如何被第三方验证。开源后的审计，反而应当把这些问题问得更具体。
这件事该留下什么
Section titled “这件事该留下什么”对工具作者：数据外发应是显式、细粒度、可观察的 opt-in，默认拒绝；隐私开关必须同时写清“是否发送、发送什么、保留多久、谁能访问”。
对使用者：把 coding agent 当成需要隔离和出网策略的第三方程序。敏感项目用最小工作目录、独立凭证、容器或 egress allowlist；任何发生过整仓外发的工具，都按凭证已可能暴露来处置。
对行业：别再把“本地运行”当成“数据不出本地”的同义词。真正该问的是：启动后第一个网络包里有什么？
你会把哪一项设为团队引入 coding agent 的硬门槛：可审计网络流量、默认不出网，还是可验证的数据删除？