Amazon Quick Adds Four Ways to Automate User-Level Custom Permissions Without Leaving Access Gaps

Amazon Quick now offers four patterns to automate user-level custom permissions for Amazon Quick, despite the different ways enterprises create and manage users. AWS published the guidance on September 9, 2026, as Quick’s expanding AI features made manual permission assignments harder to sustain.

The important change is not another permissions screen. AWS has connected custom permission profiles to four distinct moments in a user’s lifecycle: registration, default assignment, group membership changes, and retrospective remediation.

That creates a useful tension for security teams. Broad defaults provide immediate protection, but they cannot express every business rule. Per-user automation adds precision, yet it introduces event handling, conflict resolution, monitoring, and recovery work.

Microsoft Power BI and Salesforce Tableau face the same general governance pressure as analytics platforms absorb generative AI and workflow features. However, AWS is framing its answer around layered profiles that can follow users across Quick roles and groups.

What Changed in Amazon Quick’s Permission Model

AWS has turned custom permissions into a lifecycle control rather than a profile administrators assign only after onboarding.

Custom permissions let administrators enable or disable specific Quick capabilities for selected users. A financial analyst might create reports while losing the ability to export underlying data. An external partner might view dashboards without receiving sharing controls.

These profiles do not replace identity authentication or ordinary resource authorization. They create another control layer for deciding which product features an authenticated user can access.

The distinction matters as Amazon Quick expands beyond conventional business intelligence. The platform now includes AI-assisted authoring, agents, flows, knowledge bases, connectors, applications, and generative business intelligence capabilities.

A role such as AUTHOR therefore says less about a user’s complete risk profile than it once did. Two authors can hold the same role while requiring very different access to exports, sharing, AI functions, or data connections.

AWS’s new guidance organizes automation around four operational scenarios. The first attaches a profile during API-based registration. The second applies account or role defaults without maintaining separate automation.

The third responds to group membership events with Amazon EventBridge and AWS Lambda. The fourth updates people who already existed before the organization introduced its automated controls.

These approaches are not four interchangeable deployment choices. They cover different points in the identity lifecycle, and mature environments will often combine several of them.

The hierarchy determines how those combinations behave. User-level settings override role-level settings, while role-level settings override the account-level default.

That order gives administrators a restrictive foundation with controlled exceptions. It also creates a governance responsibility because one user-level assignment can supersede protections inherited from broader levels.

The timing is significant. On August 19, AWS also announced deny by default for AI capability categories in custom permission profiles.

That setting blocks newly released AI capabilities for affected users until administrators explicitly allow them. Previously, new capabilities became available at launch, which forced security teams to respond afterward.

The automation guidance completes another part of that control story. Deny by default defines a safer posture for future features. Lifecycle automation determines which people receive each posture and when.

AWS recommends starting with account or role defaults before building conditional event processing. That recommendation exposes the central issue: the safest control is the one active before an exception workflow runs.

Why Account and Role Defaults Carry the Most Security Weight

The simplest pattern closes the largest access gap because it applies before administrators finish classifying each user.

The account-level option uses the UpdateAccountCustomPermission API. It establishes a fallback profile for users without an explicit user or role assignment, including users created through just-in-time provisioning.

Just-in-time provisioning creates an account when a federated user first accesses the service. It reduces manual onboarding, but it can produce a period when group-based business context is still missing.

An account default covers that period. Every unclassified person begins with the organization’s minimum acceptable restrictions instead of inheriting unrestricted access to newly introduced features.

The role-level option uses UpdateRoleCustomPermission. Administrators can set different defaults for readers, authors, administrators, and corresponding professional roles within a namespace.

Role defaults fit organizations whose primary policy distinctions already follow job capabilities. Authors might receive one profile because they create content, while readers receive another because they mainly consume it.

AWS describes a three-level hierarchy across account, role, and user assignments. The administrator configuration documentation confirms that user-level profiles take precedence over broader defaults.

This hierarchy separates baseline governance from exceptions. Security teams can restrict a capability across the account, refine the policy for a role, and grant a specific user another profile.

The same structure also limits operational complexity. An enterprise does not need a Lambda function for a rule that applies uniformly to every author or every account user.

Defaults are particularly relevant when security review moves more slowly than product delivery. A company can block a new AI category immediately, evaluate it, and permit selected capabilities after approval.

AWS gives the example of an enterprise reviewing new generative business intelligence features and connectors for 60 to 90 days. The figures illustrate a policy window, not a service requirement.

The underlying point remains sound without the example’s scale. Feature release dates rarely align with an organization’s privacy assessment, vendor review, or internal change process.

Broad defaults therefore pressure security teams in a productive direction. They must define a minimum posture before they design exceptions, instead of treating each new user as an isolated ticket.

