Amazon Quick shipped deny by default to 26 regions on 19 August 2026, but only 8 run the AI capabilities it governs

Summary. On 19 August 2026 AWS announced deny by default for Amazon Quick custom permissions, a setting that blocks new AI capabilities on launch day instead of releasing them to every user. The announcement says it is "available in all AWS Regions where Amazon Quick is available." Quick's own region table lists 26 regions and marks exactly 8 of them Yes under Agentic Features: us-east-1, us-west-2, ap-southeast-2, ap-northeast-1, eu-central-1, eu-west-1, eu-west-2 and gov-west-1. The only supported capability category at launch is AI. Asia Pacific (Mumbai) at ap-south-1 is marked No, as are Ohio, Singapore, Seoul, Paris, Zurich and 13 others. Three other Quick governance launches from the same week scope themselves differently again, and 1 of them to just 6 regions. The gap between those 3 footprints is the thing to check before you write this into a policy document.

What shipped

The setting lives inside a custom permissions profile. AWS describes the problem it solves plainly: "Without Deny by Default, any new capability that Amazon Quick ships is automatically available to all users upon release. Administrators must manually restrict each new capability after every release" (Deny by Default, Amazon Quick User Guide).

With it on, restricting a category denies every capability in that category for assigned users, present and future, unless a capability is explicitly allowed. The API field is DefaultCategoryEffects, and the documented value is DENY_BY_DEFAULT. Omit the field and the behaviour reverts to allow by default. Evaluation runs User over Role over Account, with the most specific level winning (AWS What's New, 19 August 2026).

For a bank with a model risk management policy, that is the control they have been asking for. AWS names exactly that audience, along with healthcare organisations and enterprises running controlled rollouts.

The trap in the second paragraph

The announcement's phrasing, "Restricting a category also restricts existing capabilities in it," is accurate and easy to skim past. The user guide spells out what it means for a profile that is already in production: "If you enable it on an existing profile, all capabilities in that category become restricted, including capabilities the profile previously allowed. Allow the ones your users need."

So turning deny by default on for a live profile revokes AI capabilities your users already had, including ones a previous administrator deliberately allowed. AWS puts an Important callout at the top of the page telling you to "Test Deny by Default configurations in a development or staging account before applying them to production users." That callout exists for a reason.

The second half of the same rule cuts the other way. Restricting a category "affects only the profile you configure it in. Existing custom permissions profiles do not inherit the restriction." If your account has 6 profiles and you enable the setting on 1, the other 5 keep receiving every new AI capability on launch day. Deny by default is not an account-wide switch, and a compliance attestation written as though it were will be wrong.

Three region footprints, one product

Amazon Quick's governance features shipped across a single fortnight in August 2026, and the availability language differs on every one of them.

Sources: AWS What's New entries dated 14, 17 and 19 August 2026.

The 6 named regions for the Microsoft 365 extensions are US East (N. Virginia), US West (Oregon), Asia Pacific (Sydney), Europe (Ireland), Asia Pacific (Tokyo) and Europe (Frankfurt) (AWS What's New, 17 August 2026). Europe (London) and GovCloud (US-West) carry agentic features in the region table but are absent from that list, so the extensions footprint is narrower than the agentic footprint, which is in turn narrower than the Quick footprint.

Here is the region table itself, filtered to the ones that matter for the decision.

Source: AWS Regions for Amazon Quick, retrieved 22 August 2026. The full table lists 26 regions, 8 marked Yes.

Read the two documents together and the practical position is this: in the 18 regions marked No, you can enable a governance control over a capability category that has no agentic capabilities in it. That is not harmful. It is also not the control your risk committee thinks it bought.

What this means for Indian deployments

Mumbai is marked No. Hyderabad does not appear in the Quick region table at all. An Indian enterprise that keeps analytics workloads in ap-south-1 for DPDP reasons cannot use Quick's agentic capabilities there today, which means the Purview data loss prevention integration, the sharing approval policies and the per-user limit profiles are all out of reach as well, since three of those explicitly scope to agentic regions.

The choice is the familiar one. Either run Quick agentic features in a region that supports them and accept that the processing sits outside India, or keep Quick in Mumbai as conventional BI and govern AI capability adoption somewhere else in the stack. Neither is wrong. Both need writing down before an audit asks. The same storage-versus-processing split is showing up across AI vendors this month, including OpenAI's per-request regional processing, where 7 of 10 residency regions store locally but infer elsewhere.

Teams migrating off Amazon Q Business should read this alongside the access-control gaps we documented in Q Business to Amazon Quick migration ACL gaps, because a migration that lands in a non-agentic region inherits a different feature set than the source account had. The broader compliance framing is in the DPDP engineering playbook.

How to check your own account in under an hour

Start with the region. Confirm which region your Quick account runs in and look it up in the region table. If Agentic Features says No, deny by default is available but the AI category is empty, and the DLP, approval policy and limit profile launches from 14 August are unavailable.

Then count your profiles. ListCustomPermissions and ListCustomPermissionAssignments will tell you how many custom permissions profiles exist and who is assigned to each. Every profile without DENY_BY_DEFAULT on the AI category still receives new AI capabilities automatically. Administering this needs a Quick administrator holding the full set of quicksight: permissions listed in the user guide, including CreateCustomPermissions, UpdateCustomPermissions and the account, role and user assignment operations. Note the naming: all API operations still use Amazon QuickSight conventions and permission strings still carry the quicksight: prefix, so an IAM policy written against Quick branding will not attach to anything.

Check your identity integration next. The prerequisites require the account to be integrated with IAM Identity Center, Active Directory, or configured with Quick managed users. An account outside those three cannot assign profiles at role level, which removes the middle tier of the precedence hierarchy.

Finally, check the plan. Approval policies and per-user resource limits are Professional and Enterprise only (approval policies, per-user limits). Deny by default carries no such plan restriction in its announcement, so a Standard-plan account may end up with the AI kill switch and none of the sharing or cost controls that surround it.

What is still unknown

AWS has not published a date for agentic features in ap-south-1 or any of the other 18 regions marked No. The user guide states that AI is the supported category "at launch," which implies more categories later but names none and gives no schedule. Nor does either document say what happens to a profile with DENY_BY_DEFAULT set on the AI category if that account's region later gains agentic features, though the documented behaviour, current and future capabilities denied unless explicitly allowed, suggests the control activates rather than needing to be re-applied. Treat that as a reasonable reading, not a commitment.

One small documentation defect worth flagging to your AWS account team: the 14 August approval policies announcement links its "Approval policies in the Amazon Quick User Guide" reference to the data loss prevention page rather than an approval policies page. If you are collecting evidence for an audit trail, cite the announcement text rather than following that link.

FAQ

How eCorpIT can help

Governance controls that ship faster than the capabilities they govern are a recurring pattern, and the cost lands on whoever has to explain the gap to an auditor. Our teams map which Quick features your region actually supports, model the permissions profiles against the precedence hierarchy before anything is enabled in production, and write the control description so it matches runtime behaviour rather than the launch note. That work sits alongside our generative BI and Quick Suite migration practice. Start a conversation at /contact-us/.

References

1. Amazon Quick adds deny by default for custom permissions — AWS What's New, 19 August 2026.

1. Deny by Default, Amazon Quick User Guide — key concepts, prerequisites, evaluation order and DefaultCategoryEffects.

1. AWS Regions, websites, IP address ranges, and endpoints for Amazon Quick — 26-region table with the Agentic Features column.

1. Amazon Quick now supports data loss prevention with Microsoft Purview — AWS What's New, 14 August 2026.

1. Amazon Quick now supports approval policies for sharing — AWS What's New, 14 August 2026.

1. Amazon Quick now supports per-user resource limits — AWS What's New, 14 August 2026.

1. Amazon Quick Microsoft 365 extensions are now generally available — AWS What's New, 17 August 2026, with the 6 supported regions.

1. Amazon Quick now supports approval policies, User Guide reference — the page the 14 August announcement links to.

1. Data controls in the OpenAI platform — comparison point for the storage versus processing split.

1. OpenAI API changelog — 21 August 2026 per-request regional processing entry.

Last updated: 22 August 2026.