Amazon Quick can deny future AI features—but profile precedence decides who is covered

Amazon Quick can now keep newly released AI capabilities unavailable until an administrator explicitly approves them. The August 19 change replaces a reactive pattern—new features reaching users before restriction—with a category-level default that covers current and future AI capabilities for users assigned to a configured custom permissions profile.

That protection is narrower, and more operationally consequential, than an account-wide off switch. Enabling it also restricts existing AI capabilities in the profile, existing profiles do not inherit it, and a more-specific user or role assignment can determine the effective result. This article explains how the control resolves and how to migrate one user population without accidentally widening or removing access.

What does Deny by Default change?

AWS’s August 19 announcement says new Amazon Quick AI capabilities were previously available to users when released. Administrators who required prior review had to restrict each feature after launch. Deny by Default lets an administrator restrict a capability category inside a custom permissions profile, so capabilities added to that category later are denied for users governed by the profile.

The current Amazon Quick User Guide documents one supported category at launch: AI. AWS says it covers all AI and LLM-powered capabilities in Quick, including chat agents, flows, spaces, knowledge bases, app AI inference, Q analyses, and Quick desktop AI features.

Inside a restricted category, an explicit ALLOW makes only that named capability available. An explicit DENY blocks the named capability. A capability that is neither listed nor part of a restricted category keeps the existing allow-by-default behavior.

The important boundary is therefore category membership. The setting does not freeze the product or require an administrator to update a list on every release. Quick evaluates a capability’s category when the user accesses it, allowing a later AI capability to inherit the restricted default.

Why does enabling the control change current access?

Deny by Default applies to the whole selected category, not just features released after configuration. AWS states that restricting AI also restricts the AI capabilities that already exist in the profile. Administrators must explicitly allow the existing capabilities that assigned users should retain.

That makes adoption a permissions migration. If a team turns on the category restriction and saves without recreating the intended allows, users may lose current chat, flow, space, knowledge-base, or other AI access. Conversely, leaving an existing profile untouched means it does not gain the new default at all.

BaristaLabs interpretation: inventory effective access before editing the profile, then write the intended post-change state rather than treating the toggle as an additive safeguard. The migration record should name which existing capabilities remain available and why, not merely say that Deny by Default is enabled.

Which profile wins for a user?

Quick custom permissions can be assigned at account, role, or user level. AWS documents the resolution order as user first, then role, then account: the most specific matching assignment takes precedence. The guide gives a consequential example—a user with a user-level allow-by-default profile is not governed by an account-level Deny by Default profile.

This means account assignment alone is not evidence that every account user receives the restricted category. A role-level profile can determine the result for members of that role, while a user-level profile can determine it for one person. The effective population is the set of users after those assignments resolve, not the audience named in the broadest profile.

Before rollout, build a small assignment table with one row per test user. Record the account profile, any role profile, any user profile, the expected winning assignment, and the expected result for each representative capability. Include users with no override, a role override, and a user override; otherwise the test proves only the simplest path.

How should teams verify the migration?

AWS recommends testing Deny by Default in a development or staging account before applying it broadly to production users. Start with a copy of the intended capability state and a small population that represents the assignment patterns used in production.

Test a capability that should remain allowed, an existing capability that should be denied, and a newly introduced or otherwise unlisted AI capability that should inherit the category restriction. For each case, preserve the user, account, role and user profile assignments, expected winning profile, capability, expected result, actual result, and time.

The negative case matters as much as the positive one. Seeing an allowed chat agent work establishes that its explicit allow survived; it does not establish that unapproved AI capabilities are blocked. Likewise, one denied user does not establish coverage for a colleague with a more-specific profile.

Treat removal of the setting as another permission change. AWS says turning off the category restriction makes previously denied capabilities available to assigned users. Rollback can therefore restore access more broadly than intended unless explicit capability settings and assignment precedence are reviewed at the same time.

What changes when the profile is managed through the CLI?

AWS exposes DefaultCategoryEffects through the QuickSight-named custom-permissions API. The documented value for this control is DENY_BY_DEFAULT, and the example pairs it with explicit capability allows.

The operational warning is more important than the syntax: UpdateCustomPermissions performs a full replacement. AWS says the request must include all capability and governance values, not only the intended delta. Anything omitted is removed from the profile.

A safe automation path should therefore read and preserve the complete desired profile, review the resulting diff, apply it first to staging, and describe the profile again after the update. Sending only the new governance field can erase capability settings; sending only capability changes later can erase governance. This is configuration replacement, not a patch API.

What does the feature not establish?

The public sources document intended evaluation behavior, configuration, and precedence. They do not provide independent enforcement testing, propagation timing, audit-event details, or proof that a particular customer’s assignments produce the expected result. No authenticated Quick account was used for this source review, so console behavior and API responses were not exercised here.

Deny by Default is also not a complete AI approval program. It can hold capabilities in a category at the permission layer. It does not decide whether an approved capability is appropriate for a workflow, whether its data sources and actions are correctly scoped, or whether outputs receive the required review. Our Amazon Quick GovCloud boundary analysis covers those separate workflow dependencies.

Move one effective population, not the whole account on paper

Use the new control when the business requires explicit review before Amazon Quick AI features reach a controlled population. Begin with one profile and the users it actually governs after account, role, and user precedence resolves. Preserve required current access with explicit allows, test both permitted and denied cases, then expand assignment only when the effective results match the record.

That approach turns the launch-day default into an enforceable operating posture without overstating its scope. BaristaLabs helps teams map profile assignments, capability baselines, and positive and negative checks through process automation. If one Quick population needs a controlled migration, bring the profile and assignment model to a focused review.

Sources

• AWS What’s New: “Amazon Quick adds deny by default for custom permissions”, published August 19, 2026.
• Amazon Quick User Guide: “Deny by Default”, accessed August 20, 2026.