Why IAM Security Is Difficult
IAM risk is rarely visible in a single user, role, or policy. It emerges when permissions, credentials, services, and trust relationships are combined.
The risk is in the relationship
AWS IAM information is distributed across users, groups, roles, policies, permission sets, credentials, service trust policies, federation providers, and account boundaries. Each object may appear reasonable when reviewed independently. The real risk becomes visible only after the relationships are connected.
Distributed permissions
Permissions may come from identity policies, groups, roles, permission sets, resource policies, and organizational controls.
Indirect privilege
A user without AdministratorAccess may still reach privileged capability through role assumption, PassRole, policy modification, or a trusted AWS service.
Multiple entry paths
Access keys, SAML, OIDC, service roles, and cross-account trust create additional ways to enter or move through the environment.
Manual correlation limits
A spreadsheet or one-object-at-a-time review cannot reliably calculate every possible relationship and escalation path at cloud scale.
AWS example: a developer reaches administrative access
AWS example: a developer reaches administrative access
The IAM user dev-user does not directly have AdministratorAccess. However, the user can create and invoke a Lambda function and pass the CloudOpsAdminRole. Because the role trusts lambda.amazonaws.com and has powerful permissions, code executed by the function receives the role’s privileges. The user has therefore reached administrative capability indirectly.
The user, policy, role, and trust policy may each look acceptable alone. The complete path is dangerous.
How the path should be prevented
Restrict PassRole
Allow only approved role ARNs; never use a broad wildcard for privileged roles.
Limit the target service
Use the iam:PassedToService condition for the intended AWS service.
Remove excessive role permissions
Replace AdministratorAccess with workload-specific least privilege.
Add guardrails and verification
Use permission boundaries or SCPs where appropriate, then rescan to verify the path is removed.
See how Securitain investigates this problem
Securitain connects identities, policies, roles, credentials, and trust relationships so hidden access paths can be detected and explained.
Outcome: Hidden IAM risk becomes visible before the path is used by an attacker.