A SaaS firm lets support engineers assume a troubleshooting role via IAM Identity Center, but engineers can attach broad policies and escalate beyond ticket scope. The CISO wants maximum permissions capped and per-session scoping to single customer IDs. Which least-privilege control caps role power and session scope?

A permission boundary on the troubleshooting role and a session policy on each assume-role call work together to enforce least privilege across two horizons. The boundary sets an absolute maximum that identity policies cannot exceed, so even if an engineer attaches a broad policy during a ticket, effective permissions remain capped. The session policy dynamically narrows that session to one customer ID, meeting the per-session scope requirement. A boundary that allows all customer IDs caps role power but leaves cross-tenant access available in each session. Session policies alone narrow a session but do not cap the role; if its permissions are broadened, they do not prevent escalation beyond that session control. Boundaries on engineer identities combined with customer ID session policies use the right mechanisms but place the boundary on the identity rather than the assumed troubleshooting role, so they do not limit what the role can do once assumed through Identity Center. An exam caveat: distinguish who can assume a role from what the role can do. Trust policies control who can assume, boundaries cap a role or user’s maximum, and session policies scope one session; effective access is their intersection. For a practical check, use the IAM policy simulator and CloudTrail to test the role with and without customer ID context, attempting a cross-customer read and a policy-attach action to verify both are denied.