AWS entitlements | Insights

In Insights, AWS entitlements represent the effective access identities have across your AWS environment whether granted directly through IAM policies or indirectly via role assumption.

To simplify analysis, Insights classifies all AWS entitlements into two types:

• Permission: Direct access granted via IAM policies
• Escalation: Indirect access via role assumption, typically by Identity Center users

This classification helps you quickly understand who has access, how they got it, and how risky that access is.

Permission Entitlements

The Permission entitlement type includes all IAM policies that directly grant access to AWS resources. Insights uses privilege scoring to analyze and rank these policies based on the level of access they provide. This helps you identify high-impact permissions and prioritize risk.

Policy Types Included

ℹ️

Even sts:AssumeRole permissions are included under Permission when they are granted directly via IAM policies.

Escalation entitlements

The Escalation entitlement type highlights indirect access paths — specifically, the ability of an identity to assume a role into another AWS account.

This is especially important for Identity Center users, who may not have direct permissions but can escalate into high-privilege roles via permission sets.

Example

• User_A is mapped to a permission set in Identity Center
• That permission set allows assuming AdminRole in AWS Account B
• AdminRole has full *:* permissions

Even though User_A doesn’t have direct access, they can escalate into a high-privilege role — and that’s surfaced as an Escalation entitlement.

Why this classification matters

Understanding how entitlements are categorized helps you:

• Trace privilege paths from user → role → resource
• Identify escalation risks that aren’t obvious from direct permissions
• Prioritize remediation based on true access, not just policy attachments

This model powers key workflows like:

• journeys/find-privileged-aws-accounts
• reporting/high-risk-accounts
• reporting/escalation-paths-overview

FAQs

Q: Why is sts:AssumeRole sometimes under Permission and sometimes under Escalation?
A: If the permission is granted directly via a policy, it’s classified as Permission. If it represents an actual escalation path (e.g., Identity Center user → role), it’s surfaced as Escalation.

Q: Can an identity have both Permission and Escalation entitlements?
A: Yes. For example, a user might have direct access to some resources and the ability to assume into other roles.

Q: How does privilege scoring work?
A: Insights analyzes IAM policies to determine the breadth and depth of access (e.g., wildcard actions, sensitive services) and assigns a risk score accordingly.

Related pages

• tutorials/cloud/aws
• key-concepts/true-privilege
• key-concepts/escalation-paths
• reporting/high-risk-accounts
• journeys/find-privileged-aws-accounts

---