Amazon快速智能审批：在其中重要的人类监督

人工智能

Amazon快速智能审批：在其中重要的人类监督

当AI agents承担更多工作时，安全领导人应如何维护人类监督？许可可以确定agents可以采取什么行动，但允许的行动仍然可以使一个人做出判决。 每一个步骤都需要得到批准，这似乎是最安全的办法，但多步骤的任务可以产生重复的提示，即使是例行行动。 对安全警告显示的研究认为，注意力和坚持度会随着重复而下降。 挑战并不在于需要更多的批准

Amazon快速的智能审批通过审查您现有控制范围内的合格行动来解决这一挑战。 它根据用户的要求评价每项拟议行动，或自动批准，或退回用户审查。 它这样做时没有给予额外许可或取消必要的人类批准。 安保领导人仍然控制着哪些行动必须总是由个人承担，而智能核准则旨在减少日常工作中不必要的中断。

政策设定边界

快速评价每一个针对自定义权限，快速护栏，连接器动作权限，以及用户在自动审查前的设置的拟议行动。 被拒绝的行动仍然遭到拒绝，强制性的人类批准仍然适用。 只有在用户的设定是 " 每次询问 " 时，连接器动作权限，在创建连接器时配置，可以要求人类对具体行动的批准。

管理员使用自定义权限来确定谁可以使用智能核准。 默认情况下，用户也可以自行关闭智能核准。 这一选择适用于对话以及预定的运行。 关闭时，符合自动审查条件的动作需要用户批准，任何账户级别设置都无法恢复。

合格行动如何得到审查

Smart Authoritys使用一个单独的模型，即分类器，来评价符合要求的行动，以响应用户的要求，并对对话进行限定的视图。 它考虑了行动的作用、数据流向和对谁的影响。 它可以参考用户的知识图，其中包含从相关来源抽取的人员和工作关系。 这有助于它了解收件人与用户的关系，例如收件人是否在用户的报告链中。 查一下你的账户里包括知识图表数据在内的分类审查内容

一项行动可以与请求相匹配，仍然值得进行人文审查。 例子包括将内容发送到组织之外或发送给用户报告链中的高级领导，改变访问、删除记录或启动付款。 这个列表并不完整，分类者也会权衡周围的背景。 对照用户的要求审查行动新增对照间接的提示词注入检查，其中检索内容中的指令试图重定向 agent. 快速指示agent和分类器将该内容视为信息，而不是指令。 模型审查仍然可以犯错误，因此必须总是得到人类批准的行动，包括移动敏感数据的行动，应该通过连接器动作许可来要求。

分类员提供判断。 许可服务执行权限。 每项自动批准都是单一用途的，仅适用于所审查的确切行动和参数，不给予持续许可。 快速标注对话中的自动审批。 分类员不批准返回用户的行动，这些执法界限限制了批准授权的内容。 他们不认为分类员的判断正确。

当行动超出请求范围时

一名账户经理要求Quick为Anycompany编写季度业务审查简报，然后，她要求Quick将其发送给她点名的两个同事。 假设寄件符合自动审查的资格，Smart Authoritys会根据她的请求和可用的对话背景评价拟议行动。

现在假设一个帐号称简况也应出现在大约2000人的所有销售名单中。 这会改变听众超出她指定的接受者，因此智能批准的设计将建议寄给她审查，她可以拒绝。 无法为更多读者重新使用。

审计证据和调查

快速许可服务在您的账户中记录与智能批准相关的许可更新 AWS CloudTrail. 每个事件都确定用户，连接器，动作和时间，并标注请求与Smart Records相关。 无法证明许可部门是否接受赠款，Quick还记录了权限检查判决，包括连接器动作权限的拒绝，以及更改用户的智能批准设置。

调查人员可以通过用户和时间将这些事件与CloudTrail的其他快速活动以及通过Amazon Cloud Watch Logs交付的日志联系起来。 聊天日志可以捕捉用户的请求，系统响应和对话上下文。 Agent元数据日志记录了agents的变化。 来自目的地系统的记录，如发送的电子邮件或更新的票，确认动作是否完成。 这些消息来源共同帮助重建了所发生的情况，而没有将批准视为执行的证据。 CloudTrail事件的历史将事件保留了90天，因此为更长的调查设定一条线索。 因为聊天日志可以包含敏感内容，限制访问，并考虑Cloud Watch日志数据保护政策以掩盖敏感数据。

从哪里开始

因为Smart Authoritys是默认的，所以首先确认需要人类批准的行动是通过连接器动作权限来配置的。 建立CloudTrail线索，并将聊天日志和agent元数据日志发送给Cloud Watch日志，以支持调查。 聊天日志只抓取交付配置后的活动，因此更早的批准会缺少对话上下文。 随着批准要求和记录的落实，使用自定义权限，将智能批准限制在根据确定的工作流程开展工作的试点团队，然后扩大到其他团队。

在飞行员之前，定义成功是什么样子：例行行动的提示较少，相应的行动仍然会回到一个人身上进行审查。 在试点期间，对自动审批的样本进行审查，并测试高影响案例，如将内容发送到组织外或者通过文件添加接收方推出。 确认这些案件会回到用户手中。 确认你的团队可以追踪每项行动从批准到执行只有在结果符合这些标准时，才能扩大至更多的团队和工作流程，并随着行动和政策的变化而重新评估。

agent要求批准的次数并不多，对安全领导人员，扩大智能审批范围的案件，应当以飞行员提供的证据为依据。 如果注意而不削弱问责制，那么较少的提示是有价值的。

关于设置步骤，见Amazon快速用户指南的治理部分Smart Advisions.

本文由 AI图鉴自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。

Artificial Intelligence

