正文 · AI 翻译
随着 AI 智能体承担更多工作，安全负责人应如何保留人的监督？权限规定了智能体可以执行哪些操作，但即使操作获得许可，仍可能需要由人作出判断。要求每一步都经过批准似乎是最安全的做法，但多步骤任务可能反复弹出批准请求，即使是例行操作也不例外。有关安全警告的研究表明，重复出现的提示会使注意力和遵从程度下降。难点不在于要求更多批准，而在于让人们把注意力留给需要人工审查的决定。Amazon Quick 中的 Smart Approvals 通过在现有控制措施范围内审查符合条件的操作来应对这一挑战。它根据用户的请求评估每项拟议操作，或自动批准，或交还用户审查。它不会授予额外权限，也不会取消必需的人工批准。安全负责人仍可控制哪些操作必须始终交由人审查，而 Smart Approvals 旨在减少例行工作中不必要的中断。图 1：策略决定操作是否符合条件。Smart Approvals 批准符合条件的操作，或将其交还用户审查。策略拒绝的操作仍被阻止。策略划定边界。在自动审查之前，Quick 会根据 Custom Permissions、Quick Guardrails、连接器操作权限以及用户设置评估每项拟议操作。被拒绝的操作仍会被拒绝，强制性人工批准要求仍然适用。启用 Smart Approvals 后，只有当用户设置为“Ask each time”，且没有其他控制措施要求人工批准时，操作才符合条件。创建连接器时配置的连接器操作权限可以要求特定操作经过人工批准。管理员使用 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，以支持调查。聊天日志只会记录配置日志传送之后的活动，因此较早的批准将缺少相应的对话上下文。批准要求和日志记录到位后，使用 Custom Permissions 将 Smart Approvals 限定于执行特定工作流程的试点团队，再扩展到其他团队。试点开始前，先明确成功标准：例行操作的批准提示减少，同时有重大影响的操作仍交由人审查。试点期间，抽样检查自动批准，并测试影响较大的情形，例如向组织外部发送内容，或添加文档中提及的收件人。确认这些情形会交还用户审查。确认团队能够追踪每项操作从批准到执行的全过程。只有结果符合这些标准时，才扩展到更多团队和工作流程，并在操作和策略变化时重新评估。有效监督的衡量标准不是智能体请求批准的频率，而是人能否继续掌控有重大影响的决定。对安全负责人而言，扩大 Smart Approvals 使用范围的依据应来自试点证据。只要能在不削弱问责的情况下保持人们的注意力，减少提示就有价值。有关设置步骤，请参阅《Amazon Quick User Guide》治理部分的“Smart Approvals”。关于作者：Steve Vinsik。Steve 是 AWS 的首席产品经理，负责 Amazon Quick 的治理、身份和安全工作。他直接与企业首席信息官和首席信息安全官合作，确定其组织大规模采用 AI 智能体所需的控制措施，例如访问权限、防护机制、模型管理、数据丢失防护和可观测性。在加入 Quick 之前，Steve 负责 AWS Identity 的产品工作，包括 AWS IAM Identity Center 和 AWS Builder ID，并推动这些产品从发布发展到拥有数百万用户。他拥有超过 25 年为政府客户交付关键安全项目的经验，曾在 General Dynamics、Unisys 和 Safran 担任高管。