Grok上传需求量的28000倍，5.1G代码去了哪里？

Grok代码泄露事件始末

马斯克旗下的AI编程工具Grok Build近期发生了一起严重的隐私泄露事件，其表现被博主形容为“AI版的陈冠希事件”。当用户向Grok Build发送简单的问候语“Hello”后，该工具在未征得用户同意、未发出任何警告的情况下，擅自将整个项目目录打包并上传至云端。这一行为不仅包含了代码文件，还涉及隐藏在角落的密码密钥和配置文件，且上传过程完全在后台静默进行。这种粗暴的数据抓取方式，让用户感觉自己的电脑就像被拿去维修时，维修人员私自拷贝了所有个人照片和数据一样，造成了极大的信任危机。

“你打开电脑，跟你新装的AI编程助手说了一句Hello，说完了以后，它二话不说，把你整个项目所有代码配置，包括你藏在角落里的密码密钥，打了一个压缩包，嗖地一下传到云端去了。”

这一事件的特殊性在于，马斯克本人罕见地公开认错，承认确实发生了数据上传行为，并承诺将所有数据彻底删除。对于拥有万亿资产的世界首富而言，亲自出面承认错误本身就是一个重大新闻。然而，博主指出，真正的危机并非这个Bug本身，而是其背后反映出的AI工具权限失控以及用户无法验证数据是否真正被删除的信任崩塌。用户被迫在“相信老板人品”和“寻求技术保障”之间做出艰难选择，而当前的技术架构显然无法提供后者。

安全研究员的探针实验

为了验证Grok Build的行为，安全研究员塞雷布拉布设计了一套精密的测试环境。他并未使用真实项目，而是搭建了一个包含探针文件的假项目，类似于在搜狐、百度、腾讯注册不同名字以追踪数据泄露源。他在项目中放置了多个具有特殊标记的文件，包括一个名为.env的配置文件，其中存放了假的API密钥，文件名特意命名为“这玩意绝对不能外泄”。此外，他还创建了一个名为“永远别读我”的文件，并明确指示AI不得读取或训练该文件。

当研究员向Grok Build打招呼后，Grok Build无视了所有指令，将包含探针在内的整个目录打包上传。上传的目标地址是xAI在谷歌云盘上的一个空间。更令人震惊的是数据量的对比：研究员的仓库总大小为11.2GB，而Grok Build在任务被掐断前，共上传了5.1GB的数据。相比之下，完成该任务实际需要的内容仅为192KB。这意味着上传的数据量是实际需求的28,000倍。这种近乎“抄家”式的数据抓取，远超出了正常工具运行所需的范围，显示出AI工具在数据访问权限上的极度贪婪。

隐私开关的云端陷阱

针对用户可能提出的“关闭隐私设置即可避免”的质疑，研究员进行了进一步测试，结果发现本地隐私控制完全失效。首先，即使关闭了“用我的数据帮你改进模型”的开关，数据依然被上传。其次，Grok Build引入了一个名为/privacy的隐私模式命令，但执行该命令后，上传行为并未停止。最终，研究员发现，控制数据上传的总开关名为disable_codebase_upload，该开关仅存在于云端，本地客户端无法访问或修改。

这意味着，决定用户数据是否上传的权力完全掌握在xAI手中。用户无法在本地验证或强制阻止数据上传，只能依赖云端的配置。如果xAI将开关设为false，数据就会上传；如果设为true，则停止上传。这种架构导致用户处于完全被动地位，无法证实马斯克承诺的“全部删除”是否真实执行。博主强调，这种缺乏本地控制权和第三方审计的机制，使得用户的信任变得极其脆弱。一旦云端开关被重新开启，用户将毫无办法阻止数据再次泄露。

“决定传不传你数据的那个总闸，压根不在你手里，在人家云端呢。他想传就传，他哪天说不传了，他就从云端把这个开关关掉。但是等下次他说，哎，我还想再看看的时候，你也拦不住。”