Smart Approvals in Amazon Quick: Human oversight where it matters

How should security leaders preserve human oversight as AI agents take on more work? Permissions establish which actions agents can take, but a permitted action can still warrant a person’s judgment. Requiring approval for every step might seem like the safest approach, yet multi-step tasks can produce repeated prompts, even for routine actions. Research on security warnings shows that attention and adherence can decline with repetition. The challenge isn’t to require more approvals, but to preserve attention for decisions that need human review.

Smart Approvals in Amazon Quick addresses this challenge by reviewing eligible actions within your existing controls. It evaluates each proposed action against the user’s request and either approves it automatically or returns it to the user for review. It does this without granting additional permissions or removing required human approvals. Security leaders retain control over which actions must always go to a person, while Smart Approvals is designed to reduce unnecessary interruptions in routine work.

Policy sets the boundary

Quick evaluates each proposed action against Custom Permissions, Quick Guardrails, connector action permissions, and the user’s settings before automated review. Denied actions remain denied, and mandatory human approvals still apply. With Smart Approvals enabled, an action is eligible only when the user’s setting is “Ask each time” and no other control requires human approval. Connector action permissions, configured when a connector is created, can require human approval for specific actions.

Administrators use Custom Permissions to determine who can use Smart Approvals. It’s on by default, but profiles with deny-by-default enabled must explicitly allow it. Users can also turn Smart Approvals off for themselves. That choice applies across conversations and scheduled runs. When it’s off, actions otherwise eligible for automated review require the user’s approval, and no account-level setting can turn it back on for them.

How eligible actions are reviewed

Smart Approvals uses a separate model, the classifier, to evaluate eligible actions against the user’s request and a bounded view of the conversation. It considers what the action does, where data goes, and who it affects. It can consult the user’s knowledge graph, which contains people and working relationships drawn from connected sources. This helps it understand how recipients relate to the user, such as whether a recipient is in the user’s reporting chain. This lookup stays within your Quick account. Quick doesn’t use the content the classifier reviews, including knowledge graph data, to train models or improve the service.

An action can match the request and still warrant human review. Examples include sending content outside the organization or to senior leaders in the user’s reporting chain, changing access, deleting records, or initiating payments. This list isn’t complete, and the classifier also weighs the surrounding context. Reviewing actions against the user’s request adds a check against indirect prompt injection, where instructions in retrieved content attempt to redirect the agent. Quick instructs both the agent and classifier to treat that content as information, not instructions. Model review can still make mistakes, so actions that must always receive human approval, including those that move sensitive data, should require it through connector action permissions.

The classifier provides judgment. The permission service enforces authority. Each automatic approval is single-use, applies only to the exact action and parameters reviewed, and grants no ongoing permission. Quick labels automatic approvals in the conversation. Actions the classifier doesn’t approve return to the user, as do timeouts and other review failures, which never grant automatic approval. These enforcement boundaries limit what an approval authorizes. They don’t establish that the classifier’s judgment was correct.

When an action goes beyond the request

An account manager asks Quick to prepare a quarterly business review brief for AnyCompany using her team’s account notes and last quarter’s email. She then asks Quick to send it to two colleagues she names. Assuming the send is eligible for automated review, Smart Approvals evaluates the proposed action against her request and the available conversation context.

Now suppose an account note says the brief should also go to an all-sales distribution list of about 2,000 people. That would change the audience beyond the recipients she specified, so Smart Approvals is designed to return the proposed send to her for review, where she can decline it. An approval to send to the original recipients can’t be reused for the wider audience.

Audit evidence and investigation

The Quick permission service records permission updates associated with Smart Approvals in AWS CloudTrail in your account. Each event identifies the user, connector, action, and time, and marks the request as associated with Smart Approvals. That marker doesn’t establish that the permission service accepted the grant or that the action ran. Quick also records permission-check verdicts, including denials from connector action permissions, and changes to a user’s Smart Approvals setting.

Investigators can correlate these events by user and time with other Quick activity in CloudTrail and logs delivered through Amazon CloudWatch Logs. Chat logs capture the user’s request, system response, and conversation context. Agent metadata logs record changes to agents. Records from the destination system, such as a sent email or updated ticket, confirm whether the action completed. Together, these sources help reconstruct what happened without treating approval as proof of execution. CloudTrail Event history retains events for 90 days, so configure a trail for longer investigations. Because chat logs can contain sensitive content, restrict access and consider CloudWatch Logs data protection policies to mask sensitive data.

Where to start

Because Smart Approvals is on by default, begin by confirming that actions requiring human approval are configured through connector action permissions. Set up a CloudTrail trail and delivery of chat logs and agent metadata logs to CloudWatch Logs to support investigations. Chat logs capture only activity after delivery is configured, so earlier approvals will lack that conversation context. With approval requirements and logging in place, use Custom Permissions to limit Smart Approvals to a pilot team working on a defined workflow before extending it to other teams.

Before the pilot, define what success looks like: fewer prompts for routine actions, with consequential actions still returning to a person for review. During the pilot, review a sample of automatic approvals and test high-impact cases, such as sending content outside the organization or adding a recipient introduced by a document. Confirm that these cases come back to the user. Confirm that your team can trace each action from approval through execution. Expand to more teams and workflows only when the results meet those criteria, and reassess as actions and policies change.

The measure of effective oversight isn’t how often an agent asks for approval, but whether people retain control over consequential decisions. For security leaders, the case for expanding Smart Approvals should rest on evidence from the pilot. Fewer prompts are valuable when they preserve attention without weakening accountability.

For setup steps, see Smart Approvals in the governance section of the Amazon Quick User Guide.

Auto-fetched and translated by AI Atlas. All rights belong to the original author.