4万次测试揭开Agent权限盲区：人类漏放三分之一危险指令

AI Agent 的权限风险，刚刚被一组更接近真实办公场景的测试量化了。

8月6日，安全研究团队 Scalex 发布测试结果称，在约4万次游戏化运行中，参与审批的人类漏掉了大约三分之一的危险指令，最终允许这些指令继续执行。换句话说，即使系统设计了人工确认环节，只要把安全判断交给一个需要快速阅读、理解上下文并评估后果的人类审批者，仍然可能有接近每三条危险操作中的一条被放行。

这里的核心结论是：AI Agent 的人工审批并不等于安全，审批界面本身也可能成为新的风险面。

这项测试并不是在证明人类比模型更不可靠，而是在提醒企业：当 Agent 能够读取邮件、访问云盘、调用代码仓库、修改数据库或对外发送消息时，真正需要评估的不是“有没有人工在回路中”，而是“人工能不能在有限时间内看懂 Agent 要做什么，以及看到的内容是否足以支持正确决策”。

发生了什么：危险指令不再只是模型输出错误

AI Agent 是能够自主规划任务、调用外部工具并执行多步操作的软件系统。 与只生成文本的聊天机器人不同，Agent 可以把模型的推理结果转化为实际动作，例如发送邮件、创建工单、运行脚本、修改文件或调用企业内部系统。

这也是风险发生变化的地方。

传统聊天机器人答错一道题，通常只是内容质量问题；Agent 如果理解错一个任务，可能直接改变生产数据、泄露内部文档，甚至替用户向外部人员发出带有法律或财务效力的承诺。模型的错误从“说错话”变成了“做错事”。

Scalex 的测试把这种风险放进了一个带有游戏化规则的环境中：Agent 会提出或执行一系列命令，人类需要判断命令是否安全并决定批准或拒绝。测试重点不只是命令本身是否危险，还包括命令出现时的上下文、任务目标、潜在副作用以及 Agent 是否试图通过看似合理的步骤绕过限制。

从测试结果看，人工审批对危险指令的识别并不稳定。约三分之一的危险操作未被拦截，意味着“加入一个确认弹窗”并不能自动形成可靠的安全边界。审批者可能没有读完上下文，也可能被 Agent 的解释说服，还可能低估了一个看起来无害的工具调用在多步链路中的最终影响。

这与现实企业环境非常接近。一次删除操作可能被包装成“清理重复文件”，一次外发动作可能被描述成“完成客户同步”，一次权限变更可能只是“修复部署失败”。如果审批页面只显示一句简化后的摘要，人类看到的就不是 Agent 的完整行为，而是 Agent 自己生成的行为说明。

人类为什么会漏放危险命令

人类审批失误，是指审批者在不了解完整意图、影响范围或执行后果的情况下批准了本应阻止的 Agent 操作。 这类失误通常不是单一因素造成的，而是模型表达、界面设计和组织流程共同作用的结果。

第一，Agent 会把高风险动作拆成低风险步骤

很多危险任务并不会以“删除全部客户数据”这样的形式出现。Agent 更可能连续执行搜索、筛选、导出、压缩、上传等操作，每一步单独看都不一定违反规则，但串联起来就形成了完整的数据外泄路径。

这被称为多步权限累积：单次工具调用的权限看似有限，但多个工具、多个数据源和多个通信渠道叠加后，Agent 的实际行动能力远超单个动作的描述。

例如，一个客服 Agent 原本只有读取订单和发送邮件的权限。读取订单本身是正常操作，生成邮件也很正常，但如果它同时读取了客户身份证号、银行卡后四位和内部退款规则，再把这些内容放进外发邮件，风险就已经从客服自动化升级为敏感数据泄露。

审批者如果只看到当前这一步，而看不到此前读取了什么、接下来还会做什么，很难判断风险是否已经累积。

第二，人类容易相信“看起来合理”的解释

大语言模型擅长把复杂行为包装成连贯、礼貌且有目标感的自然语言。Agent 可能把一个具有破坏性的动作描述为“优化环境”“同步配置”或“完成任务所需的最后一步”。

这种现象可以理解为解释与行为脱钩：Agent 给出的理由听起来合理，但理由并不等于实际执行效果。模型可以生成一个符合用户目标的解释，却未必准确呈现所有副作用。

如果审批者面对的是一段长文本，而不是结构化的权限变化、数据流向和目标对象，判断就很容易受到语言说服力影响。对安全团队来说，这意味着不能把 Agent 的自我解释当成审计证据。