They also pressure product owners who want faster access. Those owners need a repeatable approval path because the default now favors restriction during uncertainty.

However, defaults cannot identify every business context. Two authors in separate divisions can share the same Quick role while facing different requirements for exports, asset sharing, and AI tools.

That is where broad protection reaches its limit. Once policy depends on department, customer entitlement, geography, or approval status, administrators need a more precise signal.

How to Automate User-Level Custom Permissions for Amazon Quick

The four patterns form a control sequence: assign early, default safely, react to context, and repair historical coverage.

The most direct pattern applies when an organization controls user creation through a custom portal or provisioning script. The RegisterUser request accepts a CustomPermissionsName value during account creation.

The AWS CLI exposes that value through the --custom-permissions-name parameter. This places the intended profile on the user without waiting for another event or scheduled reconciliation.

The pattern fits embedded analytics providers and other software services that already know a customer’s entitlement during registration. A service can map that entitlement to an established permission profile.

For example, a provider might restrict paginated reporting or generative features for users whose customer agreement excludes them. The decision happens inside the existing provisioning path.

This approach has the smallest moving surface because it requires no EventBridge rule or Lambda function. Its weakness is equally clear: it works only when the organization controls registration end to end.

Federated onboarding complicates that assumption. The identity system can create the Quick user before the organization has resolved department, group, or policy attributes.

Account and role defaults handle that uncertainty by setting the baseline. They require less custom infrastructure and cover both existing and future users who lack a higher-priority assignment.

Conditional rules require the third pattern. AWS’s design watches group membership activity captured by AWS CloudTrail, routes matching events through EventBridge, and invokes Lambda.

For native Quick groups, CloudTrail records CreateGroupMembership when someone joins and DeleteGroupMembership when someone leaves. IAM Identity Center uses AddMemberToGroup and RemoveMemberFromGroup.

EventBridge filters those records. Lambda extracts the account, namespace, user, action, and target group before calling the relevant Quick API.

When a membership addition matches the configured group, Lambda calls UpdateUserCustomPermission. The user permission API accepts one custom permissions profile name for that user.

When the person leaves the monitored group, Lambda calls DeleteUserCustomPermission. Removing the explicit assignment returns the user to the applicable role or account default.

That removal behavior is critical. An automation that only grants or restricts access during additions will accumulate stale assignments as employees change teams.

AWS supplies a CloudFormation template for the event-driven architecture. The stack includes the EventBridge rule, Lambda function, execution role, and required policy resources.

The stack must run in the same AWS Region as the Quick subscription. EventBridge captures the relevant service events within its configured Region, so a mismatched deployment can miss the expected activity.

Each deployment targets either one native Quick group or one IAM Identity Center group. Monitoring both group sources requires separate stacks under the published design.

The permission profile must already exist. The automation assigns profiles, but it does not define their capability settings or decide the organization’s policy.

The fourth pattern addresses people who joined before event-driven automation existed. Future membership events cannot remediate a user whose relevant group assignment happened months earlier.

AWS provides a Python batch approach that calls ListGroupMemberships, iterates through the returned users, and applies UpdateUserCustomPermission to each one.

Pagination is the easily missed detail. ListGroupMemberships returns no more than 100 members per response, so the script must continue with NextToken.

Without that loop, a team could report a successful migration while leaving every member after the first page unchanged. Large groups make that failure both plausible and difficult to notice.

The example script records failed updates in a CSV file for follow-up. Administrators can also call DescribeUser and inspect CustomPermissionsName to verify an individual assignment.

Together, these patterns automate user-level custom permissions for Amazon Quick without pretending every organization has the same identity architecture. The correct mix depends on when reliable policy context becomes available.

Group-Based Precision Introduces a New Control Problem

Event-driven permissions remove repetitive work, but they shift risk into event delivery, group quality, and conflict resolution.

AWS’s group-based design is the most flexible pattern because it can apply different profiles to users who share the same Quick role. That flexibility also carries the greatest operational burden.

CloudTrail must capture the expected events in the correct Region. EventBridge rules must match the actual event structure. Lambda needs adequate permissions, error handling, logging, and retry behavior.

The execution role should follow least privilege itself. AWS lists Quick actions for updating, deleting, describing, and managing user assignments, plus Identity Store reads when Identity Center integration is involved.

Service authorization matters because the automation can change user capabilities across an account. The Quick authorization reference classifies UpdateUserCustomPermission as a write action against user resources.

That makes Lambda a privileged policy enforcement component, not merely integration glue. Teams should review changes to its code and execution role as carefully as other access-control infrastructure.

Group accuracy presents another risk. An event-driven system faithfully applies the policy mapped to a group, even when the underlying membership is wrong.

