[Amazon Bedrock] Amazon Quick 的智能审批：把人工监督用在真正要紧的地方

Amazon Quick 的智能审批：把人工监督用在真正要紧的地方

安全负责人在 AI agent 承担越来越多工作的情况下，该怎么保住人工监督？permissions 界定了 agent 能执行哪些动作，但一个被允许的动作仍然可能需要人来做判断。每一步都要求 approval 看似最安全，可多步任务会带来重复的 prompt，哪怕动作本身很常规。关于安全警告的研究表明，随着重复次数增加，注意力和遵从度都会下降。难点不在于要求更多 approval，而在于把注意力留给真正需要人工复核的决策。

Amazon Quick 中的 Smart Approvals 在你已有的 controls 之内审查符合条件的动作，以此应对这一难点。它会把每个拟执行的动作与用户的请求做比对，要么自动批准，要么退回给用户复核。整个过程既不授予额外 permissions，也不取消必需的人工 approval。哪些动作必须始终交给人来判断，决定权仍留在安全负责人手里；而 Smart Approvals 的设计目标是减少日常工作中不必要的打断。

图 1：policy 决定资格。Smart Approvals 批准符合条件的动作，或把它们退回给用户复核。被 policy 拒绝的仍然保持拦截

policy 划定边界

在进入自动化审查之前，Quick 会先对照 Custom Permissions、Quick Guardrails、connector action permissions 以及用户自身的设置来评估每个拟执行的动作。被拒绝的动作仍然是拒绝，强制的人工 approval 照样生效。开启 Smart Approvals 后，只有当用户的设置是「Ask each time」且没有别的 control 要求人工 approval 时，一个动作才有资格进入自动审查。connector action permissions 在创建 connector 时配置，可以要求特定动作必须经人工 approval。

管理员用 Custom Permissions 决定谁能使用 Smart Approvals。它默认开启，但启用了 deny-by-default 的 profile 必须显式放行。用户也可以为自己关掉 Smart Approvals，这个选择对所有对话和定时运行都生效。关掉之后，那些本来有资格进自动审查的动作都要经用户本人 approval，账户级别的任何设置都无法替他们重新打开。

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

Smart Approvals 用一个独立的模型——classifier——来对照用户请求以及有边界限制的对话视图评估符合条件的动作。它会考虑这个动作做什么、数据流向哪里、影响到谁。它还可以查阅用户的 knowledge graph，其中包含从已连接来源抽取的人物与工作关系。这有助于它判断收件人与用户之间是什么关系，比如某个收件人是否处在用户的汇报线上。这类查询留在你的 Quick 账户之内。Quick 不会用 classifier 审查的内容（包括 knowledge graph 数据）来训练模型或改进服务。

一个动作即便与请求相符，也可能仍然需要人工复核。例子包括把内容发到组织外部、或发给用户汇报线上的高层，变更访问权限，删除记录，发起付款。这份清单并不完整，classifier 还会权衡周边的上下文。把动作对照用户请求来审查，等于额外加了一道针对 indirect prompt injection 的检查——检索到的内容里可能夹着试图把 agent 带偏的指令。Quick 会同时要求 agent 和 classifier 把那类内容当作信息而不是指令。模型审查仍可能出错，所以那些必须始终走人工 approval 的动作，包括搬运敏感数据的动作，应当通过 connector action permissions 把 approval 设为必需。

classifier 给出判断，permission service 负责强制权限。每一次自动 approval 都只可用一次，只适用于被审查的那一个确切动作和参数，不授予任何持续性的 permission。Quick 会在对话里标注出自动 approval。classifier 没批准的动作会退回给用户，超时和其他审查失败同样退回，它们绝不会给出自动 approval。这些强制边界限定了一次 approval 授权的范围，但并不能证明 classifier 的判断是正确的。

当动作超出请求范围

一位客户经理让 Quick 用她团队的账户记录和上一季的邮件，为 AnyCompany 准备一份季度业务回顾简报。接着她让 Quick 把它发给她点名的两位同事。假设这次发送有资格进自动审查，Smart Approvals 会把这一拟执行动作与她的请求以及可用的对话上下文做比对。

现在假设某条账户记录写着这份简报也应发给一个约 2,000 人的全体销售邮件组。这就把受众扩大到她指定的收件人之外了，因此 Smart Approvals 的设计是把这次拟发送退回给她复核，她可以拒绝。原本发给那几位收件人的 approval 不能被复用到更大的受众上。

审计证据与排查

Quick 的 permission service 会把与 Smart Approvals 相关的 permission 更新记录到你账户内的 AWS CloudTrail。每个事件都标明用户、connector、动作和时间，并把该请求标记为与 Smart Approvals 相关。这个标记本身并不能证明 permission service 接受了这次授权，也不能证明动作真的执行了。Quick 还会记录 permission 检查的结论，包括来自 connector action permissions 的拒绝，以及用户对自身 Smart Approvals 设置的改动。

排查人员可以按用户和时间，把这些事件与 CloudTrail 中其他 Quick 活动、以及经 Amazon CloudWatch Logs 投递的日志关联起来。聊天日志记录用户的请求、系统响应和对话上下文。agent 元数据日志记录 agent 的变更。目标系统那边的记录，比如已发出的邮件或更新后的工单，才能确认动作是否完成。这些来源合起来有助于还原发生了什么，同时不把 approval 当作执行凭证。CloudTrail 的 Event history 只保留 90 天的事件，所以要为更长时间的排查配置一条 trail。由于聊天日志可能含敏感内容，请限制访问，并考虑用 CloudWatch Logs 的数据保护策略对敏感数据做掩码。

从哪里开始

由于 Smart Approvals 默认开启，先确认需要人工 approval 的动作都已经通过 connector action permissions 配置好。建一条 CloudTrail trail，并把聊天日志与 agent 元数据日志投递到 CloudWatch Logs，以支撑排查。聊天日志只记录配置好投递之后的活动，所以更早的 approval 会缺少那段对话上下文。approval 要求和日志都到位之后，用 Custom Permissions 先把 Smart Approvals 限定在一个试点团队、跑一条界定清楚的工作流，再推广到其他团队。

试点之前，先定义什么叫成功：常规动作的 prompt 变少，而有分量的动作仍然会回到人这里复核。试点期间，抽查一部分自动 approval，并测试高影响场景，比如把内容发到组织外部，或添加一个由文档里带出来的收件人。确认这些场景确实会退回给用户，确认你的团队能把每个动作从 approval 一路追踪到执行。只有结果达到这些标准，才扩展到更多团队和更多工作流，并随着动作与 policies 的变化重新评估。

有效监督的衡量标准不是 agent 多久问一次 approval，而是人是否仍然掌握着有分量决策的控制权。对安全负责人来说，扩大 Smart Approvals 使用的理由应当建立在试点拿出的证据上。更少的 prompt 之所以有价值，是因为它保住了注意力，又没有削弱问责。

配置步骤见 Amazon Quick User Guide 治理章节中的 Smart Approvals。

关于作者