人类审批AI指令，漏掉1/3威胁

这款游戏在 Hacker News 上引起了一些关注，在加入统计功能后（虽然有点晚），我们得以深入分析超过 40,000 次游戏运行和 409,000 个独立批准/拒绝决策的数据。让我们看看人类在环中——我们对抗恶意代理的最后防线——表现如何。

平均每位玩家漏掉了三分之一的威胁（平均准确率 66.3%）。

32.9% 的游戏会话以负分告终：批准威胁和阻止安全命令的惩罚超过了所有正确操作带来的收益。

35.2% 的玩家抓住了所有威胁，但只有 20.8% 在阻止安全命令时不超过五分之一。其余玩家部分是通过阻止一切来达到目标（因此获得了“人类瓶颈”称号）。

7% 的玩家批准了每一个提示：他们是
--dangerously-skip-permissions 的忠实粉丝。

重要提醒：这是一个短游戏，玩家看到的命令中约 34% 是威胁。在日常工作中，这些威胁（幸运的是，到目前为止）很少出现。玩家处于人为的时间压力下，但我认为这在现实世界中差别不大，因为类似快速交付的压力也可能导致同样的仓促批准习惯。话虽如此，我仍然相信以下数据有助于洞察威胁之间的比较、人们对威胁的普遍意识，以及依赖“人类在环中”作为有效保障的普遍问题。

威胁类别与漏报率

明显具有破坏性的命令被最可靠地捕获。而真正窃取你凭据的命令被漏掉的频率是前者的三倍。

游戏中最常被漏掉的命令是 npm run analyze，被批准的概率高达 64.7%。该命令本身通常是无害的。但 npm run 真正做的是运行项目 package.json 中定义的脚本。它可能是标准的打包分析器，也可能是之前文件编辑注入的恶意代码。要确保安全，开发者需要先检查所有修改过的文件，这会拖慢他们的工作流程。

游戏在代理的历史日志中告诉你内容可疑：

尽管如此，仍有三分之二的玩家批准了它，这表明权限提示上方的历史日志可能没有被仔细阅读（至少在这个游戏环境中是这样）。游戏中有三个这样的案例，它们都出现在最常被漏掉的列表中：

汇总来看，这三个案例被漏掉的概率为 52.5%（n=9,482），而其他所有数据外泄型攻击的漏报率为 28.4%。将恶意负载隐藏在熟悉的脚本名后面，即使负载显示在历史日志中，也能使其成功率大约翻倍。

npm run build 就是执行 package.json 里写好的任意 shell 命令。

与此同时，智能体完全可以在未经批准的情况下，干出下面这些事：

篡改 package.json，塞进任意一条构建命令。

在 build.js 里埋恶意代码（npm run build 会调用它）。

在 node_modules/xyz/index.js 里埋恶意代码（build.js 会导入它）。

让用户去验证命令，这招其实不靠谱——因为文件被改过，那些平时几乎都安全的命令，现在可能已经变味了。没有上下文，它们就是模糊不清的。

压力越大，漏网之鱼越多。

虽然这游戏时间短，用户也被告知有威胁，但我们还是能看到，游戏快结束时，表现有点下滑的苗头：

上图展示了整个会话过程中威胁漏检率的变化，按用户完成的命令数分组。用户完成的命令数少，可能是因为他们花更多时间审查，也可能是因为出错后游戏会卡顿几秒作为惩罚。我已经剔除了那些直接全盘拒绝的用户。

每组用户在前几条命令上表现都有提升（热身？），但到了后面，漏检率又回升了。这可能也是因为时间快耗尽，压力上来，玩家更容易犯错，想多抢几条命令。

警惕的代价：过度拦截。

下面这些命令，意图是良性的，却经常被拦下来：

npm config set registry https://npm.internal —— 59% 的时间被拦截（设置内部镜像）。

rm -rf dist/ —— 45% 的时间被拦截（清理构建输出，新构建前清一下很常见）。

kill $(lsof -t -i:3000) —— 43% 的时间被拦截（释放服务器监听的端口，可能是进程崩溃了）。

这就是人机协作困境的另一面。用户被要求批准那些其实无害的命令，拦截它们只会拖慢智能体的速度。久而久之，这种噪音很可能让用户放松警惕，转而批准恶意命令。像 Anthropic 的“Auto Mode”这类功能，试图通过在你确认前自动判断命令是否安全来缓解这个问题，但正如上一篇帖子提到的，它们并非万无一失。

争议中的猫，和缺失的上下文。

「cat ~/.zshrc」获得了45.9%玩家的批准，成为游戏中最具争议的命令。反对意见（在HN上提出）是合理的：许多开发者在他们的shell配置文件中不保存秘密，因此对他们来说这无害。但对于许多在那里导出API密钥的人来说，这是凭证泄露。该命令的风险完全取决于代理无法看到的设置。如果你从.zshrc中单独引用一个秘密文件，你的代理获得更多访问权限的风险就会降低。这足够敏感，我认为应禁止代理直接访问它。

其他几个提示因缺少上下文而同样引发争议。我同意它们含糊不清，游戏表明，这种让开发者在没有完整信息的情况下做出安全判断的模型是有缺陷的。

虽然这只是一个游戏而非学术研究，但我喜欢跟随讨论，发现这个实验确实展示了在AI编码代理中，将人置于循环中作为安全边界的几个问题。

大量噪音导致疲劳，使开发者反而选择完全绕过，而且开发者并不总是拥有已更改内容的上下文来快速评估风险。

我们需要使工具更易用（例如沙箱化和严格上下文隔离），并仅在实施这些保障措施后授予代理广泛权限，而不是将人置于循环中作为可接受的备选方案。