A stale department group can therefore produce a technically successful but organizationally incorrect assignment. Automation reduces manual execution errors without guaranteeing correct source data.

Multiple group memberships create the sharpest unresolved issue. Quick supports one custom permissions profile per user, while a person can belong to several groups with different intended profiles.

The AWS example does not implement automatic conflict resolution for that case. Organizations must decide which profile wins and encode that choice in their Lambda logic.

A most-restrictive-wins strategy aligns with least privilege, but it can block legitimate work. A priority list is more flexible, yet it requires an owner and a documented exception process.

The hierarchy adds another consideration. A group-triggered user profile overrides role and account defaults, even when the explicit profile is less restrictive than the inherited baseline.

Teams should therefore treat user-level profiles as complete policy outcomes. They should not assume the account default continues protecting capabilities omitted from an exception design.

AWS’s event pattern is also reactive. A new federated user can exist before an administrator adds that person to the appropriate group.

AWS explicitly recommends using a restrictive account or role default to cover this provisioning window. The later group event then refines the user’s permissions.

This relationship makes defaults and events complementary. The default protects the unknown state, while group automation applies known context after classification.

Organizations should monitor failed Lambda invocations, unmatched events, and unexpected permission changes. CloudWatch alarms can identify execution failures, but teams also need business-level reconciliation.

A periodic comparison between authoritative groups and assigned profiles provides that second check. It can detect missed events, manual overrides, renamed groups, and profiles changed outside the expected workflow.

Batch scripts can support this reconciliation, although AWS presents its script primarily for initial remediation. The same pagination and verification principles apply to recurring audits.

There is also no third-party evidence yet showing how these patterns perform across complex production environments. The guidance is new, and its largest scale figures appear as illustrative scenarios.

That does not invalidate the architecture. It means buyers should validate delivery latency, API throttling, retry behavior, and conflict rules under their own identity traffic.

What Security Teams Should Watch Next

The next test is whether organizations can turn these components into an auditable policy system rather than a collection of scripts.

The first signal is adoption of restrictive account defaults alongside group automation. Deployments that use only membership events retain a window before classification.

Wider use of deny by default would strengthen AWS’s lifecycle model. It would show that enterprises want new AI capabilities held for review instead of released automatically.

The second signal is native support for group-level custom permission assignments. AWS says there is no direct API that assigns a custom permission profile to a group.

That gap explains the CloudTrail, EventBridge, and Lambda architecture. Native group assignment would remove infrastructure while giving administrators a clearer place to define precedence.

Such a feature would also need conflict semantics. AWS would have to explain what happens when one person belongs to groups mapped to different profiles.

If native support arrives without deterministic precedence, it will move the problem rather than solve it. If AWS adds explicit priority rules, the event-driven workaround will become less necessary.

The third signal is evidence from real deployments. Teams should look for published data covering assignment latency, failure recovery, API limits, and reconciliation across large identity populations.

The current guidance includes examples involving 50,000, 125,000, and more than 200,000 users. AWS presents these as scenarios that explain design requirements, not measured customer results.

Production evidence would either strengthen or weaken the case for this architecture. Reliable event processing at enterprise scale would validate its layered design.

Frequent missed events or complicated conflict handling would point organizations toward scheduled reconciliation or centralized identity governance instead.

Administrators implementing the model now should begin with an inventory. They need every custom profile, its owner, affected capabilities, assigned scope, and approved exception path.

They should then establish the most restrictive usable account default. Role-level profiles can refine that baseline where job functions create consistent differences.

Direct registration assignments should remain limited to provisioning systems with dependable entitlement data. Group-based Lambda logic should handle only rules that broad defaults cannot express.

Existing users need a complete batch pass before teams trust future events. The migration should record success, preserve failures, and verify assignments after pagination completes.

Administrators should also test removal, not only addition. A user who leaves a group must revert to the intended account or role profile without retaining an obsolete override.

The broader lesson reaches beyond Amazon Quick. AI features increase the number of capabilities hidden inside familiar roles, making static role names less informative over time.

Product teams want new tools available quickly. Security teams need time to evaluate data movement, sharing behavior, model access, and connector permissions.

Amazon Quick’s answer is layered enforcement rather than a single policy mechanism. Broad defaults establish safety, while registration and group events add user-specific context.

For teams that document these decisions, a searchable technical knowledge base can connect profile definitions, approval records, incident notes, and operating procedures.

The practical next step is to test one restrictive profile against a controlled group. Verify registration, addition, removal, pagination, failure logging, and fallback behavior before expanding coverage.

Can your current process explain exactly which profile every Quick user receives, why that profile wins, and what happens when the automation fails? If not, use the four patterns as a control map. Start with the baseline, close the historical gap, and add event-driven exceptions only where business context truly requires them.