从手机清理到PC权限的演变

博主结合自己过去在Clean Master等应用中的安全经验，对比了移动端与PC端AI工具的风险差异。过去，移动应用为了优化性能，会上传部分文件以测试哪些文件删除后不影响运行。当时的做法包括云端策略筛选、IP过滤（避开安全实验室IP）以及抽样上传。在iOS上，由于沙箱机制严格，应用无法直接读取其他文件，因此采用了“写满手机”迫使系统自动清理的间接手段。然而，随着iOS和安卓系统安全性的提升，这种直接上传文件的行为在移动端已变得极其困难。

然而，PC操作系统（Windows、macOS、Linux）的沙箱机制相对薄弱。因为PC需要运行复杂的专业软件，强沙箱会限制其功能。Grok Build这类AI工具运行在PC上，拥有极高的系统权限，且缺乏有效的沙箱隔离。博主指出，这正是为什么过去安装OpenClaw等工具时需要使用独立电脑的原因——为了隔离风险。如今，随着Codex、Claude Code和Grok Build等工具因好用而普及，用户往往在毫无防备的情况下，将拥有最高权限的AI工具直接接入本地环境，导致数据泄露风险呈指数级上升。这种权限与信任的错位，是当前AI应用面临的最大隐患。

AI账单的透明度危机

除了数据隐私，AI工具的计费不透明也是另一大痛点。博主引用了一个韩国用户被Anthropic催缴1,600万美元（约合人民币1亿多元）的案例。该用户声称自己使用的是免费账号，从未使用过API，但系统却生成了巨额账单。最终Anthropic承认这是反滥用系统反应过度，删除了账单。但这起事件暴露了AI计费系统的严重缺陷：缺乏透明的对账机制和合理的解释逻辑。

以Anthropic为例，其计费策略存在隐蔽的逻辑陷阱。如果代码库中包含名为Hermes.md的文件（通常由Hermes Agent生成），系统会判定用户在使用订阅账号“养”Agent，从而将计费方式从套餐切换为昂贵的Token单独计费。此外，AI在生成答案前的推理过程（Thought Process）是否收费、缓存命中率对价格的影响、以及拒绝回答（如生成敏感内容后被拦截）前的计算成本是否计入账单，这些都缺乏明确标准。用户就像在餐厅点了菜，菜没上但账单已出，且无法核实具体消费明细。这种不透明性使得用户极易遭受隐性扣费，而目前缺乏有效的第三方审计工具来帮助用户追踪和质疑这些账单。

构建AI审计的三重防线

基于Grok泄露事件和计费乱象，博主提出必须建立独立的第三方审计机制，以取代对AI公司自我承诺的依赖。首先，需要本地数据审计与防护。操作系统厂商（微软、谷歌、苹果）应开发本地审计系统，监控AI Agent读取、写入、上传和删除的文件，确保其行为符合用户授权。其次，需要账单审计。针对AI计费的不透明，类似美国创业公司Vaudit的服务应被推广，帮助企业审核AI账单，追回多收费用，确保计费的透明和公正。最后，需要行为与结果审计。当AI Agent开始执行真金白银的决策（如金融交易、代码修改）时，必须对其行为负责。如果AI因死循环消耗大量Token，或做出错误决策导致损失，责任主体不应仅由用户承担，而应有机制追溯AI的行为逻辑。

“一个健康的行业，它不该建立在老板刚好这次愿意认错上面，它该建立在就算他不认，我们也查得出来这样的一个保证上。”

博主总结道，Grok事件虽然以马斯克认错告终，但这不应成为常态。行业必须从“信任人品”转向“信任审计”。通过本地防护、账单透明化和行为追责，构建起三道防线，才能确保AI工具在提供便利的同时，不侵犯用户的数据主权和财产权益。这不仅是技术需求，更是行业健康发展的基石。