What Your Cloud Accounts Can Actually Do Is Not What You Think
A developer needed access to read logs from a production S3 bucket six months ago. Somebody added them to the group with the logging role. The logging role had read access to S3. They also had AdministratorAccess on their original role because the team was moving fast. Nobody removed it. Last month they got phished. The attacker now had AdministratorAccess to the production environment.
This is not a story about phishing. This is a story about effective permissions.
The Distinction Nobody Makes at Scale
Cloud platforms model access through layers. In AWS, the effective permissions for a principal are determined by the intersection of identity-based policies, resource-based policies, permission boundaries, service control policies at the organizational level, and session policies when assuming roles. Each layer can grant or restrict what an API call succeeds at.
The typical cloud governance process handles one of these layers: the identity-based policy attached to a role. Security reviews the role definition. Compliance verifies it matches the principle of least privilege. The review closes. Nobody checked the others.
A permission boundary can constrain a role to a subset of what its attached policies would allow. An SCP can restrict the entire account from performing actions regardless of what roles say. A resource-based policy on an S3 bucket can grant access to a role that has no S3 permissions in its own policy. The interaction between these layers produces an effective permissions set that is often meaningfully different from what the identity-based policy review suggests.
The Accumulation Problem
Access rights accumulate. A developer joins a project and gets added to the project's role group. They rotate to a different project. Nobody removes them from the first group. Over time, they have access derived from three projects they have not touched in eighteen months, plus whatever their current role grants.
This is not a failure of the role design. The role definitions are probably fine. The problem is that nobody is tracking the cumulative effect of group memberships, role assumptions, and cross-account trust relationships on what a specific principal can actually reach.
Cloud environments make this worse because the scale of principals is different. There are IAM users, IAM roles, service accounts for compute instances, service-linked roles created by cloud services, federated identities from your identity provider, cross-account roles for partner access, and emergency break-glass roles that bypass normal restrictions. Each category has different provisioning patterns, different review cycles, and different assumptions about who is responsible for reviewing them.
When a security team says they have reviewed IAM, they usually mean they reviewed the role definitions for their standard roles. They have not necessarily reviewed every principal's effective permissions at the account level, which is the number that matters.
What Least Privilege Means in Practice
Least privilege is the right principle. Most cloud implementations of it are aspirational rather than operational.
The stated goal is that every principal can access exactly what it needs and nothing more. The operational reality is that least privilege is applied at provisioning time, when the job function is known and the needed access seems clear. What erodes it is the accumulation of access over time, the shortcuts taken under deadline pressure, the wildcard permissions in policies that looked harmless when a developer wrote them, and the cross-account trust relationships created for integrations that outlived the integration.
The most common wildcard finding in cloud environments: policies with s3:* on a specific bucket that also match other buckets because the ARN pattern is broader than intended. Not an attack, just a typo or a misunderstanding of how ARN matching works. The account can now read every bucket with a name that matches the pattern, which includes several it was never supposed to touch.
How to Find Out What You Actually Have
Effective permissions analysis is the practice of computing what a principal can actually do, given all applicable policies, rather than reading what the attached policies say.
AWS offers IAM Access Analyzer for finding external access grants and the IAM Policy Simulator for evaluating whether specific actions are allowed. Neither gives you a complete picture of effective permissions across all principals in a complex multi-account environment without deliberate use. Third-party tools and dedicated CIEM (Cloud Infrastructure Entitlement Management) products can enumerate effective permissions at scale and surface principals with far more access than their provisioning records suggest.
The exercise is worth running periodically, not at provisioning time only. The most dangerous findings are rarely in the roles that were designed intentionally. They are in the roles that accumulated permissions gradually, the service accounts that were created for a project and never reviewed since, and the cross-account trust relationships that exist because somebody set them up and nobody removed them when the need went away.
What to Do With What You Find
Start with principals that have administrative or near-administrative effective permissions. That list is almost always longer than the list of principals that were intentionally given administrative access. For each one, answer two questions: does this principal need this access currently, and who is responsible for reviewing it going forward.
The second question is the harder one. Cloud access tends to be owned by the team that provisioned it, and those teams are not running periodic access reviews. A CIEM tool without an ownership model just produces a list of findings with no clear owner. The governance structure matters as much as the tooling.
What makes this worth doing now rather than later is the compounding effect. Effective permissions only accumulate in one direction without deliberate review. Every quarter without an entitlement review is a quarter where the gap between intended access and actual access grows. The findings do not get smaller over time. The accounts you are most worried about are the ones that have been around long enough to accumulate access that nobody intended.