Auditing Cross Account Role Trust Boundaries

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 outside your engagement. If you can't name the authorization, stop.

The loop

1. Establish the intended trust relationship first. For each cross-account role, name who is supposed to assume it and why: which specific partner role, which service, which internal account. This is the false-positive killer: a trust policy that admits exactly the intended principal under the intended conditions is correct even in a sprawling multi-account setup. Name the intended relationship, then read the policy against it.

2. Read the principal element for who it actually admits. A trust policy naming an entire account as the principal admits every identity in that account, not just the intended role. A wildcard principal admits anyone, gated only by whatever conditions follow. Determine the true set of principals the policy allows, not the one the author had in mind.

3. Check third-party roles for external-ID enforcement. A role a vendor assumes on your behalf must require an external ID that the vendor sets per customer and that an attacker cannot guess or supply, otherwise the vendor can be induced to assume your role for someone else. Confirm the trust policy requires the external ID as a condition and that the value is unique and secret to your relationship, not a shared or predictable string.

4. Confirm the conditions actually scope the assumption. Condition keys on the trust policy (source account, source identity, external ID, network conditions) are the difference between a broad principal and a safe one. Read whether the conditions are present, whether they use the correct keys, and whether they can be satisfied by an attacker. A condition that references a spoofable or caller-controlled value does not scope anything.

5. Follow the assumption chain. Where an assumed role can assume a further role, trace the chain to its end and ask whether the origin principal should be able to reach the final role's privileges. A chain that lets a partner or a low-privilege account step through intermediate roles into administrative access is a trust-boundary break even when each individual policy looks reasonable.

6. Confirm and record. Confirm by assuming the role from a principal that should not be admitted (within owned accounts), or by demonstrating a chain that carries an origin to privileges beyond its intended reach, without touching accounts outside the engagement. Kill the lead if every trust policy admits only the specific intended principal, third-party roles require a unique secret external ID, conditions scope the assumption to unspoofable values, and no chain reaches unintended privilege. Record the admitted principal, the assume-role sink, and the trust scope beyond intent.

Where cross-account trust boundaries leak

• An account-wide principal admits everyone in that account. Naming the account instead of the specific role grants assumption to every identity it contains.
• A missing external ID is a confused-deputy opening. Without it, a vendor can be induced to assume your role for an attacker's benefit.
• A wildcard principal relies entirely on the conditions. If the conditions are absent or spoofable, the role is effectively open.
• Assumption chains connect trust domains the policies never meant to link. A safe-looking pair of policies can compose into an origin-to-admin path.
• A predictable external ID is no boundary. If the value is shared, guessable, or attacker-suppliable, it does not scope the third-party assumption.

Worked example (a confirm and a kill)

Confirm. A data-integration role trusts a vendor account but omits the external-ID condition. Because the vendor assumes the role for many customers, an attacker who is also a vendor customer induces the vendor to assume this role on their behalf, obtaining credentials in the target account. Confirmed confused-deputy cross-account assumption, high, remediation = add a required external-ID condition to the trust policy with a value unique and secret to this relationship, and confirm the vendor sends it on every assume-role call.

Kill. Every cross-account role names the specific partner role as principal, third-party roles require a unique secret external ID as a condition, and no assumed role can chain into privileges beyond its intended reach. An assumption attempt from any other principal, or without the external ID, is denied. Killed, kill_reason = "trust policies admit only the specific intended role under a unique-external-ID condition and no chain reaches unintended privilege; no unadmitted principal can assume the role."

Rationalizations to reject

• "Only our partner's account is trusted." → Naming the account admits every identity in it; scope the principal to the specific role, not the whole account.
• "The external ID is set, so it is safe." → Confirm it is unique and secret to your relationship; a shared or guessable value provides no scoping.
• "Each policy is fine on its own." → Trace the chain; safe individual policies can compose into an origin-to-admin path.
• "The condition restricts it." → Confirm the condition uses the correct key and an unspoofable value; a condition on a caller-controlled field is not a boundary.
• "It is inside our organization." → Cross-account within one organization still crosses a trust boundary; the trust policy is the control regardless.

Executing this in practice

You need each cross-account role's trust policy, the intended principal for each, what the principal element actually admits, the external-ID and condition scoping on third-party roles, and the assumption chains that lead onward. For each role, compare the admitted set to the intended relationship and follow where an admitted principal can chain. Reading the policy shows who is meant to assume; assuming from an unintended principal in an owned account shows whether the boundary holds.

Related

• hunting-iam-privilege-escalation-paths - the in-account escalation companion; a cross-account entry often lands on a role that then escalates within the target account.
• mapping-service-account-impersonation-chains - the same assumption-chain reasoning in cloud identity, where impersonation rather than assume-role carries the principal onward.
• auditing-cicd-oidc-trust - a federated CI principal assuming a cloud role is a cross-account trust with the same subject-scoping requirements.
• adjudicating-taint-paths - use it to trace an admitted principal through an assumption chain to a privileged final role.
• FINDING-SCHEMA.md - source = the external principal the trust policy permits, sink = the assume-role grant, evidence = the trust scope beyond the intended relationship.