Amazon Quick 推出 Smart Approvals：让 AI 智能体在关键操作上保留人工审核

当 AI 智能体承担更多工作时，安全负责人应如何保留人工监督？权限规定了智能体可以执行哪些操作，但一项被允许的操作仍可能需要人的判断。对每一步都要求审批看似是最安全的做法，但多步骤任务可能产生重复提示，即便是常规操作也不例外。关于安全警告的研究表明，注意力和遵从度会随着重复而下降。真正的挑战不在于要求更多审批，而在于把注意力留给需要人工审核的决策。

Amazon Quick 中的 Smart Approvals 通过在您现有控制措施内审查符合条件的操作来应对这一挑战。它会根据用户的请求评估每一项拟议操作，然后自动批准，或将其退回用户审核。这一过程不会授予额外权限，也不会取消必需的人工审批。安全负责人仍可控制哪些操作必须始终交由人工处理，而 Smart Approvals 旨在减少常规工作中不必要的打断。

图 1：策略决定是否符合条件。Smart Approvals 会批准符合条件的操作，或将其退回用户审核。被策略拒绝的操作仍保持阻止状态

策略设定边界

在进行自动审查之前，Quick 会根据 Custom Permissions、Quick Guardrails、连接器操作权限以及用户设置来评估每一项拟议操作。被拒绝的操作仍保持拒绝状态，强制人工审批仍然适用。启用 Smart Approvals 后，只有当用户设置为“每次询问”且没有其他控制措施要求人工审批时，该操作才符合条件。连接器操作权限在创建连接器时配置，可要求对特定操作进行人工审批。

管理员使用 Custom Permissions 决定谁可以使用 Smart Approvals。该功能默认开启，但启用了默认拒绝的配置文件必须显式允许它。用户也可以为自己关闭 Smart Approvals。该选择适用于所有对话和计划运行。关闭后，原本符合自动审查条件的操作需要用户批准，且任何账户级设置都无法替他们重新开启。

符合条件的操作如何被审查

Smart Approvals 使用一个独立的模型——分类器，根据用户的请求以及对对话的有限视图来评估符合条件的操作。它会考虑该操作做什么、数据流向何处以及影响哪些人。它可以查询用户的知识图谱，其中包含来自已连接来源的人员和工作关系。这有助于它理解收件人与用户的关系，例如收件人是否在用户的汇报链中。此查询仅限于您的 Quick 账户内。Quick 不会使用分类器审查的内容（包括知识图谱数据）来训练模型或改进服务。

某个操作可能符合请求，但仍值得人工审核。示例包括将内容发送到组织外部或用户汇报链中的高层领导、更改访问权限、删除记录或发起付款。这份清单并不完整，分类器还会权衡周围的上下文。对照用户的请求审核操作，增加了一道针对间接提示注入的检查，即检索内容中的指令试图改变智能体的行为。Quick 会指示智能体和分类器将该内容视为信息，而非指令。模型审核仍可能出错，因此必须始终获得人工批准的操作（包括涉及敏感数据传输的操作）应通过连接器操作权限要求人工批准。

分类器提供判断。权限服务执行授权。每次自动批准均为一次性，仅适用于所审核的确切操作和参数，且不授予持续权限。Quick 会在对话中标记自动批准。分类器未批准的操作会返回给用户，超时和其他审核失败也是如此，这些情况绝不会授予自动批准。这些执行边界限制了批准所授权的范围。它们并不证明分类器的判断是正确的。

当操作超出请求范围时

一位客户经理让 Quick 使用其团队的客户笔记和上一季度的电子邮件，为 AnyCompany 准备一份季度业务回顾简报。随后她让 Quick 将其发送给她指定的两位同事。假设该发送操作符合自动审核的条件，Smart Approvals 会根据她的请求和可用的对话上下文评估拟议的操作。

现在假设一条客户笔记指出，该简报还应发送给一个约 2,000 人的全销售分发列表。这将使受众超出她指定的收件人范围，因此 Smart Approvals 的设计是将拟议的发送操作返回给她审核，她可以在那里拒绝。发送给原始收件人的批准不能复用于更广泛的受众。

审计证据与调查

Quick 权限服务会在您账户的 AWS CloudTrail 中记录与 Smart Approvals 相关的权限更新。每个事件都会标识用户、连接器、操作和时间，并将该请求标记为与 Smart Approvals 关联。该标记并不证明权限服务接受了授权或操作已运行。Quick 还会记录权限检查结论，包括来自连接器操作权限的拒绝，以及对用户 Smart Approvals 设置的更改。

调查人员可以按用户和时间将这些事件与 CloudTrail 中的其他 Quick 活动以及通过 Amazon CloudWatch Logs 交付的日志关联起来。聊天日志会捕获用户的请求、系统响应和对话上下文。智能体元数据日志会记录对智能体的更改。目标系统的记录（例如已发送的电子邮件或已更新的工单）可确认操作是否完成。这些来源共同帮助重建事件经过，而不会将批准视为执行的证据。CloudTrail 事件历史记录会保留事件 90 天，因此请配置跟踪以支持更长时间的调查。由于聊天日志可能包含敏感内容，请限制访问权限，并考虑使用 CloudWatch Logs 数据保护策略来屏蔽敏感数据。

从哪里开始

由于 Smart Approvals 默认开启，请先确认需要人工审批的操作已通过连接器操作权限进行配置。设置 CloudTrail 跟踪，并将聊天日志和代理元数据日志投递到 CloudWatch Logs，以支持调查。聊天日志仅记录配置投递之后的活动，因此此前的审批将缺少该对话上下文。在审批要求和日志记录就位后，使用 Custom Permissions 将 Smart Approvals 限制在负责特定工作流的试点团队，然后再扩展到其他团队。

在试点之前，明确成功的标准：常规操作的提示更少，而重大操作仍会返回给人工审核。在试点期间，抽查自动审批样本并测试高影响案例，例如向组织外部发送内容或添加由文档引入的收件人。确认这些案例会返回给用户。确认你的团队能够追踪每个操作从审批到执行的完整过程。只有在结果满足这些标准时，才扩展到更多团队和工作流，并随着操作和策略的变化重新评估。

有效监督的衡量标准不是代理请求审批的频率，而是人们是否对重大决策保持控制。对于安全负责人而言，扩展 Smart Approvals 的理由应基于试点中的证据。当更少的提示能够在不削弱问责制的前提下保持注意力时，它们才有价值。

有关设置步骤，请参阅 Amazon Quick 用户指南治理部分中的 Smart Approvals。

关于作者

Steve Vinsik

Steve 是 AWS 的首席产品经理，负责 Amazon Quick 的治理、身份和安全工作。他直接与企业 CIO 和 CISO 合作，定义其组织大规模采用 AI 代理所需的控制措施，例如访问权限、护栏、模型管理、数据丢失防护和可观测性。在加入 Quick 之前，Steve 负责 AWS Identity 的产品工作，包括 AWS IAM Identity Center 和 AWS Builder ID，并将其从发布扩展到数百万用户。他在为政府客户交付关键任务安全项目方面拥有超过 25 年的经验，并曾在 General Dynamics、Unisys 和 Safran 担任高管职务。