Cross-account trust
Cross-account trust is a configuration in which a role in one cloud account permits identities from another account to assume it. It is the intended way to separate environments and to grant a supplier access, and it is also the relationship that turns a compromise of one account into a compromise of several.
The trust is expressed as a policy on the role naming who may assume it. Two mistakes make it dangerous. Naming an entire external account rather than a specific role or identity in it, which means anyone who obtains any credential in that account can step across. And omitting the conditions that constrain the assumption, so nothing limits which caller, from where, or under what circumstances.
The supplier case has a specific control that exists for a reason. When a third party manages several customers, an external identifier agreed between the parties and required in the trust policy prevents that third party from being tricked into using its access to your account on behalf of another customer. It is a confused deputy problem, it is documented by the providers, and it is left unset in most of the supplier integrations we review.
The reason this deserves attention over other misconfigurations is direction of travel. Account separation is usually the control an organisation relies on to argue that a development environment cannot affect production, and a permissive trust in the wrong direction removes that argument entirely. Following those edges is what makes a cloud attack path graph useful and what CIEM tooling is meant to surface, and we walk them by hand in the cloud testing where trust relationships are followed across account boundaries.