An IAM inventory does not answer the right question
In a single account, asking who can do what is already hard. In AWS Organizations the question changes shape: who can reach what, through which roles, from which account, with what practical outcome.
Documented policies, attached permissions and trust policies exist. What is often missing is the graph of effective paths between them. A well-meant sts:AssumeRole in a member account can be the next hop from an identity nobody reviewed as a whole.
Risk does not always show up as one oversized JSON policy. It shows up as a chain.
Why multi-account organisations hide paths
AWS Organizations introduces structural trust: cross-account access roles, management accounts, SCPs, delegated administrators, Identity Center, org-scoped Access Analyzer. Each piece makes sense alone. Together they define a perimeter that is rarely drawn in full.
Common patterns in reviews:
- broad trust policies or weak conditions between accounts
- jump roles used by pipelines or vendors that accumulate reach
- privileges in the management account that are not subject to the same SCPs as member accounts
- paths that only appear when IAM inventory is combined with organisation relationships
Without that map, security teams respond with local controls. An attacker, or an auditor, thinks in routes.
What STRAP contributes
STRAP is TechRebel internal tooling for analysing attack paths at AWS organisation scale. We use it in cloud security engagements and make it available to clients when the problem is understanding effective access beyond a single account.
It does not replace IAM Access Analyzer or a policy inventory. It complements those sources with a path-oriented reading: identity to identity, account to account, up to privileges that matter to the business.
The useful output is not an endless finding list. It is a prioritised set of routes that explain how someone with a foothold in one place can reach another.
How it fits an engagement
In AWS & Cloud Security work we usually start from three layers:
- posture and coverage (accounts, regions, logging, baseline controls)
- effective access (roles, trusts, cross-account paths)
- prioritisation (which routes matter and which remediations are realistic)
STRAP mainly feeds the second. It helps turn “we have many policies” into “these are the routes to cut first”.
What we do not promise
No tool removes the complexity of a large AWS organisation. STRAP does not invent a secure posture by itself. It depends on agreed read scope and credentials, inventory quality and human decisions about what to fix.
Its value is making visible paths that account-by-account design tends to leave off the radar.
To review effective access in your AWS organisation, book a meeting or see more context on Research.