Explain Access
Understand why a specific AWS action is allowed, denied or indeterminate for an identity.
Effective Permissions shows what an identity can do. Explain Access answers a different question: why does the identity have or not have a particular action for a specific AWS service or resource? It works through each applicable authorization layer and surfaces the result as a layered decision breakdown.
The question it answers
Based on the authorization context available to this assessment, why does this identity have or not have this access for this action?
This is useful when investigating a finding, reviewing a specific permission, or preparing for a remediation decision. Rather than reading raw policy documents across multiple AWS consoles, the Explain Access panel consolidates the supporting evidence.
Where to open Explain Access
The panel can be opened from multiple places in the product:
- the user detail drawer in the IAM Analyzer identity list
- the role detail drawer in the IAM Analyzer identity list
- an Effective Permissions row — selecting an action opens the explanation for that action
- a selected identity node in the IAM Relationship Graph
Decision states
Each layer and the overall result can produce one of three states:
- Allowed — the layer permits the action based on the collected policy information and the assessment was able to verify the relevant evidence.
- Denied — the layer contains a restriction that blocks the action, either through an explicit deny or a missing allow in a mandatory layer.
- Indeterminate — a layer exists and is relevant, but the assessment cannot fully evaluate it. Common causes include missing SCP hierarchy data, incomplete resource-policy collection, or conditions that depend on runtime request context.
Important
Identity Layer: Allowed Boundary Layer: Allowed SCP Layer: Indeterminate Resource Layer: Allowed ───────────────────────────── Overall: Indeterminate
The four authorization layers
AWS IAM authorization can involve multiple independent layers. Explain Access works through four supported layers in order. All applicable layers must permit the action for the overall result to be Allowed.
1. Identity policy 2. Permission boundary 3. Service Control Policy 4. Resource policy
Layer 1: Identity policy
Identity policies are the permissions attached to the IAM user or role itself, including policies attached through IAM group membership.
When an action is granted through a group policy, Explain Access identifies the group as the source rather than attributing it generically to the identity. This distinction matters when investigating inherited permissions — a policy attached to a group may affect many users.
alice ↓ member of Developers group ↓ group policy AllowEC2Read ↓ ec2:DescribeInstances → Allowed
Layer 2: Permission boundary
A permission boundary does not grant permissions. It defines the maximum permission ceiling for the identity. If the identity policy allows an action but the boundary does not, the action is denied at this layer.
Limitation
Layer 3: Service Control Policy
SCPs are organization-level permission guardrails applied through AWS Organizations. They do not grant permissions — they define the maximum actions available to principals in the governed accounts, organizational units and root.
Securitain uses collected organization hierarchy and SCP documents to evaluate the applicable SCP context for each identity under assessment. Availability depends on whether the connected account is part of an AWS Organization and whether the required organization information can be collected.
SCP hierarchy evaluation
AWS Organizations structures accounts into a hierarchy: root, organizational units (OUs) and member accounts. SCPs can be attached at any level. Securitain evaluates SCP context across the hierarchy as follows:
- Within a level — if multiple SCPs are attached at the same OU or account level, their allows are unioned. The identity needs to be permitted by at least one SCP at that level to pass.
- Across levels — the allowed sets from each level are intersected. An action must be permitted at every level in the hierarchy path from root to the member account.
- Explicit deny — a deny in any SCP at any level overrides any allow, regardless of other SCPs.
Root SCPs: Allow S3:*
↓ (intersection)
OU SCPs: Allow S3:GetObject, S3:PutObject
↓ (intersection)
Account SCPs: Allow S3:GetObject
SCP Result: S3:GetObject → Allowed
S3:PutObject → Denied (missing at account level)
S3:DeleteObject → Denied (missing at OU level)Important
Layer 4: Resource policy
For AWS services that use resource-based policies, the resource policy can independently grant or restrict access. A resource policy that grants access to the identity can allow an action even without an identity policy grant, depending on the AWS service. A resource policy deny overrides identity-policy allows.
Resource policy evaluation in Explain Access covers supported resource types where both the identity policy and resource policy are available. Where a resource policy exists but cannot be read, or where the evaluation depends on a runtime condition, the layer result is Indeterminate.
Session policies
Limitation
sts:AssumeRole or similar — are not observable by Securitain. Session policy context is treated as unknown in Explain Access. This means the panel cannot evaluate whether a session policy further restricts an otherwise-allowed action during an active assumed-role session.Explicit deny
An explicit deny in any policy — identity policy, boundary, SCP or resource policy — takes precedence over any allow in the same or other policy sources.
Identity policy: ALLOW s3:DeleteObject SCP: DENY s3:DeleteObject ─────────────────────────────────────── Result: Denied
How layers combine to a decision
Allowed
When all applicable layers permit the action
Identity: Allowed Boundary: Allowed SCP: Allowed Resource: Allowed ───────────────── Result: Allowed
Denied or Indeterminate
When any applicable layer blocks or cannot be evaluated
Identity: Allowed Boundary: Allowed SCP: Denied Resource: Allowed ───────────────── Result: Denied
Permission sources and provenance
Where the identity layer result is Allowed, Explain Access identifies the specific policy or policy set responsible, including whether the grant came from a directly attached policy or an IAM group policy. This provenance is useful when deciding which policy to modify during remediation — changing the wrong policy may not fix the underlying access condition.
Limitations
- Boundary scope — permission boundary evaluation covers IAM roles; IAM user boundaries are not included today.
- Conditions not evaluated — policy conditions that depend on runtime request context (IP address, time, MFA, resource tags) are not evaluated. A condition-gated allow still appears as Allowed at the identity layer; actual runtime authorization may differ.
- Session policies — not observed; treated as unknown.
- SCP hierarchy gaps — if an intermediate OU or organization document is not available, the SCP layer is Indeterminate rather than assumed clear.
- Resource policy completeness — resource policy collection covers supported resource types. An unsupported resource type returns Indeterminate for the resource layer, not Allowed.
Evidence and data completeness
Explain Access reflects the authorization context collected during the most recent supported scan. A stale scan may not reflect recently attached policies, boundary changes, or SCP updates. Use Scan Status to verify the freshness of the underlying data before relying on the explanation for a time-sensitive decision.
Important