What is the difference between updating a trust policy and attaching a policy in AWS?

Why the distinction matters in AWS permissions work

In AWS, a trust policy controls who can assume a role, while an attached permission policy controls what the role or identity can do after access is granted. That distinction matters because the first is an entry decision and the second is an entitlement decision. A role can have very limited permissions and still be dangerous if its trust policy admits the wrong principal.

For practitioners, the practical split is between who gets in and what they can do once in. A trust policy is evaluated during role assumption, typically through STS, so it governs the security boundary at the moment credentials are issued. An attached policy is evaluated during API authorization, so it shapes the blast radius after the principal is already authenticated and operating.

How trust policy changes differ from attached policy changes

Updating a trust policy changes the set of principals that AWS will accept as callers for the role. That can include users, roles, federated identities, services, or other AWS accounts depending on the role design. In effect, you are changing the entrance conditions for the role, which is why trust policy mistakes often create immediate escalation paths or cross-account exposure.

Attaching or editing a permission policy changes the actions and resources allowed to the role or identity after it exists. It does not decide whether the caller may assume the role in the first place. If the attached policy is broadened, the identity gains more operational capability, but only within the access path already granted by authentication and trust.

The easiest way to think about it is this: trust policy governs assumption; attached policy governs authorization. When AWS permissions reviews go wrong, teams often confuse those two layers and either over-focus on actions while missing who can assume the role, or tighten trust while leaving overly broad permissions in place.

Why these changes can create escalation paths

The security impact is different even though both are policy changes. A trust policy update can let a new principal step into the role, which means the attacker or unintended actor may inherit every permission already attached to that role. That is why role trust edits are often the higher-risk change: they can turn a previously unreachable role into an active access path.

An attached policy change is usually less explosive than a trust policy change, but it still matters because it can widen the role’s effective reach after assumption. If the role is already assumable, a broader permission policy can expose sensitive data, allow destructive actions, or enable lateral movement through AWS services and resource relationships.

In both cases, the real question is not only whether the policy is syntactically valid. It is whether the change alters the trust boundary, the effective privilege set, or the blast radius of a principal that can already act inside the account or across accounts.

Risk and Threat Considerations

Trust policy changes are especially sensitive because they can open or expand the path into a role, not just the actions available after entry. If a compromised account, federation path, or external principal is added to the trust relationship, the result can be direct privilege escalation through role assumption rather than through permission abuse alone.

Failure mechanism: The trust relationship is broadened so an unintended principal can call STS and obtain the role’s temporary credentials. Once that happens, any attached permissions become available to the caller within the scope of the role.

Impact: Attackers or mistaken administrators can gain access that looks legitimate to downstream systems, making the change harder to notice and easier to abuse for data access, infrastructure changes, or cross-account movement.

Practitioner Guidance

What to verify: Before approving a trust policy edit, verify the exact principal, the assumption path, and whether the role is cross-account, federated, or service-assumed. For attached policies, verify the affected actions, resources, and whether the policy creates wildcard access or new write capabilities.

Decision rule: If the change alters who can assume the role, treat it as a trust-boundary change and review it more strictly than a routine permission adjustment. If the role already has broad attached permissions, a small trust change can be more dangerous than a large-looking permission edit on a low-value role.

What good looks like: Trust policies are tightly scoped to named principals and assumption conditions, while attached policies follow least privilege and are reviewed separately. The cleanest control state is when a reviewer can explain both the entry path and the post-assumption capability without ambiguity.

Practitioner takeaway: In AWS, trust policy edits change who can become the role, while attached policy edits change what that role can do; the first is usually the more sensitive escalation surface because it controls access to the role itself.

Related resources from NHI Mgmt Group

• What is the difference between an AWS role trust policy and a permission policy?
• What is the difference between attack surface management and NHI governance?
• What is the difference between reviewing human access and reviewing NHIs?
• What is the difference between role-based access and API key governance for NHI security?