Effective Permissions
Understand what an AWS identity can effectively do after relevant authorization controls are considered.
An attached policy tells you what a policy document contains. It does not always tell you the final access available to the identity. Securitain's Effective Permissions view brings supported authorization context together so teams can investigate effective access rather than attached-policy volume.
Why attached policies can be misleading
Consider a role with an attached policy that grants s3:*. Looking only at that policy may suggest broad S3 access. But AWS authorization can also involve other controls.
Identity Policies + Group Permissions + Permission Boundary + Organization / SCP Context + Explicit Denies ↓ Effective Permission Context
A permission that appears in an attached policy may be constrained by another applicable control. Likewise, permissions inherited indirectly can matter even when they are not attached directly to the identity being reviewed.
Where to find Effective Permissions
The current view organizes results by identity and AWS service. Depending on the available result, you can review information such as entity, entity type, AWS service, allowed actions and effective-access risk context. The exact result depends on the evidence available to the assessment.
Identity policies
Identity-based policies can grant permissions directly to supported AWS IAM principals. For IAM users, permissions can also be inherited through IAM group membership. For example:
dev-user ↓ member of Developers ↓ group policy s3:GetObject
When investigating the user, group-derived permissions should be considered alongside directly attached permissions.
Permission boundaries
A permissions boundary does not grant permissions by itself. Instead, it defines a maximum permission boundary for the IAM user or role to which it applies.
Identity Policy Allows ∩ Permissions Boundary Allows ↓ Potential Effective Set
If the identity policy permits an action but the permissions boundary does not allow that action, the boundary can constrain the resulting permission. Securitain can identify supported effective-permission results where permission-boundary context limits the principal's access.
AWS Organizations and SCPs
Service Control Policies, or SCPs, can affect the maximum permissions available to principals in accounts governed by AWS Organizations. SCPs do not grant permissions — they define organization-level permission boundaries for member accounts and organizational units.
Identity Permission ∩ Applicable SCP Permission Context ↓ Allowed Organization Scope
Securitain uses supported Organizations/SCP context when that information is available to the assessment. Availability can depend on the connected account, the account's position within AWS Organizations, AWS permissions available to the Securitain assessment, and whether the relevant organization information can be collected.
Important
Explicit deny
AWS explicit deny takes precedence over an otherwise applicable allow.
ALLOW s3:GetObject + DENY s3:GetObject ↓ Denied
This is one reason simply counting attached allow statements can produce a misleading view of access.
What the Securitain result means
Based on the supported policy information and authorization context available to this assessment, these are the actions Securitain currently represents as effectively allowed or constrained for this principal.
Do not interpret the result as a universal simulation of every possible AWS request context. AWS authorization can depend on information that exists only when an actual request is made.
Example
Imagine DeploymentRole has an identity policy granting s3:GetObject, s3:PutObject and kms:Decrypt. Its permission boundary allows s3:GetObject and kms:Decrypt but does not allow s3:PutObject.
The resulting access may therefore be narrower than the attached identity policy suggests. The important investigation question becomes:
What actions remain available after the relevant controls are applied?
That is the purpose of Effective Permissions.
Risk context
The Effective Permissions view can provide a risk indicator for the resulting permission set. Use that value as a prioritization aid. Do not interpret it as a probability of exploitation, an independent proof that a principal is compromised, or a universal AWS risk score. The detailed permissions and surrounding identity context remain more important than the number alone.
Proprietary boundary
Effective Permissions vs Policy Analyzer
Policy Analyzer
What does this policy contain, and what characteristics deserve attention?
Use when starting from a policy document.
Effective Permissions
What permissions remain available to this identity after supported context is considered?
Use when starting from an identity or access question.
Effective Permissions vs Sensitive Permissions
A permission can be effective without necessarily being highly sensitive. A sensitive-permission view helps focus attention on actions with greater security consequence. For example, s3:ListBucket and iam:PassRole are both permissions, but their security implications can be very different depending on scope and context.
How Effective Permissions feeds deeper analysis
Effective permission context is important because later questions depend on what the identity can actually do.
Attached Policies ↓ Effective Permissions ↓ Sensitive Capabilities ↓ Privilege Escalation ↓ Blast Radius
For this reason, an incomplete effective-permission assessment can also limit the certainty of downstream security analysis.
Investigating broad effective access
- 1
Identify the identity
Determine whether it is an IAM user, an IAM role, a human identity or a workload identity.
- 2
Review allowed actions
Focus first on wildcard actions, IAM mutation, role assumption, PassRole, credential creation, security-control changes and access to sensitive data services.
- 3
Review permission source
Determine whether access comes from a direct managed policy, an inline policy, an IAM group, or another supported permission source.
- 4
Review constraints
Check permission boundary, SCP context, explicit deny, policy conditions and resource scope where available.
- 5
Investigate consequence
Continue into Sensitive Permissions, Privilege Escalation, Blast Radius, Identity-to-Data and Cross-Account Exposure.
Evidence and limitations
Effective AWS authorization can depend on details including:
- identity policies
- IAM group policies
- permissions boundaries
- SCPs
- resource policies
- session policies
- role trust
- explicit deny
- request context
- policy conditions
- principal tags
- resource tags
- service-specific authorization behavior
Not every AWS authorization input is necessarily available to every Securitain assessment or represented in every effective-permission result.
Important
If assessment coverage is incomplete, use Scan Status and related evidence to understand what information was available.
Related guides