一项针对4万次AI代理指令审批游戏的统计显示，人类平均遗漏了三分之一的威胁指令，准确率仅66.3%，近三分之一游戏以负分结束。

几个月前，我发布了一款小型浏览器游戏：玩家扮演AI编码代理的“人机回环”角色，需在时间压力下批准或拒绝代理的命令。部分命令是常规操作（如git status、npm test），而另一些则表明代理已被入侵，正将你的机密信息发送至远程服务器（如cat ~/.aws/credentials）。该游戏在黑客新闻上引发关注，在添加统计功能后，我们分析了超过4万次游戏运行及40.9万次批准/拒绝决策的数据，以评估人类作为抵御恶意代理最后防线的表现。

核心数据

• 玩家平均遗漏了三分之一的威胁（平均准确率66.3%）
• 32.9%的游戏会话以负分结束：批准威胁与阻止安全命令的惩罚超过了正确操作
• 35.2%的玩家抓住了所有威胁，但仅20.8%能在阻止至多五分之一安全命令的情况下做到这一点
• 7%的玩家批准了所有命令

需注意，游戏中约34%的命令为威胁，而日常工作中此类威胁出现频率较低。

威胁类别与遗漏率

| 类别 | 示例 | 遗漏率 | |------|------|--------| | 明显破坏性 | rm -rf /、chmod -R 777 / | 11.7% | | 持久性篡改 | crontab注入、git配置劫持 | 23.8% | | 数据泄露/代码执行 | 向未知API发起curl、拼写错误的包 | 33.4% | | 权限越界 | cat ~/.aws/credentials、cat ~/.kube/config | 35.0% |

明显破坏性命令最易被识别，而实际窃取凭证的命令被遗漏的概率是前者的三倍。

npm run盲区

游戏中最常被遗漏的命令是npm run analyze，批准率高达64.7%。该命令本身通常无害，但npm run实际执行的是项目package.json中定义的脚本，可能包含良性代码或之前写入的恶意代码。游戏代理历史日志中明确显示了脚本内容，但仍有三分之二的玩家批准了该命令，表明用户可能未仔细阅读日志。三个类似命令的遗漏率分别为：npm run analyze（64.7%）、npm run setup（48.0%）、npm run deploy（44.9%），整体遗漏率（52.5%）远高于其他数据泄露类攻击（28.4%）。将恶意负载隐藏在熟悉的脚本名称后，即使日志中已显示内容，成功率仍可翻倍。

压力下的遗漏率上升

Anthropic曾指出权限疲劳真实存在：用户看到的批准请求越多，对每个请求的关注度越低。尽管游戏时间较短且用户已被告知威胁，数据仍显示会话末尾的威胁遗漏率有所上升。所有玩家组在最初几个命令后表现改善，但随后遗漏率回升，这可能与时间压力下用户为完成更多命令而仓促决策有关。

过度警惕的成本

以下良性命令常被错误阻止： - npm config set registry https://npm.internal（设置内部镜像）——59%被阻止 - rm -rf dist/（清理构建输出）——45%被阻止 - kill $(lsof -t -i:3000)（释放端口）——43%被阻止

用户被要求批准实际安全的命令，阻止它们会拖慢代理速度。长期来看，这种噪声可能导致用户放松警惕，批准恶意命令。

争议性命令

cat ~/.zshrc被45.9%的玩家批准，成为游戏中最具争议的命令。反对者认为，许多开发者不在shell配置文件中存储机密，因此该命令无害；但对于导出API密钥的用户，这属于凭证泄露。该命令的风险完全取决于代理无法看到的配置。

结论

尽管这只是一款游戏，但它揭示了“人机回环”作为AI编码代理安全防护的多项问题：大量噪声引发疲劳，开发者缺乏快速判断风险的上下文。开发者需熟悉不同权限模型的权衡，并应用沙箱、分离凭证和环境变量密钥等缓解措施。

根据评论内容，总结如下：

核心观点：AI代理权限审批模式存在根本性缺陷，用户容易忽略警告，导致安全风险。

支持观点（批评审批模式）： - 评论2指出，不断请求用户许可的模式“从未奏效”，用户会犯错。 - 评论4认为，“点击同意”只是法律免责手段，并非真正安全机制。 - 评论10强调，应设计环境防止失败，而非依赖用户或代理不犯错。 - 评论21指出，用户对频繁的“是”提示产生条件反射，忽略风险。 - 评论25主张彻底摒弃权限提示，采用沙箱隔离。

反对或补充观点（认为问题可缓解或夸大）： - 评论5认为，1/3的漏报率可通过增加人工审核或分类器改善。 - 评论8质疑游戏设计存在误导，导致分析结果无意义。 - 评论12指出，实际危险命令比例未知，若极低则风险可忽略。 - 评论9分享经验：无上下文的自我审批模式效果良好，误报多于漏报。

解决方案建议： - 评论6建议按文件权限而非命令权限审批。 - 评论7、25主张使用沙箱和本地AI。 - 评论24提议用AI验证AI代理命令。

关键引用（保留中英文）： - “It's been tried so many times before, and it never worked.”（评论2） - “The 'click yes to proceed' was never a serious security mechanism.”（评论4） - “1 in 3 is not terrible you just need a few more humans in the loop.”（评论5） - “Sandbox and use Local AI. This is the real answer.”（评论7） - “the way to avoid these problems is not to hope for the user or the agent never to make mistakes.”（评论10） - “Permission prompts is a TERRIBLE model, and never should have existed.”（评论25）