Amazon Quick smart approvals: what to keep on Always Ask

Amazon Quick turned on smart approvals for all users on Oct. 28, 2026. A separate classifier model now reviews eligible agent actions, such as sending email or creating tickets, approves the routine ones automatically and sends consequential ones to the user. For Quick administrators, the decision is which actions should never reach the classifier, and whether some teams should have the feature restricted until it has been tested.

The catch is that smart approvals only replaces a prompt the user would otherwise see. It never grants new access, but an action set to "Ask each time" may now run without a click. AWS's own guide says automated review "is not a substitute for policy," and an early hands-on test found behavior that didn't match the documentation.

What are Amazon Quick smart approvals?

Smart approvals is a review layer between an agent's proposed action and the person it acts for. According to the AWS announcement, "a separate review model called the classifier evaluates each eligible action against the user's request." AWS describes the goal as reducing approval fatigue, where people asked to approve every step stop reading the prompts.

The documented rules:

• Each automatic approval covers only the exact action that was reviewed.
• If a review fails or times out, the action goes to the user.
• It is on for all users by default and available in every Region where Quick agentic capabilities are supported.
• The user guide says it works in the Quick desktop and mobile apps, and "is not currently available in the web version."

Which actions does the classifier review?

Only actions where two settings line up. The user guide says smart approvals reviews an action when the connector author set it to Let user choose and the user's own permission for it is Ask each time. Everything else follows its configured setting directly: Always Allow runs without review, and Always Ask goes to the user.

Before that check, Quick applies your existing controls in order: permissions, custom permissions, guardrails, connector action permissions and the user's own settings. Denied actions stay denied. For an eligible action, the classifier compares it with the user's request and the conversation. Low-risk actions consistent with the request are approved and, per the docs, labeled as automatic approvals in the conversation.

AWS lists what counts as consequential and goes to the user:

Scroll sideways to see all 2 columns.

Goes to the user	Can be approved automatically
Sending content outside the organization	Low-risk actions consistent with the user's request
Changing permissions
Deleting or overwriting content
Making a payment
Actions beyond what the user asked for
Any review that fails or times out

The left column is a classifier's judgment, not a rule you configure. That is the reason the guide recommends: "For any action that must always receive human approval, consider requiring review through connector action permission settings rather than relying on automated review."

How do you turn smart approvals off?

Administrators restrict it in a custom permissions profile. In the Quick console, open Manage Quick, then Permissions, then Custom permissions, edit or create a profile, expand AI capabilities under Capabilities & features, and restrict the Smart Approvals feature. Users on that profile then get a prompt for every eligible action.

Users the administrator allows can switch it on or off from the + menu in chat. The guide notes this is a global setting that also covers "actions that your scheduled runs take on your behalf." Turning it off makes scheduled runs wait for review instead of proceeding.

Profile precedence still decides who is actually covered. An earlier post walked through how Quick custom permission profiles and overrides interact when you deny AI features by default.

What an early hands-on test found

One public test didn't match the documentation. A DevelopersIO write-up from Classmethod, published Oct. 30 Japan time, tested the feature in the macOS desktop app with a Gmail connector whose write actions met both eligibility conditions. BaristaLabs did not run this test; the findings below are the author's.

• Creating a draft, creating a label, sending an email to the author's own address and moving it to trash all ran with no prompt. A second send to the same address showed a review card.
• The automatic-approval label the docs describe did not appear.
• With smart approvals switched off, creating a label still ran with no prompt.
• The web version, which has no smart approvals, showed an approval card for the same action.
• The two CloudTrail events the guide documents for smart approvals returned zero results in three Regions 25 or more minutes later, while the connector's action lookups were logged.

The author concluded they could not tell whether the classifier approved those actions or the confirmation step never ran. Treat that as one test on one connector, not a measured failure rate, but it is a good reason to test before relying on the setting.

How do you audit smart approvals?

AWS documents two CloudTrail events, both with the event source quicksight.amazonaws.com. BatchUpdatePreferencesInternal with preferenceKeys set to UseSmartApprovals records a user turning the feature on or off. BatchUpdatePermissionsInternal with approvalSource set to SMART_APPROVALS records an automatic approval, including the connector and action IDs.

Two limits matter. The guide says an approval event "does not confirm that the action ran." The CloudTrail monitoring page adds that the InvokeAction data event, which records connector calls, doesn't include the action's inputs, such as an email recipient, "or any approval decision." To reconstruct what happened, you need both event types, and you should confirm they appear in your account first.

Why it matters for small teams running Quick agents

BaristaLabs' interpretation: smart approvals moves part of your approval policy into a model's judgment. For a small team, that can be a real time saver for internal, reversible actions such as drafting, labeling or creating tickets, where prompts mostly get clicked through anyway. The risk is concentrated in a short list of actions that cost money, reach customers or remove data. If those already sit on Ask each time, they are now eligible for automatic approval, and whether they reach a person depends on the classifier.

Writing the approval policy before choosing the agent still applies here. A classifier's risk call, like a confidence score, is not an approval policy.

Recommended first step

BaristaLabs recommends a short setup pass before Quick agents take on more actions:

1. List the connector actions that must always reach a person: external email, payments, permission changes, deletes. Set those to Always Ask in the connector's action permissions, which takes them out of smart approvals entirely.
2. Restrict smart approvals in the custom permissions profile for teams whose agents run scheduled jobs against customer-facing systems, until step 3 is done.
3. In the desktop app, run three or four test actions with the feature on and off, and confirm both the prompts you see and the CloudTrail events you get.
4. When users get a prompt, have them choose Allow rather than Trust. The DevelopersIO test notes that Trust stops future prompts for that action.

If you want help mapping which Quick actions belong on Always Ask, see AI consulting.

Sources and scope

• AWS What's New, Quick now supports smart approvals for agentic actions, Oct. 28, 2026.
• Amazon Quick User Guide, Smart Approvals, read Oct. 29, 2026.
• Amazon Quick User Guide, Monitoring Amazon Quick using CloudTrail, read Oct. 29, 2026.
• DevelopersIO (Classmethod), hands-on test of Amazon Quick smart approvals, Oct. 30, 2026 (Japan time), in Japanese.

AWS does not publish the classifier's accuracy or the full list of actions it treats as consequential. The hands-on findings come from one third-party test and may reflect an early desktop build. BaristaLabs has not tested the feature for this post.