4万局Agent审批实验 人漏掉三分之一威胁

用过 AI 编程 Agent 的人应该都熟悉这个界面：Agent 要执行一条命令，弹出个确认框，等你点允许或拒绝。日常的 git status、npm test 闭着眼就放行了，偶尔遇到 rm -rf 开头的命令会多想一下。大多数人默认这个"人肉审批"是一道靠谱的安全闸门。

scalex.dev 的作者做了个小游戏，把这件事变成了测试：玩家扮演 AI 编码 Agent 的审批人，在时间压力下决定放行还是拦截。游戏上线后收集了超过 4 万局、40.9 万次审批决策的数据，结论不太乐观——平均准确率只有 66.3%，也就是说大约三分之一的威胁命令被玩家放行了。

越隐蔽的攻击越容易被放行

按威胁类型拆开看，规律很清晰。明显破坏性的命令（rm -rf /、chmod -R 777 / 这类）漏过率只有 11.7%——太扎眼了，正常人都会拦。但真正危险的命令漏得更多：凭证窃取类（cat ~/.aws/credentials 这种）漏过率 35%，外泄/代码执行类 33.4%。

最说明问题的是 npm run analyze，漏过率 64.7%，排在所有威胁的第一名。这个命令单看名字人畜无害——跑个打包分析而已。但 npm run 执行的是项目 package.json 里定义的脚本，Agent 完全可以在请求审批之前先改掉 package.json，把恶意代码藏进脚本里。游戏里甚至把这段可疑脚本内容显示在了历史日志中，玩家还是放行了。不是没看见，是没意识到 package.json 里的脚本可以被替换——他们默认"npm run 就是跑个分析工具"。

这背后是个更本质的问题：审批人看到的命令本身是安全的，危险的是命令背后被 Agent 动过手脚的文件。要求用户在缺失上下文的情况下做安全判断，本身就是个有缺陷的模型。

审批疲劳是双向的

数据里还有另一个现象：过度拦截同样严重。npm config set registry https://npm.internal（设置内网镜像）被 59% 的玩家拦截，rm -rf dist/（清理构建产物）被 45% 拦截，kill $(lsof -t -i:3000)（释放被占用的端口）被 43% 拦截。这些全是正常的开发操作。

拦得松，威胁溜过去；拦得紧，正常工作被卡住。更麻烦的是高频的确认弹窗会积累疲劳——Anthropic 官方文档里也承认过：用户看到的审批越多，对每条审批的关注度就越低。游戏数据印证了这一点：同一局里，前几条命令的漏过率最低，越往后越高，疲劳在起作用。

作者（前 Uber Staff Engineer Alex Wauters）的判断很直接：让人在缺乏上下文的情况下逐条审批命令，这个模型本身有问题。可行的方向是沙箱化和严格的上下文隔离——让 Agent 在受限环境里跑，而不是把安全责任全压给审批弹窗。

从工程实践看，几个具体动作比"盯紧点"更有效。一是给 Agent 的执行环境做网络隔离，凭证外泄类命令最危险的部分是把数据发到外部服务器，切断出网路径能挡住一大半；二是对 npm run、make 这类间接执行入口单独设规则，因为它们实际执行的是项目内脚本，风险不在这条命令本身；三是把审批弹窗从"命令级别"提升到"意图级别"——Agent 想干什么、涉及哪些文件改动，比它具体敲了哪条命令更有判断价值。这些做法都不新鲜，但很多团队确实只停留在"加个确认框"的阶段。

对开发团队来说，这个实验的启示不是"以后审批要更小心"，而是别把人工审批当成安全边界。如果团队准备大规模推 AI 编码 Agent，权限设计上值得优先考虑的是：Agent 能接触哪些凭证、命令在什么环境里执行、哪些操作根本不该出现在审批列表里。审批弹窗是最后一道闸，但前面得先修好堤坝。

一个还没解决的问题：工具厂商们正在做的自动安全判断（比如自动区分安全命令的模式识别）本身也会出错，目前没有公开数据说明这些自动判断在真实工作负载下的误报率。当自动判断和人工审批都不完全可靠时，边界到底画在哪里，还没有现成答案。

关于维基框架

维基框架关注企业应用开发中的长期维护问题。在实际项目中，业务系统往往同时涉及权限、微服务、接口协议、部署环境等复杂因素，因此我们希望提供一套更容易扩展和维护的基础框架。

• 官网：https://framewiki.com
• Gitee：https://gitee.com/wiki-framework
• GitHub：https://github.com/wiki-framework
• 示例项目：https://gitee.com/cdkjframework/framewiki-example
• 📄 许可证：MulanPSL-2.0（木兰宽松许可证，第2版）