auditing-cross-account-role-trust-boundarieslisted

# Auditing cross-account role trust boundaries: when the trust policy lets the wrong caller in A role's trust policy decides who may assume it, and in a multi-account or partner setup that policy is the whole boundary between organizations. It fails in quiet ways. A principal element written as a wildcard, or as an entire account rather than a specific role, lets any identity in that account assume the role. A third-party integration role that omits or does not verify an external ID is open to the confused-deputy attack, where the vendor is tricked into assuming your role on an attacker's behalf. And assumption chains, where one role assumes another, can carry a low-privilege origin into high-privilege territory the trust policies never meant to connect. You audit these by reading each trust policy for who it actually admits and by following where an admitted principal can go next. ## When to use - Roles in one account can be assumed from another account, a partner organization, or a third-party vendor. - A trust policy uses a broad principal, or a third-party role relies on an external ID for scoping. - One assumed role can assume another, forming a chain that may reach privileges the origin should not. ## Scope check Test role assumption only in accounts and organizations you own or are authorized to assess. A confirming assumption obtains real credentials in the target account, so stay inside the authorized accounts and never assume a role belonging to an organization