Hidden machine-to-machine access path

The scenario

A reporting service in the analytics account assumes a role in the shared-services account to read configuration. That role, set up years earlier for a different purpose, is trusted by a third role in the customer-data account, created for a one-off migration and left in place. None of the three policies mentions the reporting service, none grants it access to customer data directly, and each account passed its last access review because reviewers looked at one account at a time.

An attacker who compromises the reporting service, through a vulnerable dependency say, does not need to escalate privileges. They assume the first role, then the second, and read production customer records from an account the reporting team has never heard of. The path exists only when the trust policies are evaluated as a chain. It appears in no dashboard, no policy diff and no permission set, which is why it has survived three audits.

Why it happens

• Trust is configured per account and reviewed per account. Cross-account access is a graph problem, and it is being audited with per-node tools.
• Migration roles outlive migrations. Temporary trust policies are rarely scoped to a date, a condition or a session tag, so they quietly become permanent edges.
• Role chaining hides the principal. Logs in the customer-data account show the intermediate role, not the reporting service that started the chain, so usage reviews attribute the access to the wrong identity.
• Declared permissions lie by omission. A policy review answers what a role allows, not who can become that role, which is the question that matters for lateral movement.

How Trustivan helps

• Evaluate effective access across accounts. The identity graph reads trust policies and role assumptions from each connected AWS account into a reachability graph, recording conditions without evaluating them, so the reporting service's path to customer data can be walked end to end.

  Available

• Name the path, hop by hop. The evidence shows each role in the chain, the trust statement that permits the hop and any condition or external ID attached to it, recorded as written rather than evaluated.

  Available

• Attribute activity to the originating identity. No connector collects assume-role events yet. Stitching them across accounts, so usage reviews see the reporting service rather than the role it became, is a future capability.

  Future capability

• Rank by reachability, not just entitlement. Findings on high-impact access carry the reach behind them, so a low-privilege service with a path to customer data surfaces with its evidence rather than hiding behind its own policy.

  Available

• Cut the edge with evidence attached. A permission removal is proposed with the trust statement and, for roles, the last use AWS reports, then approved by a second person. Nothing executes it at the provider; the change is made in AWS.

  Available

What the evidence looks like

A transitive-access finding must show the whole chain, or the team that owns the first hop will rightly say the problem is not theirs. Illustratively:

Related capabilities

• Access Intelligence — access paths, cross-account trust and reachability computed on the graph
• Effective Access — who can become which role, and what that role can reach
• Identity Graph — trust relationships as edges you can traverse and query
• Blast Radius — the data exposed at the end of the chain
• Cloud environments — multi-account trust, role assumption and federation