7月13日那条投诉刷屏的时候,画面挺吓人:有用户在自己的home目录跑了一下xAI的Grok Build命令行,SSH密钥、密码管理器数据库、文档、照片、视频,统统被打包传到了xAI的Google Cloud存储桶。几小时后,马斯克表态"彻底删除",xAI也把整个Grok Build代码库以Apache 2.0协议开源——84.4万行Rust代码,一次性甩出来,姿态摆得很足。
但真去翻这批代码会发现,真正让上传停下来的开关,压根不在这84万行里。
两个版本的"上传了什么"
独立的取证分析(针对某个客户端版本)证实的,是完整Git仓库历史连同当时被读取到的文件一起打包上传——包括测试用.env文件里的明文API密钥和数据库密码。一次异常传输测得的数据量是5.10 GiB,同一时段正常的模型请求总共才192 KB,差了几万倍。
那条引爆社交媒体的投诉——home目录里的SSH密钥、密码管理器、照片视频统统被传走——目前还只是用户单方说法,没有同等严谨的独立取证支撑。Hacker News几百条评论里也没吵明白一个关键疑点:那个home目录是不是被Grok当成了"仓库"来处理,哪些未跟踪文件被卷了进去。两件事证据强度不一样,但方向是一致的:这工具在"该上传什么"这件事上,边界比用户以为的宽得多。
谁按下了真正的停止键
用户能想到的自救办法,基本都没用。关掉"Improve the model"开关,只影响数据会不会被用来训练模型,不影响数据要不要传出设备。用/privacy opt-out命令,解决的是保留问题,同样拦不住传输本身。真正让上传停下来的,是7月13日一次服务器端配置翻转——一个叫disable_codebase_upload的标志被打开,不需要用户升级客户端,用户也完全看不见。
这意味着在那次翻转之前,任何一个自以为关掉了隐私开关的用户,数据其实照样在走。控制权从来不在客户端,也不在用户手指点的那个开关上。
代码开源了,审计不到服务器那头
几小时后甩出来的84.4万行Rust代码(约3%是移植自Codex和OpenCode的工具实现,规模比OpenAI Codex的95万行Rust略小),读起来确实是一套能跑的终端编程Agent,姿态也确实好看。但翻代码会发现一个细节:gcs.rs和trace.rs里那套往Google Cloud上传的逻辑,一行没删,只是把入口函数硬编码成返回一个叫session_state_upload_unavailable的报错。
扬汤止沸,不如去薪。
水舀走了能降温,可柴火还在灶底,火迟早再烧起来。这次的修复更像前者:开关关了,架构留着。
- 结论.开源公开的是代码逻辑,公开不了的是服务器那头随时可以翻转的开关——这是云端编程Agent信任机制最脆弱的一层。
这套"本地优先"的说法本身也经不起细看。文件检查、编辑、shell执行确实在本地跑,但prompt和相关文件内容照样要通过TLS传到xAI的推理层。标准API请求默认保留30天,真正的零保留(ZDR)只对开通了企业协议的团队生效,普通用户拿不到。
84万行代码开源出来,还有个细节容易被忽略:仓库不接受外部贡献。谁都能看,没人能改。这不是完全意义上的开源社区协作,更像是一份"给你看"的透明度声明。
对普通开发者来说,现实的应对很朴素:凡是在敏感目录跑过Grok Build的,该轮换的密钥和令牌轮换一遍,不必等官方通知"是否受影响"。
- 风险.在任意敏感目录运行过Grok Build的开发者,应直接假定明文凭证已被读取上传,优先轮换密钥,不必等待官方通知。
马斯克说的"彻底删除"目前也没有第三方能验证——删没删,删了多少,只有xAI自己知道。开源代码能让人看懂这个工具怎么工作,看不懂的,永远是服务器那头这周做了什么决定。