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

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

从哪里开始

由于 Smart Approvals 默认开启，请先确认需要人工审批的操作已通过连接器操作权限进行配置。设置 CloudTrail 跟踪，并将聊天日志和代理元数据日志投递到 CloudWatch Logs，以支持调查。聊天日志仅记录配置投递之后的活动，因此此前的审批将缺少该对话上下文。在审批要求和日志记录就位后，使用自定义权限将 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 担任高管职务。