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

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.

Why This Matters for Security Teams

Trusting a specific AWS principal is often treated like scoping access to a single role, but the real trust boundary is broader: the account, its IAM paths, its automation, and anything that can mint, assume, or attach privileges around that role. That is why identity reviews anchored only on the named principal miss the surrounding attack surface. NIST’s NIST Cybersecurity Framework 2.0 emphasises governance and access management as system properties, not isolated objects.

This distinction matters because attackers rarely need the exact principal a defender expects. In AWS, permissions can be inherited, chained, delegated, or altered through adjacent identities, policies, or CI/CD automation. NHI Management Group research has shown that NHIs are often overprivileged and poorly rotated, which means the named role may be only one path into a much larger trust relationship. In practice, many security teams discover this only after an assumed-safe role has already been reached through another identity in the same account, rather than through intentional review of the whole trust boundary.

How It Works in Practice

The practical mistake is confusing an AWS principal with an isolated security object. A role trust policy may specify who can assume it, but the effective exposure also depends on policies attached to the account, permissions boundaries, session policies, resource-based policies, and automation that can change any of the above. If another principal in the same account can create access keys, alter trust relationships, or pass the role to a workload, the defended “one role” is not the full boundary.

Defenders should treat the account as the unit of analysis and map every path that can influence the trusted principal:

• Who can assume the role, directly or indirectly?
• Who can edit the trust policy, permission policy, or inline policy?
• What CI/CD, Terraform, Lambda, or deployment automation can attach or swap credentials?
• What resource policies, cross-account trusts, or federation paths expand access beyond the named role?

That is also why NHI visibility matters. NHI Management Group notes that only 5.7% of organisations have full visibility into service accounts in its Ultimate Guide to NHIs, and gaps like that make it easy to overlook adjacent identities with the power to reach a trusted principal. For AWS-specific attack patterns, the 230M AWS environment compromise research is a useful reminder that broad account-level exposure is often the real problem, not the named identity alone. These controls tend to break down in accounts with delegated admin, CI/CD-driven privilege changes, or multiple teams sharing IAM ownership because the trust graph changes faster than manual review cycles.

Common Variations and Edge Cases

Tighter principal-level trust often increases operational overhead, requiring organisations to balance narrower access with account-level governance and faster change control. There is no universal standard for this yet, but current guidance suggests the safest approach is to assume any identity that can modify IAM, infrastructure-as-code, or session issuance inside the account can become part of the trust boundary.

Two edge cases matter especially:

• Cross-account access: a role in one account may be “trusted” by another account, but that trust is only as strong as the source account’s identity hygiene and admin paths.
• Automation-heavy environments: if pipelines, bots, or agents can deploy code or change policies, the named principal may be protected while the surrounding automation silently widens access.

This is why the AI LLM hijack breach research is relevant even outside pure AI workloads: once an attacker gains a foothold in the account, they can chain identities and permissions in ways that make the original trust assumption obsolete. For teams using zero trust language, the Codefinger AWS S3 ransomware attack material reinforces the same lesson: trust has to be bounded by continuously evaluated context, not by a single named principal.

Related resources from NHI Mgmt Group

• What do organisations get wrong about trusting signed packages and tools?
• What do security teams get wrong about n8n and similar automation platforms?
• What do organisations get wrong about segregation of duties in federated environments?
• What do organisations get wrong about automated data classification?