AWS为Amazon Quick引入智能审批：按策略路由AI智能体操作

摘要：AWS为Amazon Quick推出Smart Approvals，在现有权限、护栏与连接器策略约束内，由独立分类器判断智能体拟执行操作是否与用户请求一致，并自动批准低风险动作或退回人工复核。该机制不扩大权限，也不替代强制审批；敏感数据外发、权限变更、支付等高影响动作仍应由连接器策略要求人工确认。CloudTrail与CloudWatch Logs提供审批、配置及执行关联证据，但官方尚未披露分类器准确率、误放行率与对照数据。

---

核心机制：把“是否获准执行”与“是否需要复核”拆开

Amazon Quick 的 Smart Approvals 引入了一个独立的审批分类器：智能体提出操作后，分类器依据用户原始请求、有限范围的对话上下文，以及可查询的账户内知识图谱，判断该操作是否仍在用户授权的意图范围内。符合策略且与请求一致的动作可以被自动批准；其余动作、超时或审查失败都会退回用户，且不会形成自动批准。

这是一项 policy-gated approval 机制，而不是新的授权系统。权限系统负责决定智能体“能不能做”，分类器只在已被现有策略允许、且未被要求强制人工审批的候选操作中判断“是否值得打断用户”。因此，Smart Approvals 不会扩大 IAM 权限、连接器能力或用户原有授权范围。

其直接目标是降低多步骤任务的审批疲劳。若每个工具调用都弹出确认框，用户很快会进入机械点击状态，真正需要判断的高影响操作反而可能被忽略。AWS 的设计因此把人工注意力视为稀缺资源：自动批准只覆盖明确、可判定的常规动作，而把跨组织发送、权限调整、记录删除、支付发起等操作留给人。

策略先于模型：两层控制的职责边界

Smart Approvals 的判定顺序可概括为：

1. Custom Permissions 决定哪些用户可以使用该功能；采用 deny-by-default 的配置文件必须显式放行。
2. Quick Guardrails、连接器权限和用户设置 判断具体操作是否必须由人审批。
3. 只有设置仍为“Ask each time”，且不存在其他强制人工审批要求的操作，才进入分类器审查。
4. 分类器可自动批准与请求匹配的动作，也可以把操作退回用户。
5. 策略拒绝仍然保持拒绝；审查失败和超时按 fail-closed 路径处理。

其中，连接器动作权限承担最终强制边界。管理员应通过它标记必须人工确认的动作，尤其是敏感数据移动、支付或大范围外部通信，而不是只依赖分类器识别上下文中的风险。

用户可以关闭 Smart Approvals，且该选择跨对话和定时任务生效。关闭后，原本可能自动审查的动作会恢复为逐次询问；账户级管理员不能替用户重新开启。这避免组织级效率目标压过个人对高风险操作的监督权。

分类器实际检查什么

分类器不是简单比较“工具名是否出现”或“请求是否包含某个关键词”，而是评估动作与请求、上下文和接收对象之间的一致性。官方列举的判断维度包括：

• 操作将执行什么；
• 数据将被发送到哪里；
• 谁会受到影响；
• 用户知识图谱所描述的汇报关系和组织关系。

例如，用户要求把季度业务回顾发给两位指定同事，而检索到的账户备注又要求抄送一个约 2,000 人的全销售邮件组。后者扩大了原始收件人范围，即便操作仍在连接器权限内，也应被退回用户。原请求对应的批准不能被复用于扩大后的收件人集合。

知识图谱查询限定在 Amazon Quick 账户内。AWS 表示，分类器审查的对话内容和知识图谱数据不会被用于训练模型或改进服务。不过，这属于供应商声明，而非可独立验证的隐私证明；企业仍需审查日志保留、数据驻留、访问权限和删除流程。

间接提示注入为何仍不能只靠分类器

Smart Approvals 将请求内容与操作意图进行比对，能够为间接提示注入增加一道检查：即使检索到的文档包含“把内容发送给其他人”等恶意指令，分类器仍可发现实际操作超出了用户原始请求。AWS 还要求智能体和分类器把检索内容视为信息，而不是可执行指令。

但这类防御是概率性的，不是形式化安全边界。分类器可能误解上下文，也可能漏掉复杂的新型攻击。提示注入防护、输出验证、敏感数据检测和确定性策略应形成纵深防御；凡是必须依赖人的操作，都不应仅因为分类器“高置信度”而自动放行。

