Cross-account AWS trust policies create hidden privilege paths

At a glance

What this is: This is an analysis of four misconceptions about AWS cross-account trust policies and how they create hidden privilege escalation paths.

Why it matters: It matters because IAM teams, cloud security leads, and PAM governance owners must treat cross-account trust as a hierarchy problem, not a simple permissions exercise.

👉 Read Token Security's analysis of secure cross-account access misconceptions

Context

Cross-account trust in AWS is the practice of allowing one account or role to assume a role in another account through IAM trust policies. The security problem is that trust is often granted across accounts with very different protection levels, which turns a working configuration into an escalation path.

That matters directly to IAM, NHI, and cloud governance programmes because a role in one account can become the entry point into a more sensitive account if trust flows in the wrong direction. In practice, cross-account access becomes a question of identity boundary design, not just policy syntax.

Key questions

Q: How should security teams govern AWS cross-account trust policies?

A: Security teams should govern AWS cross-account trust as a hierarchy problem, not a simple permission setting. Each trust path should be reviewed for source account sensitivity, destination account sensitivity, and the downstream privileges it unlocks. The safest pattern is downstream-only trust, where less secure accounts never assume roles in more sensitive environments.

Q: Why do cross-account roles increase privilege escalation risk in AWS?

A: Cross-account roles increase privilege escalation risk because a trusted principal can become an entry point into the trusting account, and often into additional roles inside it. If the trusted account is weaker, any compromise there can cascade into the sensitive account. The risk is account-level, not role-level.

Q: What do organisations get wrong about trusting a specific AWS principal?

A: They assume the trust is limited to one named role, when the effective trust boundary is the account that contains it. Other identities, policies, or automation in that account may be able to reach the role, so the trusted account's whole security posture matters. One principal is never the whole risk picture.

Q: Who should approve cross-account access into management accounts?

A: Only teams that own the highest-sensitivity AWS identity controls should approve that access, because the management account can affect the entire organisation. Any exception should require explicit business justification, compensating monitoring, and a review of the trusted account's posture before the trust is granted.

Technical breakdown

How AWS IAM trust policies create cross-account access

An AWS IAM trust policy defines which principal can assume a role. When the principal lives in another account, the role becomes a cross-account entry point, and the trusting account inherits the security posture of the trusted side. The key technical point is that a trust policy is not an isolated permission. It is a delegation mechanism that expands the reachable attack surface through AssumeRole, permission enumeration, and downstream role chaining. Once a compromised principal can assume the role, the attacker operates inside the target account under legitimate identity.

Practical implication: map every cross-account trust relationship to the full downstream privilege set it unlocks.

Why trusted principals inherit the risk of their entire account

Trusting a specific role is not the same as trusting only that named identity. In real AWS environments, multiple users, automation paths, or policies may be able to reach that role, so the effective trust boundary is the entire account that contains it. That means weak controls in the trusted account, such as permissive IAM policies or poor monitoring, can undermine the security of the account doing the trusting. This is why cross-account trust must be reviewed as an account-level exposure, not a single-principal exception.

Practical implication: assess the security posture of the whole trusted account before approving cross-account access.

Why management account trust is the highest-risk pattern

The management account in AWS controls the organisation itself, so it sits above production, logging, and development accounts in the sensitivity hierarchy. If a lower-security account can assume a role in the management account, the attacker is no longer limited to a workload or application. They can potentially reach organisation-wide control paths. The technical issue is directionality: trust must follow the security hierarchy, not convenience. Any inverse flow creates a path where a compromise in a weaker environment can become a full organisational takeover.

Practical implication: prohibit trust paths from lower-security accounts into management or other higher-sensitivity accounts.

Threat narrative

Attacker objective: The attacker wants to turn one compromised account into broader AWS organisational control by abusing trust relationships to move into higher-value environments.

1. Entry begins when an attacker compromises a less secure AWS account that already has cross-account trust into a more sensitive account.
2. Escalation occurs when the attacker assumes the trusted role and uses the target account's own IAM policies to enumerate permissions and pivot further.
3. Impact follows when the attacker reaches production, logging, or management-level resources and can modify policies or access sensitive data across accounts.

Breaches seen in the wild

