Which OIDC claim mapping strategy prevents privilege escalation in multi-tenant GitHub organizations?

Implementing least-privilege authentication in GitHub Actions via OpenID Connect (OIDC) allows workflows to exchange short-lived tokens for cloud IAM roles. This removes the need for long-lived secrets but introduces complexity in trust relationship configuration.

In a multi-tenant organization with numerous repositories, a broad trust policy based only on the organization claim can allow any repository in the org to assume a sensitive role. Conversely, mapping every single repository to a unique role creates significant administrative overhead.

When using the permissions key to restrict the GITHUB_TOKEN, the cloud provider still relies on the OIDC token claims to verify identity. There is a design tension between maintaining granular security and ensuring scalable role management.

• What is the most secure method for mapping the sub claim to ensure only specific branches or environments can assume a role?
• Does GitHub provide a mechanism to group repositories into logical sets for OIDC trust policies without creating individual IAM roles for each?