What happens when IAM privilege escalation tools do not model service trust correctly?

Why Service Trust Changes Whether an IAM Escalation Path Exists

When an escalation tool models IAM permissions without checking the service trust policy, it can overstate reachability. In AWS, permission to pass a role is not enough on its own: the target role must also trust the intended service principal before that service can assume it. Correct modelling has to evaluate both sides of the relationship, not just the permission edge.

This matters because a path that looks valid in a graph may fail at execution time. For example, a role may be passable to Lambda or EC2 in theory, but if the trust policy does not include that service, the escalation path is blocked. The difference is not cosmetic, it changes whether the finding represents a real privilege gain or only a theoretical permission relationship.

Service trust is therefore part of the access decision, not a separate documentation detail. A useful model must treat trust policy as a gating condition for role assumption, especially in cloud privilege analysis where PassRole, cross-service delegation, and managed service execution are easy to conflate.

Where Incorrect Trust Modelling Distorts the Attack Path

Incorrect modelling usually shows up as false positives in escalation analysis. Tools may infer that an actor can move from one identity to another because the permission exists, even though the trust relationship prevents the downstream service from taking action. That can produce noisy results, wasted triage, and the wrong remediation priority.

The practical error is to treat credential and privilege escalation patterns as purely permission-driven. In cloud environments, the attacker or operator still has to clear the trust boundary that lets the service assume the role. If the model skips that check, it can also misrepresent lateral movement into managed services as a direct escalation path when the trust chain is incomplete.

For cloud teams, that means the real question is not only “can this principal pass a role” but “can the intended service actually assume it.” That distinction is what separates an exploitable path from a dead end, and it is why trust-aware analysis is essential for accurate attack-path reporting.

What Good Modelling Looks Like for PassRole and Similar Paths

A correct model should join permissions, trust policy, and service context into one decision point. The permission to pass a role, the existence of an assumable trust relationship, and the target service's execution model all have to align before the path should be treated as viable. Without that, the result is an incomplete representation of the effective privilege state.

This is the same reason cloud privilege analysis has to look beyond raw entitlements and consider effective permissions. A role that is technically reachable in policy data may still be operationally unreachable if the service trust is absent or narrowed. Good tooling should surface that difference rather than collapsing it into a single escalation score.

For AWS specifically, trust-aware modelling is most important where roles are used by Lambda, EC2, automation, and other managed services that execute with delegated authority. Those paths are attractive because they look simple in permission graphs, but they are only real when the service principal is explicitly trusted. That makes trust policy inspection a core part of privilege-path validation, not a post-processing step.

Risk and Threat Considerations

When trust is not modelled correctly, defenders can end up with a false sense of exposure or a false sense of safety. False positives waste investigation time and reduce confidence in the tool, while false negatives can hide a real abuse path if trust is present but the model fails to connect it to the permission chain.

Failure mechanism: The tool treats PassRole or similar permissions as sufficient evidence of escalation and does not verify whether the target service principal is allowed in the role trust policy.

Impact: Analysts may chase nonexistent escalation paths, miss real ones, and make incorrect remediation decisions about role design, service delegation, and cloud privilege boundaries.

Practitioner Guidance

What to verify: Check both the permission to pass or assign the role and the trust policy on the target role. If either side is missing, the path is not executable and should not be presented as a valid escalation route.

Common mistake: Treating identity graph edges as equivalent to runtime assumability. In cloud privilege work, that shortcut creates the most misleading results because policy reachability and service trust are related but not identical.

Practitioner takeaway: Trust policy is the execution gate, so escalation analysis should report only paths that survive both permission and trust validation.

Related resources from NHI Mgmt Group

• Why do service accounts with standing IAM privilege create escalation risk in cloud environments?
• What happens when MCP tools expose write actions but the underlying user should not have model-driven write privilege?
• What happens when service accounts with standing privilege are exposed to attackers in a zero trust environment?
• What does AI model abuse reveal about the current NHI threat surface?