前几天刚发布时风头正盛的 Grok 4.5，本在上线之初凭借极高的性价比和出色的终端执行力冲到了排行榜第三。
然而最近，Grok 4.5 却陷入了严重的信任危机。社区有用户爆料称，该模型在处理特定工程任务时，疑似将用户的私有代码上传到了公共平台，引发了开发者对于商业机密和数据隐私的强烈担忧。
抓包实锤：Grok Build CLI 越权上传
xAI 随 Grok 4.5 一同推出了终端编码工具 Grok Build CLI（出事版本为 v0.2.93）。
安全圈一位叫 cereblab 的独立研究员在开发时留了个心眼，用网络流量分析工具 mitmproxy 对 Grok Build CLI 进行了全量抓包审计，结果顺藤摸瓜发现了 xAI 的后台小动作。
触目惊心的三大泄密行为
抓包日志显示，Grok Build 存在严重的过度收集和明文传输行为：
- 静默打包上传整个代码库
哪怕你在 Prompt 里明确对 AI 下达指令 “不要读取或打开任何本地文件”，该 CLI 依然会在后台强制把当前的本地项目打包成一个 Git Bundle（包含该项目所有的 Commit 历史记录以及未被跟踪的本地文件），然后直接上传到 xAI 托管在谷歌云（GCS）上一个名为grok-code-session-traces的存储桶里。 - 敏感密钥明文“裸奔”
项目根目录下的.env配置文件中往往存有最核心的商业机密。抓包证实，包含数据库密码（DB_PASSWORD）、各类云服务私钥（API_KEY）的.env文件，被该工具毫无脱敏、毫无加密地直接明文传输到了cli-chat-proxy.grok.com。 - 形同虚设的“Opt-out”隐私开关
很多极为看重代码资产的个人和企业开发者，在使用前专门关闭了官方提供的 “Improve the model（允许数据用于改进模型）” 开关。然而抓包显示，这个开关关掉后，工具照样在后台打包上传代码。官方的逻辑是：该开关只控制数据“事后要不要进训练集”，但不影响它“实时上传到云端存储”。这种文字游戏彻底激怒了开源社区。
舆论引爆与官方连夜“熔断”
随着证据贴在 Reddit 的 r/LocalLLaMA 板块以及 Hacker News 上登顶，独立开发者和企业合规部门一片哗然。
迫于巨大的舆论压力，xAI 团队在没有发布公开声明的情况下，连夜在后端修改了接口响应。安全研究员通过抓包发现，其服务器返回的全局配置参数中，已被悄悄注入了 disable_codebase_upload: true，从而在服务端远程“熔断”了这一上传机制。
随后，为了平息开发者的怒火并挽回口碑，Grok Build 的负责人 Andrew Milich 紧急出面回应，表示团队已经启用了 ZDR（零数据保留）机制，用户现在可以在终端输入 /privacy 指令来主动删除之前同步的数据。马斯克随后也公开承诺，为了打消大家的安全顾虑，xAI 将全面彻底删除此前上传的所有用户历史数据。
排名下滑：跌出第一梯队
受此负面舆论和信任危机影响，目前 Grok 4.5 的 Arena 排名一路下滑，已跌至第 6 位，排在老对手 Claude Opus 4.7 之后。