• Azure Key Vault privilege escalation exposure — Azure Key Vault Contributor role misconfiguration enabled privilege escalation.
• Codefinger AWS S3 ransomware attack — Codefinger used compromised AWS credentials to encrypt S3 buckets via SSE-C.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Cross-account trust is an identity boundary problem, not a configuration problem. A trust policy can be syntactically correct and still create the wrong security outcome if the direction of trust violates the account hierarchy. The field often treats trust as a permissions object, but the real issue is whether one account is allowed to inherit the risk of another. Practitioners should evaluate cross-account access as delegated blast-radius design, not as a rule syntax check.

The management account is the apex of AWS identity risk, not an administrative convenience layer. Organisations that harden production while leaving organisation control paths comparatively weaker are building the wrong risk model. A compromise at the management layer changes the entire control plane for every other account. IAM and cloud security teams should treat the management account as the highest-value identity asset in the AWS estate.

Downstream-only trust should be the default assumption for sensitive environments. When a less secure account can reach a more sensitive one, the trust policy is no longer supporting segmentation. It is encoding escalation. The practical conclusion is that account topology must be designed around sensitivity hierarchy, because cross-account access from weaker to stronger domains collapses the separation that IAM was meant to preserve.

Identity blast radius is the right named concept for cross-account AWS governance. A role does not just carry its own permissions. It carries the reachable set of assumptions, policies, and downstream paths behind it. That means the true control question is how far an attacker can move once one trusted account is touched. Practitioners should model blast radius at the account boundary, not only at the role boundary.

From our research:

• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded, according to The State of Secrets Sprawl 2026.
• 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks.
• Cross-account trust and secrets sprawl often intersect, so teams should pair trust-policy review with the Guide to the Secret Sprawl Challenge when they assess where credentials and delegation paths overlap.

What this signals

Identity blast radius should become the organising concept for AWS governance reviews. If a lower-security account can assume a role in a higher-sensitivity account, the issue is no longer least privilege at the role level. It is the size of the trust corridor the organisation has opened between security domains.

With 28.65 million new hardcoded secrets detected in public GitHub commits in 2025 alone, according to The State of Secrets Sprawl 2026, identity compromise is still being industrialised through exposed credentials and overextended trust paths.

Teams that already use the NIST Cybersecurity Framework 2.0 can map cross-account trust review to the Protect function, but the practical test is whether the trust boundary follows environment sensitivity instead of convenience.

For practitioners

• Inventory every cross-account trust path Document which roles can be assumed across accounts, then classify each path by source account sensitivity, destination account sensitivity, and the business reason for the trust. Include dev, test, logging, and automation accounts, not just production.
• Block upward trust into sensitive accounts Revise trust policies so that less secure accounts cannot assume roles in management or other higher-sensitivity environments unless there is an explicit, time-bound exception with compensating controls.
• Review trusted accounts as whole security domains Assess the security posture of the full trusted account, including its IAM policies, monitoring, and role assumption paths, before approving cross-account access from a more sensitive account.
• Align cross-account access with sensitivity hierarchy Allow trust to flow only downstream in the hierarchy, so the most sensitive accounts remain the hardest to reach and the least secure environments never become an escalation bridge.

Key takeaways

• AWS cross-account trust becomes dangerous when it lets weaker accounts reach stronger ones.
• The real risk is account-level exposure, because a trusted principal often carries the security weaknesses of its whole account.
• Practitioners should enforce downstream-only trust and treat the management account as the highest-value identity boundary.

Key terms

• Cross-Account Trust: Cross-account trust is an AWS delegation pattern that allows a principal in one account to assume a role in another. It is useful for automation and shared services, but it also expands the effective trust boundary to include the security posture of the trusted account.
• Trust Boundary: A trust boundary is the point where one identity domain begins relying on another domain's controls. In AWS cross-account access, the boundary is not just the role policy. It includes the source account's users, roles, monitoring, and any path that can reach the trusted principal.
• Identity Blast Radius: Identity blast radius is the amount of access, systems, and control an attacker can reach after compromising one identity. In cross-account AWS environments, it describes how far a compromised role can move across accounts, roles, and sensitive resources before containment is possible.

What's in the full article

Token Security's full blog post covers the operational detail this post intentionally leaves for the source:

• The specific AWS trust-policy examples used to illustrate each misconception.
• The step-by-step reasoning behind why a trusted principal often exposes the whole account.
• The account hierarchy patterns the vendor uses to separate management, production, logging, and development risk.
• The follow-on example promised by the vendor showing how AWS itself got cross-account trust wrong.

👉 The full Token Security post breaks down the four misconceptions and the trust-policy patterns behind them.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.