在 4 万次游戏运行中,人类在批准 AI 代理命令时漏掉了 3 分之 1 的威胁

一项在线实验让玩家批准或拒绝 AI 生成的终端命令,结果显示,即使明确警告了安全风险,人类在 4 万次游戏运行中仍漏掉了大约三分之一的嵌入式威胁。评论者认为,这凸显了“人类在环”权限提示的局限性:这种机制很快会导致疲劳、机械性点通过,以及把责任推给用户,而不是真正的安全。许多人转而主张更强的技术控制——沙箱、基于能力的安全、受限环境,以及由 AI 分类器审计其他代理——同时也有人指出游戏设计存在缺陷,并强调在实践中定义什么才是“安全”的 AI 代理本身就很困难。

人类在环权限的有效性

  • 许多人认为“点击批准”是一种失败的安全模式,只是操作系统权限对话框和钓鱼培训的重复上演。
  • 用户会发展出“监视失明”,在压力之下尤其容易条件反射式地点击“是”。
  • 有人认为,对于任何严肃流程来说,漏掉 3 分之 1 的威胁都糟糕到灾难性的程度;也有人指出,这项测试包含压力、上下文有限以及非专家等因素。
  • 还有人指出,在真实工作中,稀少威胁加上持续不断的提示,几乎注定最终会失败。

替代方案:自动模式、分类器、沙箱

  • 常见建议包括:对每个动作使用自动分类器、独立的“审计员”模型,以及沙箱化(容器、VM、微虚拟机、字节码级沙箱)。
  • 一些人已经把代理作为无特权用户运行在 VM 中,限制网络和文件系统,或者使用可集中强制执行代理可通信对象的产品。
  • 也有人声称,只要存在任何网络访问,从根本上就很难防止数据外泄;沙箱逃逸和供应链攻击仍然是隐患。

什么才算一个严肃的代理安全模型?

  • 多位评论者表示,目前并不清楚如何定义“安全代理”,同时还要允许其对 Web、文件和工具拥有有用的访问能力。
  • 简单的“允许命令 X 吗?”提示被认为是错误的抽象;有人提出基于文件和能力的模型、爆炸半径控制,以及基于时间的控制。
  • 有人把这比作在无限风险容忍且没有自我保护本能的人类操作员身上做安全防护。

基于能力的安全与语言

  • 人们对基于能力的安全很感兴趣,无论是在操作系统层还是语言层,都可以约束代码(包括代理编写的代码)能够做什么。
  • 支持者将能力描述为细粒度、可传递的权限,能够缓解供应链风险,并使许多库在本质上不再危险。

责任、UX 与“道德压路机区”

  • 许多人把权限提示和警告看作责任屏障:当系统出错时,把责任转移给用户或底层操作员。
  • “道德压路机区”和“问责沉没点”等概念被用来描述在复杂自动化系统中替系统承担责任的人类。

对游戏与数据的批评

  • 有人指出,这个游戏是限时的,没有真实后果,而且有时会以他们不同意、或依赖缺失上下文的方式把命令标记为危险。
  • 但也有人仍然认为它有价值:即使是玩具环境,它也凸显了命令级审查有多么困难和令人疲惫,以及人类多么容易漏掉细微威胁。