Can AWS sessions be limited to specific resources and actions?

Other patterns include role chaining, session tags with ABAC or resource-based policies, and just-in-time access. Tags can let policies decide which resources a session may access, while a temporary task role can be created or modified for a specific job and then discarded. These approaches take more setup, and ABAC coverage varies across AWS services, so many organizations combine attributes with explicit resource-based rules.

The AI aspect does not require a fundamentally different IAM model. Treat the assistant as another principal and issue it temporary credentials for a dedicated, narrowly scoped role. Session policies are useful for ad hoc reductions, but predefined roles and permission sets are usually more predictable and easier to review.

Yes—AWS session policies are designed for this. When assuming a role or requesting federated temporary credentials, you can pass a session policy that further restricts the permissions granted by the role. The effective permissions are the intersection of the role policy and the session policy, so the session policy can narrow broad access but cannot grant permissions the role does not already have. Resource-level restrictions also depend on whether the AWS service and action support them.

You can also solve this with separate roles or permission sets for common workflows. For example, create distinct roles for SSM access, power-user tasks, backups, and read-only AI-assisted work. This is often easier to audit and safer operationally than generating a custom policy for every session. Keep the AI role read-only or tightly scoped, with a human approving anything that can change infrastructure.