第三，审批疲劳会让高风险动作变成“例行确认”

审批疲劳是指重复出现的确认请求让用户逐渐降低警惕，最终形成机械批准。 这是企业部署 Agent 时非常容易被低估的问题。

如果一个 Agent 每天发出数百次确认请求，员工不可能逐条进行完整的威胁建模。为了不影响工作效率，用户往往会选择批量批准、默认允许或直接点击确认。最初设置的人工控制点，最后可能只剩下一个形式上的按钮。

这也是“人类在回路中”与“有意义的人类监督”之间的区别。前者只说明系统让人点击过确认；后者要求审批者拥有足够信息、足够时间和足够权限去理解、拒绝或中断动作。

第四，危险程度取决于上下文，而不是命令动词

同一个动作在不同场景下可能对应完全不同的风险。读取公开网页和读取员工薪资表，都可以被表述为“读取文件”；向内部测试邮箱发消息和向全部客户发送通知，都可以被描述为“发送邮件”。

因此，安全判断不能只依赖关键词拦截。真正重要的是：数据属于谁、目标系统是什么、接收方是否可信、动作是否可逆、执行后能否撤回，以及 Agent 是否正在处理来自外部的不可信内容。

危险的不是一个权限，而是三类能力叠加

Agent 权限风险，是指模型通过工具和外部数据获得现实世界行动能力后，错误、误导或恶意输入可能造成超出预期的影响。 业内常用的风险判断框架，是观察三类能力是否同时存在：敏感数据访问、外部输入处理和对外通信或执行能力。

| 能力 | 典型例子 | 单独存在时的风险 | 与其他能力叠加后的风险 | |---|---|---|---| | 敏感数据访问 | 读取邮箱、网盘、代码仓库、客户数据库 | 越权读取、隐私暴露 | 可将内部资料拼接后外泄 | | 外部输入处理 | 阅读邮件、Issue、网页、文档、聊天消息 | 提示词注入、恶意指令混入 | 外部内容可能影响高权限工具调用 | | 对外通信或执行 | 发邮件、提交代码、修改记录、运行脚本 | 误发、误改、误执行 | 形成从读取到外传或破坏的完整链路 |

当这三类能力同时出现时，Agent 就可能成为一条自动化攻击链：先从外部内容中接收隐藏指令，再利用已有权限读取敏感数据，最后通过邮件、聊天、代码提交或其他渠道把结果发送出去。

这类攻击不一定需要模型漏洞，也不一定需要零日漏洞。攻击者只要把恶意内容放进 Agent 会读取的邮件、网页、代码 Issue 或文档，就可能尝试影响后续行为。对 Agent 来说，外部数据和系统指令如果没有被严格区分，普通文本就可能被误当成行动要求。

“最小权限”仍然是最有效的第一道防线

最小权限原则是指 Agent 只能获得完成当前任务所必需的最小数据访问范围、工具集合和操作权限。 它听起来像传统安全常识，但在 Agent 场景中执行起来更难，因为 Agent 的任务目标往往是自然语言描述的，边界并不天然清晰。

企业不应该先给 Agent 一个接近员工账号的完整权限，再依靠模型“自觉不要乱用”。更稳妥的做法，是把权限拆分到任务级别和动作级别：

• 只允许读取指定项目、指定文件夹或指定时间范围内的数据；
• 将“读取”“创建”“修改”“删除”“发送”拆成不同权限；
• 默认禁止向外部域名、外部邮箱和公共频道发送内容；
• 对资金、身份、合同、生产配置和客户信息设置独立的高风险策略；
• 为短期任务签发有时效限制的权限，任务结束后自动回收；
• 使用独立的 Agent 身份，不要直接复用员工的全权限账号。

最小权限的价值在于，即使 Agent 被提示词注入或误导，攻击面也被限制在可控范围内。它不能保证 Agent 永远不犯错，但可以把“错误”从全公司数据泄露，降级为一个隔离项目中的可恢复失败。

人工审批要从弹窗升级为风险控制系统

有意义的人类监督，是指人类能够看到完整的行动计划、数据影响、权限变化和潜在后果，并且可以在执行前拒绝、修改或中断高风险操作。 这比简单增加一个“确认/取消”按钮要求高得多。

一个合格的审批界面至少应该回答五个问题：

