Direct IAM permissions are the actions explicitly attached to an identity. Real access also includes anything that identity can reach, modify, invoke, or assume through other resources and roles. In practice, that means the true blast radius may be far larger than the policy document suggests, especially in environments with automation, permissive resource roles, and weak segmentation.
Why Direct IAM Permissions and Real AWS Access Diverge
Direct IAM permissions are only the policy statements attached to an identity. Real access is the effective set of actions that identity can actually perform after you include role assumption, resource-based policies, trust relationships, service-linked permissions, and any downstream paths that those permissions open. The gap matters because authorization reviews that stop at attached policies often miss the true blast radius.
In AWS, the difference appears whenever an identity can use one permission to reach another control plane object, or when a resource policy grants access independently of the identity policy. That is why a short permission list can still produce broad operational reach, especially in environments with delegated administration, automation, and cross-account trust.
Real access also includes what the identity can influence indirectly. An identity may not be allowed to write a resource directly, but it may be able to assume a role, invoke a function, update a configuration, or alter a dependency that then changes the behavior of a more privileged system. For a practical view of lifecycle and entitlement sprawl, see Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs.
What Expands AWS Access Beyond the Attached Policy
The first expansion point is role assumption. If an identity can call sts:AssumeRole, the effective access includes the permissions of the target role for the duration of the session. The second is resource-based authorization, where a bucket, queue, key, or secret policy can grant access even when the identity policy is narrow. The third is transitive reach, where one allowed action enables a second-hop action that was not obvious in the original policy review.
That is why permissions analysis must look at both granted permissions and used or reachable permissions. A narrow principal policy can still sit inside a large trust graph, and the practical question is not “what does the JSON allow?” but “what can this identity actually reach in the account, across accounts, and through services it is allowed to invoke?” For a broader control perspective on entitlement right-sizing, use Cloud PAM and CIEM Guide.
In AWS estates, the biggest sources of mismatch are automation roles, permissive trust policies, and resource policies that were added for convenience and never revisited. Over time, these paths create effective access that is larger than any single attached permission set.
How to Measure Real Blast Radius in Practice
The useful unit of analysis is effective access, not policy count. Start by tracing what the identity can assume, invoke, pass through, or modify, then map the downstream resources that those actions unlock. That includes cross-account roles, service roles, delegated admin paths, and permissions that become dangerous only when combined.
When the environment includes non-human identities, the access problem is often lifecycle-driven as well as policy-driven. Secrets may be long-lived, roles may be reused, and trust policies may survive after the original use case has ended. The more automation and service integration you have, the more important it becomes to validate actual reach rather than assume the attached policy is the final answer. A useful starting point is Cloud Workload Identity Guide, which shows how temporary credentials and federation change the access picture.
Risk and Threat Considerations
The main risk is underestimating blast radius. If you review only direct permissions, you can miss privilege escalation paths, cross-account reach, or indirect control over sensitive systems. That creates a false sense of containment, especially when resource policies and trust relationships are permissive.
Failure mechanism: An identity with limited-looking permissions uses role assumption, service invocation, or a resource policy to reach assets that were not visible in the original policy review, then pivots into higher-value resources.
Impact: Access reviews become incomplete, privilege creep goes undetected, and an apparently low-risk identity can be enough to read, modify, or destroy far more than intended.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack surface, CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | AWS real access depends on accounts, roles, and reachable entitlements beyond the attached policy. |
| Recommendation — Review effective permissions across accounts, roles, and service paths, then remove unused access. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The question is about the gap between nominal and effective access, which is a least-privilege issue. |
| IA-5 — Authenticator Management | AWS access often hinges on credentials and role sessions that expand practical reach. | |
| Recommendation — Evaluate effective access paths and reduce permissions to the minimum reach actually required. Control credential and session lifecycle so indirect access paths do not persist unnoticed. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Access control governance must cover effective access, not only written permissions. |
| Recommendation — Validate that access decisions reflect reachable permissions, trust paths, and resource policies. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Indirectly reachable AWS actions can bypass the apparent limits of direct authorization. |
| Recommendation — Test whether alternate paths let identities invoke higher-privilege functions than intended. | ||
Practitioner Guidance
What to verify: Review the identity’s reachable actions, not just its attached statements. Include assumed roles, resource policies, pass-role paths, and any service that can act on the identity’s behalf. If a control only checks policies in isolation, treat it as incomplete.
What good looks like: A reviewer can explain, for each identity, which resources it can reach directly, which it can reach indirectly, and which paths are only possible because of trust relationships or downstream services. If those three sets differ materially, the effective access model is the one that should drive remediation.
Practitioner takeaway: In AWS, the real security question is not whether the policy is narrow, but whether the trust graph is narrow enough to match the policy.
OWASP Non-Human Identity Top 10 highlights why overprivilege and secret sprawl often make effective access much larger than intended.
CIS Controls v8 supports this by pushing account management and access control reviews beyond static policy inspection.
Related resources from NHI Mgmt Group
- What is the difference between federated SAML or OIDC access and AWS IAM Identity Center?
- What is the difference between security groups and IAM permissions in AWS instance access?
- What is the difference between reviewing human access and reviewing NHIs?
- What is the difference between role-based access and API key governance for NHI security?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
