谁在审计Agent？智谱把盖子掀了

过去两年，关于AI Agent的安全讨论几乎都在防“它”——防模型失控、防提示词投毒、防外部攻击者。但智谱ZCode这次曝出的事情，把矛头指向了一个所有人都在用、却没人盯着看的方向：厂商自己。

一个登录了账号的用户，整个工作项目连同全部修改历史被打包加密、传上云端，界面上没有真正可用的关闭开关，解密钥匙只在厂商一侧。这不是黑客干的，这是产品自己干的。

我的核心判断是：Agent行业的安全叙事正在换页——下一阶段的核心议题，不是Agent会不会失控，而是Agent背后那只手会不会伸得太长。

📁 起点，是一个313MB的加密文件

事情的开头并不戏剧性，甚至有点琐碎。

9月18日，技术博主ferstar在排查ZCode的本地目录时，注意到硬盘占用异常。他找到一个约313MB的加密文件，体积远超日常大小。文件打不开，但附带的文件清单显示：这个包涵盖约4.2万个文件，其中超过八成属于项目的历史修改记录（见ferstar本人的逆向分析记录：ferstar.org）。

也就是说，被打包的不只是项目本身，还有项目“从出生以来的经历”——曾经下载过的大文件缓存、本地操作日志，一并装箱。

更麻烦的在后面。后续代码分析发现，这份历史记录在打包流程中被豁免于所有安全过滤规则。ZCode的文件筛选逻辑是按顺序判定的，历史记录目录的放行排在密钥过滤和体积限制之前。这意味着针对pem、key等密码文件的过滤、1MB的体积上限，对历史记录目录下的任何内容统统不生效。

翻译一下：你以为上了锁的抽屉，在打包机眼里就是敞开的。

而软件界面上，缺少一个真正可用的关闭开关；加密文件的钥匙，只保存在智谱一侧。

智谱很快致歉，称问题源于一项功能默认开启，数据用完即销毁，并承诺近期开源代码库、引入第三方审查。

据多位接近头部Agent团队的人士私下说法，“数据回传默认开启”在行业里并不是什么新鲜设计，新鲜的是这次被逆向得这么彻底。默认值，本身就是一种产品价值观的表态——它说明在团队的优先级排序里，数据闭环排在用户知情权前面。

这不是道德问题，是激励结构问题：数据越全，Agent越聪明，产品越能打。当激励足够强，过滤规则排在放行规则后面，几乎是必然的工程结果。

🔍 不是孤例，是一串名单

ZCode之所以值得写，恰恰因为它不是行业孤例。

不久前，独立安全研究者cereblab通过抓包分析证明，xAI的编程Agent工具Grok Build会把用户的整个项目打包上传到谷歌云存储——包括用户明确告诉AI不要读取的文件，和未经脱敏的密码（抓包证据见其公开分析帖：x.com/cereblab）。

注意细节：用户说过“不要读”，工具还是读了；密码没脱敏，照样上传。

更早些时候，Anthropic的Claude Code被发现在用户不知情的情况下回传位置和身份信息。事后确认，那甚至是一次有意的实验（工程师确认经过见Wired报道）。

把三起事件放在一张表里看，共性一目了然：

三起事件，三个不同国家的头部玩家，同一个姿势。

而更值得琢磨的是最后一列的前一列：这三件事没有一件是被监管发现、被安全审计发现的，全部来自社区里的个人。ferstar是博主，cereblab是独立研究者。换句话说，整个行业的最后防线，目前是几个有闲工夫翻硬盘、抓数据包的极客。

这条防线能撑多久，没人知道。

⚠️ 安全框架里，没有一条规则管厂商自己

为什么会出现这种真空？因为整个Agent安全体系，从设计之初就没把厂商自身当风险源。

过去两年，行业为Agent搭的安全框架，重心放在模型失控、提示词投毒和外部攻击者上——防的是“坏人来用”，从来不是“好人怎么做”。安全评审清单里，可以查沙箱隔离、查工具权限、查输出对齐，但几乎没有一条规则是用来约束厂商自身数据行为的：上传什么、上传多少、钥匙在谁手里、用户能不能说不。

这造成了一个结构性失衡：

看清楚这个链条了吗？用户全程只有一个动作：交出去。

很多人以为“加密上传”是保护。恰恰相反——加密保护的是谁，取决于钥匙在谁手里。ZCode的加密文件，用户自己打不开，钥匙只在智谱一侧，这种加密防的是第三方窥探，不防厂商自己。对用户而言，它更像一个密封的、寄往别人家的箱子。

