Restrict who can supply AWS session tags used for authorization

Treat permission-bearing session attributes as controlled inputs.

Source facts

AWS STS can pass session tags and mark selected keys as transitive through role chaining. Relevant role trust policies need sts:TagSession permission. Session tags can override matching tags, and AWS provides conditions to constrain tag keys, values and transitive keys. Tags are therefore part of the authorization design.

Source: AWS Documentation.

Applicability

Apply this to AWS attribute-based access workflows that rely on session tags, including federated role sessions.

DSE recommendation

DSE recommends listing the attributes that influence access and identifying the trusted system permitted to supply each one. Constrain acceptable keys and values in the role trust design instead of allowing callers to assert any department or project. Review whether a tag must survive the next role assumption. Keep authorization attributes separate from free-form reporting labels, and assign responsibility for updating the mapping when the organization changes. Review conflicts between inherited and newly supplied tags before rollout. Include a deliberately conflicting attribute in the design review and write down which source should be authoritative. Have the identity and resource owners agree the expected access result before any test, rather than accepting whichever value appears in a successful session.

Verification

Proposed verification: assume a disposable role with an allowed attribute, a disallowed value and an unexpected transitive key. Follow the intended role chain and confirm the resulting access. Inspect both trust decisions and resource authorization rather than checking only whether a tag appears.

Official reference

AWS Documentation. Reviewed October 20, 2026.