What is an over-permissioned identity?

An over-permissioned identity is a cloud user, role, or service account that holds more permissions than it actually needs for its work. It is the most common quiet risk in cloud environments: present in nearly every account, rarely causing visible problems on its own, and carrying serious consequences when something else goes wrong.

How do identities accumulate excess permissions?

Permissions grow through a consistent pattern: they are added under time pressure and never removed.

When an engineer needs access to complete a task, the fastest path is almost always a broad permission set. Attaching PowerUserAccess or AdministratorAccess takes seconds. Scoping a custom policy to exactly the S3 prefixes and DynamoDB tables that a specific service actually touches takes research, testing, and iteration. Under deadline, teams choose speed. The intent is usually to tighten the scope later. That rarely happens.

The same pattern applies to service accounts and automation roles. A deployment role gets broad access to reach a new resource during an incident. A Lambda function gets read access to a bucket it needed once. Neither gets reviewed afterward. Over months, permissions accumulate across dozens of identities until the actual permission footprint of an account is several times larger than what any current workflow requires.

Why is this described as a quiet risk?

Most over-permissioned identities never directly cause an incident. Permissions that are not used are not harmful on their own. The risk is conditional: it activates when something else goes wrong.

A developer identity with AdministratorAccess is not a problem until that identity’s credentials are phished, or until that developer makes a mistake during an incident response. At that point, the damage is bounded only by what those permissions can reach. An over-permissioned service account is not a problem until the service it runs on is compromised. Then the attacker’s lateral movement is constrained only by the scope of that role.

This conditionality makes over-permissioning easy to deprioritize. Nothing is broken. Alerts are not firing. The risk is invisible until it is not.

How do you find over-permissioned identities?

AWS provides tooling that makes auditing tractable. IAM Access Analyzer shows which permissions each identity has used and when. The IAM console exposes last-used dates at the policy level, so you can see that a role has 200 permissions attached but has only called 12 distinct APIs in the past year. AWS service last accessed data goes a level deeper and shows which services a role has actually interacted with, not just which services its policies allow.

A practical starting point: flag any permission that has not been used in 90 days as a removal candidate. Flag any identity carrying a managed policy like AdministratorAccess or PowerUserAccess for manual review. These two passes alone typically surface the majority of excess permissions in an account.

For service accounts and Lambda execution roles, the question is simpler: what APIs does this code actually call? That can be answered by reading the source or by inspecting CloudTrail logs for the role over a representative time window. Anything outside that set is excess.

What is a reasonable cadence for reviewing permissions?

Quarterly is a common baseline for human identities. Monthly works better for high-privilege roles and service accounts in active services.

The goal of each review is not to achieve perfection but to prevent drift from compounding. A role that is slightly over-permissioned after one quarter of growth is easy to fix. The same role after two years of unreviewed additions becomes a project that nobody wants to take on because the risk of breaking something feels higher than the risk of leaving it alone. Frequent small reviews prevent that calculus from setting in.

Automated tooling helps. AWS IAM Access Analyzer can generate least-privilege policies from actual CloudTrail activity, giving reviewers a concrete diff rather than a blank-slate policy-writing exercise.

Korvalis surfaces over-permissioned identities as part of session monitoring, flagging when an identity uses permissions far outside its recent pattern or reaches resources it has no history of touching.