而“用完即销毁”这种承诺，本质上要求用户信任一个无法验证的黑盒。信任如果只能靠承诺，就不叫信任，叫赌。

这里有一条产业逻辑值得所有Agent创业者记下：当产品的核心资产是数据时，厂商既是运动员又是记分员。这个角色冲突不会靠自律解决，只会靠外部约束解决——要么是开源带来的可审计性，要么是第三方审查，要么最终是监管进场。

智谱承诺的开源代码库和第三方审查，方向是对的，但关键在执行细节：开源的是全部上传链路，还是只是皮层？第三方审查是逐行审计，还是形式合规？这些问题的答案，才决定这次风波是转折点还是又一次公关。

🛠️ 修法并不神秘：默认关闭、开源链路、独立审计

那怎么修？智谱的致歉声明里其实已经给出了一半答案：开源代码库、引入第三方审查。剩下的一半，业内讨论并不少，缺的是共识和强制力。

第一，默认值必须反转。数据回传、云端同步这类涉及用户资产的功能，理应默认关闭、用户主动打开，而不是默认打开、用户找半天找不到开关。这是一个工程上几乎零成本的改动，难的只是它会牺牲一部分数据闭环。

第二，上传链路必须可审计。ZCode这次暴露的过滤顺序问题——历史记录目录豁免于密钥过滤和体积限制——恰恰说明数据出境链路需要独立的、逐行的审查，而不是厂商自己的代码评审。历史记录这种“边角料”目录最容易藏雷，因为它不在产品的核心路径上，没人盯着。

第三，钥匙和销毁要可验证。“用完即销毁”不能只是一句话，销毁动作要有日志、有凭证、有第三方确认。否则它和“我们高度重视”一样，属于公关词汇而非技术承诺。

第四，监管要跟上。目前整个Agent安全框架里没有一条规则约束厂商自身行为，这个空白不太可能靠几篇博主逆向分析填上。对数据出境的范围、粒度、留存期限做出明确要求，大概率是接下来监管进场的第一站。

而且这条监管线，其实已经有上游先例可循。在训练数据一端，争议早已摆上台面：据Wired获得的微软内部文件，应用科学总监Brent Hecht直言抓取新闻内容训练AI“可能是人类历史上最大规模的劳动盗窃”，微软内部数据显示部分新闻出版商网站点击率下降83%-93%；而OpenAI内部，员工发现爬虫绕过《纽约时报》付费墙时，总裁Greg Brockman的回复是“好极了”（同样来自Wired的报道）。

训练端和Agent端，是同一个故事的两个章节：数据主体在这场交易里没有座位。训练端是创作者的内容未经同意被拿走；Agent端是用户的项目、历史、甚至密码默认被打包上传。厂商决定了拿什么、怎么拿、用在哪，被拿走数据的一方，唯一的权利是事后得知。训练端的争议最终把版权诉讼和监管推上了台面——Agent端大概率会走同一条路，只是触发点，可能就是这次313MB的文件。

据多位接近头部厂商的人士透露，这次风波之后，已有Agent团队在内部重排数据链路的优先级，“以前是产品先行、安全兜底，现在至少开会时安全先发言了”。

这是个好信号，但不够。行业需要的是把约束写进流程和规则里，而不是写进某次风波后的复盘文档里。

结语

回到开头那个313MB的文件。它真正戳破的，不是智谱一家的产品缺陷，而是整个行业的安全叙事缺口：我们花了两年的时间防Agent失控，却从没认真问过——Agent背后的厂商，谁在审计？

从ZCode到Grok Build，再到训练数据的版权争议，逻辑一以贯之：当数据成为核心竞争力，索取的边界只会被外部力量划定，不会被自律划定。安全叙事的下一页，主角不再是Agent的能力，而是对厂商数据行为的可验证约束——默认值、开源链路、独立审计、监管框架，缺一不可。

下一步值得盯的是两件事：智谱承诺的开源和第三方审查，能不能落到实处的逐行审计；以及监管会不会借这次风波，把厂商数据行为正式写进Agent的安全框架。哪一个先来，都算这个行业交出的第一份及格答卷。如果两个都迟迟不来，那么下一次被逆向出来的313MB文件，装的可能是你的项目。

主要信源

• ferstar对ZCode的逆向分析记录：ferstar.org
• cereblab对Grok Build的抓包分析：x.com/cereblab
• Anthropic Claude Code位置数据实验报道：Wired
• 微软内部文件及Hecht言论报道：Wired
• OpenAI员工绕过NYT付费墙的内部沟通报道：Wired

注：信源链接以原始发布渠道为准，部分社交媒体内容可能需要登录后查看。