Amazon Quick’s permission automation starts with defaults—not Lambda

Amazon Quick’s newest governance guide makes a useful distinction for teams rolling AI-powered analytics out broadly: identity automation is not enough if a newly provisioned user can briefly inherit permissions that are too broad.

AWS lays out four ways to assign custom permissions across the user lifecycle: attach a profile during RegisterUser; set an account- or role-level default; react to group membership changes with CloudTrail, EventBridge and Lambda; and batch-update users who predate the automation. The important recommendation is to layer them rather than pick one.

Close the gap before adding logic

Quick resolves custom permissions through a three-level hierarchy. A user-level profile overrides the role-level profile, which overrides the account-level profile. AWS recommends starting with an account or role default because it applies to existing users and future users—including users created through just-in-time provisioning—without waiting for another workflow to run.

That matters because the more flexible event-driven pattern only starts after a user is added to a group. AWS explicitly identifies an unavoidable interval between just-in-time account creation and group assignment. Its suggested design places the most restrictive acceptable profile at the account or role layer, then lets a Lambda function replace it with a group-specific user profile after the membership event arrives.

For operators, the ordering is the lesson: establish the safe floor first; automate exceptions second. Event-driven policy is refinement, not the initial guardrail.

Four patterns for four lifecycle moments

The simplest path is to supply --custom-permissions-name when a controlled portal or script calls RegisterUser. AWS says this fits embedded deployments and other environments that own provisioning end to end.

Native account and role defaults require less machinery and should cover organizations with uniform restrictions. Group-specific requirements need the third pattern: CloudTrail records Quick or IAM Identity Center membership changes, EventBridge filters those events, and Lambda calls the user custom-permission API. AWS’s sample also handles removals by deleting the user override so the account or role default becomes effective again.

Existing estates need a separate backfill. AWS provides a Python batch pattern that paginates through group memberships—100 records per API response—and records failures for review. The post warns that a non-paginated script would stop after the first page and leave the remainder unchanged.

The boundaries still belong to the operator

The automation is not a complete policy engine. Quick permits one custom-permission profile per user, so organizations that place people in multiple groups must define their own precedence rule. AWS suggests selecting the highest-priority, potentially most restrictive, applicable profile but does not implement that conflict resolution.

The event path also depends on CloudTrail being enabled in the target Region, and the CloudFormation stack must run in the same Region as the Quick subscription because EventBridge rules capture regional events. Monitoring both Quick-native and IAM Identity Center groups requires separate deployments.

The practical rollout is therefore incremental: set a restrictive default, attach explicit profiles during controlled provisioning where possible, add event-driven overrides only for conditional cases, and backfill the installed base. That sequence makes least privilege the state users start from rather than the state automation eventually reaches.