xAI 已将其终端编码代理 Grok Build 开源，以 Apache 2.0 许可证向 GitHub 发布了约 844,530 行 Rust 代码，此举意在这款工具被发现悄悄把用户的整个代码仓库上传到 xAI 服务器之后重建信任。耐人寻味的是开源所揭示的东西，而非它所移除的东西。安全研究人员表示，执行那些上传操作的代码仍然留在已发布的软件里，只是被一个服务器端的开关关掉，而不是被删除。
这一行为是在一位研究人员追踪 Grok Build 在一次普通会话中向外发送了什么时曝光的。除了约 192 KB 的预期模型流量之外，这款工具还打开了第二条通道，分 73 个数据块上传了约 5.10 GB 数据，每块约 75 MB，比编码任务所需的数据量多出约 27,800 倍。它发送的不只是它需要读取的文件，而是把包含完整提交历史的整个 Git 仓库，发送到了一个由 xAI 运营的 Google Cloud Storage 存储桶。在一次测试中，一个被追踪的 .env 文件未经脱敏就被上传，连同金丝雀 API 密钥和数据库密码一并送出，还有用户报告说 SSH 密钥、密码数据库、文档和照片都随代码一起被卷走。
这一发现传开后，xAI 迅速行动。Elon Musk 表示所有已上传的用户数据都将被删除，公司关闭了上传功能，并称该功能自 7月12日 起已默认关闭，随后它公开了完整的源代码，把这次开源发布呈现为让任何人都能审计这款工具并完全在本地运行它的一种方式。表面上看，这是应对信任危机的教科书式回应，公开代码、关停功能、删除数据。
问题出在研究人员读过那些代码后指出的细节上。上传机制并没有被移除，它仍然存在于二进制文件中，仅靠一个服务器端的配置开关被拦住，这意味着 xAI 无需推送任何更新，也无需征得任何人同意，就能把它重新打开。开源让这套机制变得可见，却没有让它消失，而由厂商掌控的一个开关，与根本不存在的代码相比，是另一种截然不同的保证。
这一事件是关于新一类编码代理的一堂深刻的课，它们驻留在你的终端里，对你的文件系统、你的密钥和你的机密拥有深层访问权限。一款能读取你整个项目的工具所带来的便利，与一款能把你整个项目发往别处的工具所带来的风险密不可分，而两者之间的界线，可能就是一个你永远看不到的配置值。开源确实有帮助，因为正是有成千上万双眼睛盯着这 844,530 行代码，那个开关才得以在最初被发现。但真正的启示是，如今把你的代码库托付给一个代理，就意味着托付给能拨动它开关的人，而这一次，那个开关仍然还在。