Examples in this article are illustrative, not customer case studies. Product availability and coverage are described on the linked capability pages.
An entitlement finding tells you a role holds more permission than it needs, but not whether that permission leads anywhere an attacker would want to go. This post shows how to trace identity attack paths from a compromised workload through every role it can assume to the data store at the end, and how to rank and cut them.
An identity attack path is the route from a compromised workload identity, through every role it can assume, to the data stores those roles can reach. Tracing paths end to end, across account boundaries, shows which trust-policy edge to cut, something a flat audit of individual roles cannot do.
Our example is a document-upload API that customers call directly and that, two role assumptions later, can read a customer records database in a different account.
Identity attack paths start where an attacker lands
An identity attack path starts at a point of compromise, and in the cloud that is usually a workload identity. An attacker who exploits a running service inherits whatever identity it runs as, whether the service is a container, a function or a virtual machine. From there, the trace follows every role the identity can assume, then every role those roles can assume, until nothing further is reachable. At each hop it records what the current role can touch directly: storage, databases, secrets and management APIs.
The result is a tree rather than a single line, because one identity can often reach several roles, each opening onto different resources. That lets you ask the question that matters for prioritisation: for a given data store, which starting identities have a path to it, and how many hops does each path take? A store reachable in one hop from a public-facing workload is a different risk from one reachable only after several internal assumptions that need credentials an attacker is unlikely to hold.
A copied role template turns a narrow workload into a broad one
The most common real chain begins with a workload granted a role for one narrow task, built from a broader template that was never trimmed. The document-upload API only needs to write files to one bucket. Its role, copied from an operations template, can also assume a deployment role that engineers use for releases, which was scoped loosely because only a few trusted people were expected to use it.
Follow the chain. A crafted upload exploits a parsing flaw in the API, and the attacker inherits its workload identity. That identity assumes the deployment role, and the deployment role can assume a reader role in the data account that holds the customer records database. After the initial exploit, each subsequent step depends on the provider-specific permission, trust, condition and deny rules allowing it. The vulnerability and the entitlements belong to different teams, and neither finding alone describes the actual risk.
Wildcard trust policies are where most identity attack paths begin
A role’s trust policy defines which principals may assume it. When that principal is a whole account instead of a specific role, when a condition is easy to satisfy, or when a trust relationship survives from a migration or proof of concept, a role that looks well scoped in its permission policy becomes reachable from almost anywhere. The deployment role in our example trusts any identity in the application account, which is exactly how the upload API’s identity reaches it.
Broad trust policies are easy to introduce by accident, because console examples and infrastructure-as-code templates often start permissive and are meant to be narrowed before production. Reviews also tend to read trust policies as configuration rather than as access, so they receive less scrutiny than permission policies. Scanning templates before they are applied catches many of them, as we describe in IaC scanning before apply.
Cross-account assumption hides the path from each account owner
Cross-account assumption moves the trust decision outside the boundary any single owner sees in full. The application team sees a deployment role with sensible permissions. The data team sees a reader role trusted by a named role in a sibling account. Neither owner, looking at their own account, sees that a public API sits two role assumptions away from customer records.
The same pattern applies to third-party integrations. Granting a vendor a role extends your trust boundary to the principals and conditions that the role permits, and if their environment is compromised or the trust condition is broader than the use case, the vendor link becomes a hop in your path. Tracing must therefore cross account and subscription boundaries rather than stop at them, because an attacker will not stop there either.
Prioritise by what the identity can reach, not by permission count
With paths traced end to end, priority follows the value at the end of each path and the number of hops needed to reach it. The upload API’s path is short, starts on the internet and ends at customer records, so it comes first. A workload with a longer path to an empty logging bucket can wait, even if its permission policy looks larger on paper. Flat entitlement audits cannot make this correction, because they score the identity rather than the path. For the same idea applied to excess privilege in general, see excess privilege as graph edges.
Record which edge was cut and prove the path is gone
Closing an identity attack path means removing one edge: narrowing the deployment role’s trust policy to the release pipeline, removing the cross-account assumption, or revoking the reader role’s access to the database. The record should name the edge, show when it changed and confirm that the path no longer resolves, not merely note that a policy was edited. Without that evidence, a template redeploy or policy rollback can reopen the path silently, and nobody notices until the next trace. The same record also serves as continuous compliance evidence without a separate collection exercise.
Key takeaways
- Include public-facing workload identities, compromised users, CI identities and third-party principals as possible starting points.
- Review trust policies as rigorously as permission policies, and replace account-wide principals with specific roles.
- Trace role assumption across account and vendor boundaries rather than stopping at them.
- Record the exact edge you removed and re-trace to confirm the path no longer resolves.
How SecurityVault approaches this
SecurityVault connects collected identity and permission relationships with posture and workload findings. Teams can inspect candidate routes to sensitive resources, review the assumptions behind each hop and choose an intervention. Confirm the changed permissions and refresh the relevant evidence before concluding that a path has been removed.
Use an identity chain that your cloud team can verify independently. Compare the reported path with the applicable trust policies, permissions, conditions and explicit denies, including any account boundary. After an approved change in a test environment, collect the affected state again and review whether the path explanation changes. Include a missing-permission collection case to see how incomplete evidence appears. This gives identity owners and application owners a shared investigation record without treating every graph connection as an immediately executable attacker action.
Explore Identity and entitlements or talk to our team about an evaluation with your engineering, security and compliance stakeholders.