Cloud permission sprawl: the identities nobody is reviewing

In most cloud estates, machine identities outnumber human ones by an order of magnitude - and the access review process covers only the humans. Service accounts, workload identities, CI pipelines, functions and integrations all hold permissions, and almost nobody reviews them.

How sprawl happens

• A role is created broadly to unblock a deployment and never narrowed.
• Permissions are copied from an existing role that was already too wide.
• A managed policy grants far more than the task needs because it was convenient.
• Roles accumulate through mergers, migrations and abandoned projects.
• Nobody dares remove a permission because nobody knows what depends on it.

The compounding problem is that granted permissions and effective permissions are different things. Inherited policies, group membership, resource policies and role assumption chains combine into an effective set nobody wrote down and few can compute by inspection.

Right-size from usage, not from guesswork

Cloud platforms record which permissions an identity has actually used. That data is the safest basis for reduction: compare granted against used over a meaningful window, and remove what has never been exercised.

Two cautions. Use a long enough window to capture quarterly and annual jobs - a ninety-day window will happily remove the permission your year-end process needs. And stage the change: alert on denied actions in a monitoring mode before enforcing, so you find dependencies without an outage.

Machine identities need the same lifecycle as people

• A named human owner for every service account and workload identity. Ownerless identities are never cleaned up.
• An expiry or review date at creation.
• Prefer workload identity over static keys - it removes the credential entirely rather than protecting it.
• Review on the owner leaving, which is the trigger that catches orphans.

The permissions that matter most

Not all excess is equal. Prioritise anything that grants privilege escalation - the ability to modify IAM policies, assume other roles, attach policies, or create identities. An identity that can grant itself more permission is effectively an administrator regardless of what it currently holds.

After that: data access at scale, the ability to delete or disable logging, and anything that can reach production from a non-production context.

Why access reviews miss this

Traditional reviews present a list of users and their group memberships to a manager, who confirms the person still needs their job. That process has no place to put a workload identity, no manager to ask, and no way to express "this role can escalate to administrator through two hops".

Cover non-human identities as a distinct review, owner by owner, and use effective-permission data rather than role names.

Key takeaways

• Machine identities usually outnumber humans and are rarely reviewed.
• Granted and effective permissions differ - work from effective.
• Right-size from usage data, with a window long enough for periodic jobs.
• Privilege-escalation permissions matter more than volume of excess.