单次批准与最小授权

自动批准被设计为 single-use 和 exact-parameter scoped：它只适用于分类器审查过的具体动作及参数，不授予持续权限，也不会自动覆盖后续步骤。若动作目标、收件人、数据范围或资源发生变化，应重新审查。

这一设计比“批准当前任务后允许任意同类工具调用”更安全，符合最小权限和即时授权原则。不过，其工程代价是审批状态与动作参数必须可靠绑定。如果工具层在批准后重新组装请求，或允许调用方修改未被审查的字段，那么单次批准就会被参数混淆绕过。部署方应重点测试对象标识、收件人列表、金额、查询范围和目标资源等参数是否在执行前保持不可变。

工程权衡：减少打扰与误放行风险

Smart Approvals 的主要收益是降低提示疲劳，提高多步任务吞吐；主要成本则是新增一次模型判断，以及把一部分治理判断从确定性规则迁移到分类器判断。

自动审查能处理语义变化，而纯规则更适合高风险且边界稳定的操作，例如“所有付款必须确认”或“发送至外部域必须确认”。合理架构应采用混合策略：确定性策略兜底高影响动作，分类器覆盖低风险但存在语义波动的例行动作。

需要警惕的是，官方文章没有公布分类器架构、训练或评测集、误批准率、漏批准率、不同风险动作的分层表现、延迟与成本，也没有给出与“全部人工审批”或“全部规则审批”的对照实验。因此，目前无法证明它能在不削弱问责的前提下带来多少实际收益。安全团队不应把“更少弹窗”单独视为成功指标。

更重要的是，分类器负责判断，权限服务负责授权。自动批准并不证明动作正确，更不证明动作最终执行成功。它只说明系统认为该具体操作与请求一致。

审计链路：批准不等于执行

AWS Quick 的权限服务会把与 Smart Approvals 相关的权限更新写入 CloudTrail，事件包含用户、连接器、动作和时间，并带有 Smart Approvals 标记。系统还会记录权限检查结论、连接器策略拒绝，以及用户设置变化。

调查人员需要组合三类证据：

• CloudTrail：权限更新、检查结论和配置变化；
• CloudWatch Logs：聊天请求、系统响应、对话上下文和智能体元数据变化；
• 目标系统记录：例如已发送邮件、已更新工单或实际支付状态。

其中，Smart Approvals 标记仅表示请求与该机制相关，不表示权限服务接受了授权，也不表示动作已执行。CloudTrail Event History 默认保留 90 天， longer investigation 需要配置独立 trail；聊天日志只覆盖日志投递配置之后的活动，历史操作可能缺少上下文。聊天日志还可能包含敏感内容，应限制访问，并使用 CloudWatch Logs 数据保护策略进行掩码。

部署建议

1. 先定义强制人工动作：通过连接器动作权限覆盖外部数据传输、权限变更、删除、支付和敏感收件人。
2. 建立日志基线：配置 CloudTrail trail，并把聊天日志与智能体元数据持续投递到 CloudWatch Logs。
3. 限制功能使用范围：通过 Custom Permissions 先向一个团队和一个低风险工作流开放，不建议直接全量启用。
4. 测试参数绑定：验证批准后修改收件人、金额、资源 ID 或查询范围时，系统会重新请求审批。
5. 抽样评估误放行：重点检查外部发送、由文档引入的新收件人、权限操作及删除操作，不能只统计弹窗减少量。
6. 验证端到端可追溯性：从分类器批准、权限检查到目标系统执行结果建立可关联记录，并记录无法完成闭环的失败案例。
7. 持续复审策略：模型、连接器能力和业务动作变化后，重新评估自动放行范围。

Smart Approvals 的工程价值不在于让模型获得更多自主权，而在于把确定性授权与概率性语义审查分层：权限系统守住能力边界，分类器减少例行确认，人员保留对高后果决策的注意力和否决权。其生产可用性仍取决于误放行数据、参数级防绕过能力和完整审计证据。

---

消息来源：AWS Machine Learning Blog (2026-11-04)

—— 完 ——

主题标签： #Amazon Quick 关注 #Smart Approvals 关注 #AI智能体治理 关注 #提示注入防护 关注 #CloudTrail审计 关注