How cross-account trust creates exploitable privilege boundaries

Cross-account role assumption requires successful evaluation of both the identity policy on the source principal and the trust policy on the target role. The trust policy dictates which external principals are authorized to assume a role, making it a primary control for account isolation. Both evaluations must succeed for the action to be permitted, and authorization is limited by the weakest policy evaluated.
The concept of an authorization boundary shifts from being identity-centric within an account to resource-centric across accounts. While identity policies define internal permissions, trust policies determine external access rights. Misconfigurations in trust policies can weaken account isolation if they allow broad principals, leading to potential privilege escalation across boundaries.
Exploitable trust boundaries arise from patterns like using overly broad principal specifications, omitting condition keys, or referencing stale external account references. These failures can enable scenarios where an identity with limited permissions in one account assumes a highly privileged role in another by exploiting the delegation of authority in the trust relationship.

* Cross-account AssumeRole requires evaluation of the identity policy on the source principal and the trust policy on the target role ARN.
* Action is denied if either policy evaluation fails.
* The authorization boundary is as strong as the weakest policy.
* Trust policies specify which external principals are authorized to assume a role.
* Evaluation of the trust policy occurs on the target side and is independent of identity policy evaluation on the source side.
* Overly broad principal specifications, missing condition keys, or stale external account references create exploitable trust boundaries.
* Trust policies referencing account root do not grant unconditional assumption privileges; exploitation requires source-side permission.
* Missing condition keys allow any matching principal with source permissions to assume the role regardless of context.
* External account ownership verification is not part of standard identity permission audits.
* Resource-based policy grants (S3, Secrets Manager) can grant cross-account access independently of IAM role policies.

The tension in this information lies between the traditional focus on identity permissions and the necessity of managing trust relationships for cross-account access. Standard security reviews focusing solely on identity policies miss critical authorization vectors residing in trust policies, creating a significant blind spot in governance. The primary pattern observed is that control over cross-account boundaries shifts from explicit permission granting to implicit delegation of trust.
The existence of the confused deputy problem highlights a systemic risk where an external service's ability to assume roles can be leveraged across organizational boundaries if safeguards like external ID conditions are omitted. This suggests that controls must extend beyond the immediate resource being accessed to govern the entire chain of delegation, including the context under which the assumption occurs. The reliance on Security Control Policies (SCPs) as a secondary layer over trust policies illustrates a layered defense, but the priority should remain ensuring the primary trust relationships themselves are correctly defined and audited before relying heavily on compensatory controls like SCPs for containment.
The implication for cognitive sovereignty is that effective security governance requires shifting analytical focus from "what an identity can do" to "who can assume what context," demanding an inventory of all implicit trusts across the enterprise, including resource-based grants. This necessitates moving beyond single-account audits to implement continuous validation mechanisms that trace these external dependencies and ensure that delegation paths are intentional and appropriately constrained by verifiable conditions.
What organizational processes are in place for routinely auditing trust relationships against principles like external ID requirements and account lifecycle status? How does the current identity-centric audit framework need to evolve to incorporate a comprehensive, resource-centric view of authorization boundaries across service identities and resource grants? If an organization prioritizes operationalizing this trust inventory, what new metrics should replace reliance on static permission checks for cross-account security posture?