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.
Figure 1: Policy determines eligibility. Smart Approvals approves eligible actions or returns them to the user for review. Policy denials remain blocked
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.
