Examples in this article are illustrative, not customer case studies. Product availability and coverage are described on the linked capability pages.
Your cloud accounts hold thousands of identities, most with more permission than they use, and the access review meant to catch that excess privilege is a spreadsheet nobody can reason about. This post shows how to find it by modelling entitlements as edges in a graph, and how to turn that model into permission reductions teams will approve.
Excess privilege is access beyond what an identity needs for its authorised tasks. Unused permissions are review candidates, not conclusive proof of excess. Modelled as graph edges, recording who can assume which role and which role can access which resource, it becomes something you can trace, rank by what it reaches and cut, rather than a row in a periodic access review.
We will follow one identity throughout: the workload identity of a reporting service that builds nightly revenue summaries.
Measuring excess privilege starts with effective permissions
Finding excess privilege starts with an inventory of every identity that can act in a cloud environment: people signing in through single sign-on, workload identities attached to instances, containers and functions, and service accounts created for automation or third-party integrations. For each one it resolves effective permissions, meaning what the policy actually grants once inheritance, group membership and resource-level exceptions are applied. Cloud permission models are expressive enough that the written policy and the effective result often diverge.
The second half of the job is comparing granted permissions with used ones. Provider activity logs record which API calls an identity has made, and the gap between granted and observed use identifies permissions to review. Seasonal jobs, disaster recovery and incomplete logs can explain legitimate non-use. The reporting service needs to read one warehouse table and write summary files. Its role was copied from a broader analytics template, so it also holds write access to several storage services it has never called.
Excess privilege travels through assumable roles
Most privilege escalation starts not with an identity’s own permissions but with what it can become. Role assumption lets one identity temporarily take on another’s permissions, and trust policies decide who may make that jump. A workload identity with modest permissions that can assume an administrative role is, for practical purposes, an administrator, and an attacker who compromises the workload will make the jump without hesitation.
The reporting service’s template role carries one more inherited grant: it can assume an operations role created for incident response, and that role reads the production customer warehouse in full. Listing permissions per identity shows two roles that each look defensible. Modelling who can become whom shows a reporting job that can read every customer record. Assess both who can assume a role and what it can do. Narrow trust does not make administrative permissions low risk. For the end-to-end version of this chain, see identity attack paths.
Least privilege needs usage evidence, not intent
Least privilege is easy to state and hard to operate. Removing a permission is a change with a blast radius nobody wants to own: if the permission turns out to be needed, something breaks visibly, at a time you did not choose. Granting feels safe and revoking feels risky, which is why permissions accumulate and almost never shrink by themselves.
Evidence changes that calculation. Usage data over a meaningful observation window turns “we think this role has too much access” into a specific list of actions the identity has exercised, set against a much longer list it holds but never uses. With that list in hand, a platform team can approve removing the reporting service’s unused storage writes and its ability to assume the operations role. The alternative is carrying open-ended risk for a capability nothing uses.
Periodic access reviews cannot see multi-hop privilege
The access review is the traditional control for excess privilege, and it fails for structural reasons that diligence cannot fix. A review asks a manager whether a person still needs the access they hold, one identity at a time. That works for a human with a few role assignments. It does not work for workload identities, service accounts and the assumption chains between them, because no reviewer can hold a multi-hop trust relationship in their head while skimming a spreadsheet.
The deeper problem is that reviews judge identities in isolation, and privilege risk is not an isolated property. The reporting service would pass any review of its own role, since its grants look like normal analytics access. The risk sits in the edge to the operations role, which no row in the spreadsheet shows. A long review cycle also gives any short-term grant a long window in which an attacker can find it before a reviewer does.
Excess privilege as graph edges you can walk, rank and cut
A graph can support the review. Identities and roles are nodes, and the relationships between them (assumes, can_access, authenticates_as) are edges you can traverse. A person authenticates_as a federated role, the reporting service’s identity assumes the operations role, and the operations role can_access the customer warehouse. Excess privilege becomes a property of the paths through the graph, and a path is something you can trace, rank and cut.
This is also what connects CIEM to attack-path analysis instead of leaving it as a parallel discipline. If the reporting service’s container runs an image with a known flaw, the edge to the operations role stops being a hygiene issue and becomes the second step of a route from a compromised workload to customer data. Ranking reductions by the paths they cut, rather than by permission count, puts that edge at the top of the list. Trust policy changes also belong in your policy-as-code deployment gates, so that an over-broad trust relationship is caught before it ships.
Key takeaways
- Resolve effective permissions for every workload identity and service account, not only for people.
- Use usage evidence from an observation window to justify each permission removal.
- Map which roles each identity can assume, because that edge often carries more risk than its direct grants.
- Prioritise reductions by the paths they cut to sensitive data rather than by permission count.
How SecurityVault approaches this
SecurityVault connects collected identities, roles and resource permissions with cloud posture and workload context. Teams can investigate candidate access paths and prioritise permission reviews by exposure and business impact. Validate provider conditions and operational requirements before reducing access; missing activity in a collection window is not proof that a permission is unnecessary.
A practical evaluation starts with a known service identity and a resource it is expected to access. Review the collected grants, the source of each relationship and any conditions that could change the effective result. Include a permission used only for recovery, so the team can demonstrate how operational context affects the recommendation. The intended outcome is a reviewable reduction plan with an owner, a rollback approach and evidence that the application still performs its required tasks after the change.
Explore Identity and entitlements or talk to our team about an evaluation with your engineering, security and compliance stakeholders.