# Restrict who can supply AWS session tags used for authorization

> Treat permission-bearing session attributes as controlled inputs.

- Canonical URL: https://update.dsesecurity.com/updates/restrict-who-can-supply-aws-session-tags-used-for-authorization/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-10-20T18:13:32+00:00
- Modified: 2026-10-20T18:34:28+00:00
- Last reviewed by DSE: 2026-10-20
- Resource type: Guide
- DSE priority: Information
- Topics: Cybersecurity, IT
- Reading time: 2 minutes

## What you need to know

Treat permission-bearing session attributes as controlled inputs.

## Potentially affected

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.

## Article

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](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html).

## 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html). Reviewed October 20, 2026.

## Primary reference

- Name: AWS Documentation
- Authority: docs.aws.amazon.com
- URL: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Restrict who can supply AWS session tags used for authorization,” DSE Security, https://update.dsesecurity.com/updates/restrict-who-can-supply-aws-session-tags-used-for-authorization/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.