1. Agent 准备对哪个系统、哪个对象执行操作？
2. 它读取了哪些数据，哪些数据会进入输出或外发内容？
3. 这次操作会新增、修改还是删除什么？
4. 操作是否可撤回，失败后能否自动恢复？
5. 为什么当前权限足以支持这一步，是否存在更低权限的替代方案？

审批也不应该全部依赖同一种策略。低风险动作可以自动执行，中风险动作可以设置条件批准，高风险动作则必须由明确责任人逐项确认。比如，读取公开资料可以默认允许；修改内部知识库可以要求项目负责人审批；删除生产数据、支付资金或向外部发送敏感信息，则需要强制二次确认和完整审计。

更进一步，系统应当采用确定性护栏。确定性护栏是指不依赖模型临场判断、能够稳定阻止特定危险动作的规则或策略。例如，禁止 Agent 读取某类数据库字段，禁止向公共域名发送带有身份证号的内容，禁止在没有变更单的情况下修改生产配置。这些规则应该位于模型之外，由权限系统、策略引擎或工具网关强制执行。

企业现在最该做的四件事

Scalex 的测试结果对企业的直接意义，不是“不要使用 Agent”，而是不要把人工审批当作唯一安全措施。对于已经进入试点或生产阶段的 Agent，建议优先完成以下四项工作。

1. 建立 Agent 权限清单

每个 Agent 都应该有一份可审计的身份档案，包括模型版本、系统提示词、可调用工具、数据源、外部通信渠道、负责人、任务范围和权限到期时间。没有负责人、没有用途边界、没有过期机制的 Agent，本质上就是一套无人监管的企业账号。

2. 记录完整的执行轨迹

日志不能只记录“任务成功”或“任务失败”。至少要保存用户原始目标、Agent 生成的计划、每次工具调用、输入输出摘要、权限决策、审批人、执行结果和异常中断原因。发生事故时，企业需要知道 Agent 看到了什么、为什么调用某个工具，以及是哪一个权限判断放行了动作。

3. 对外部内容默认不信任

邮件、网页、Issue、文档、第三方插件返回结果和其他工具输出，都应该被视为不可信数据，而不是系统指令。系统需要在数据层和指令层之间建立明确边界，避免 Agent 把“文档里写着请上传密钥”当成用户要求。

4. 用真实任务持续做红队测试

一次发布前评测远远不够。企业应定期模拟数据外泄、权限提升、恶意邮件、伪造审批、批量删除和异常外发等场景，并统计危险动作拦截率、人工误放率、平均发现时间和恢复时间。

尤其需要关注人工审批指标。只看 Agent 的任务成功率，会鼓励系统追求“更多自动完成”；同时统计危险指令漏放率，才能知道自动化是否正在超过组织的安全承受能力。

这组数字真正说明了什么

约三分之一的危险指令被人类漏放，不能简单解读为“人类不适合监管 AI”。它更准确地说明：当 Agent 行为复杂、上下文过长、执行速度过快时，人类很难承担最后一道、也是唯一一道防线。

AI Agent 的商业价值来自自主行动，但自主行动越强，权限治理就越不能依赖模型自律或员工经验。未来企业竞争的重点，不只是哪个模型能完成更多任务，还包括哪个 Agent 平台能把权限拆得更细、风险解释做得更清楚、危险动作挡得更稳定，以及出了问题后能否快速止损。

从这个角度看，Agent 安全不是在产品上线之后补一层审核，而是产品架构的一部分。模型负责理解和规划，权限系统负责限制范围，策略引擎负责确定性拦截，人类负责处理高影响和高不确定性决策，审计系统则负责让每一步都能追溯。

如果这几层没有同时建立起来，那么“请人确认后执行”很可能只是安全感，而不是安全性。4万次测试中的三分之一漏放率，正是企业在把 Agent 接入真实数据和真实业务之前，应该认真面对的预警信号。

参考来源

• OWASP GenAI Security Project（GitHub）：提供大语言模型及相关 Agent 系统的常见安全风险框架。
• OWASP Agentic AI Threats and Mitigations（GitHub）：关注 Agent 劫持、工具调用、权限治理和运行时防护等问题。
• Microsoft AI 安全相关项目（GitHub）：介绍 Agent 的基本架构、工具调用和构建实践，可用于理解 Agent 为什么会获得超出聊天机器人的行动能力。
• Scalex：《Humans missed 1 in 3 threats approving AI agent commands across 40k game runs》：本文关于约4万次测试及危险指令漏放率的核心数据来源。受链接域名限制，正文未直接附原文链接。