If an AWS role trusts GitHub with a wildcard such as repo:octo-org/octo-repo:*, then any workflow in that repository can assume it: any branch, any pull request merge ref, any environment. Anyone who can run a workflow there gets the role's permissions. Tighten the sub condition to one environment or one ref.
Definition
An IAM trust policy decides who may assume a role. For GitHub, you add GitHub's token issuer as an identity provider and write conditions on two claims. The audience (aud) should be sts.amazonaws.com when you use the official action. The subject (sub) says which repository and context is allowed.
AWS recommends evaluating the sub condition key in any role trust policy that trusts GitHub's provider. GitHub's own guide says you must define at least one condition, so untrusted repositories cannot request tokens for your resources.
What the wildcard actually allows
GitHub's AWS guide gives the exact example. With StringLike, a value of repo:octo-org/octo-repo:* lets any branch, pull request merge branch, or environment assume the role. Wildcards are possible, but they are broader than they look.
| Sub condition | Who can assume the role |
|---|---|
| Exact: repo:ORG/REPO:ref:refs/heads/main | Jobs on main without an environment |
| Exact: repo:ORG/REPO:environment:prod | Jobs attached to the prod environment |
| Wildcard: repo:ORG/REPO:* | Every branch, pull request, environment, and tag in the repo |
Why this matters in a real workflow
Think about who can open a pull request in your repository. If workflows run on pull requests from branches in the same repository, a contributor can edit the workflow file in their branch and request a token. With a wildcard trust rule, that token is accepted, and the role's permissions are now reachable from a branch that nobody reviewed.
Branch protection and review rules help, but the token request happens before any merge. The cloud side rule is the last line of defense.
How to tighten it
- Find every role that trusts the GitHub provider. In the IAM console, check the trust relationships of each role.
- Read the sub condition. Replace StringLike wildcards with StringEquals on an exact value where you can.
- Prefer the environment form, and attach that environment to a branch rule so only the right refs can use it.
- Split roles by purpose. A read only role for pull requests, a deploy role for production. Never one role for everything.
- Keep the permissions small. A tight trust rule on an administrator role is still a large prize.
- Test the negative case: run a job from a feature branch and confirm the assume role call is refused.
When a wildcard is acceptable
A wildcard on the repository suffix can be fine for a throwaway sandbox account where the role can do nothing valuable. Write down why, so the next reviewer knows it was a choice.
Quick check
Does branch protection stop a feature branch from requesting a token?
No. Branch protection governs merges. A workflow running on a branch in the same repository can request a token; the trust rule is what refuses it.
Do I need the audience condition as well?
Use both. The audience pins the token to the intended service and the subject pins it to the intended workflow context.
Safeguard policies and gates can flag pull requests that change workflow files, and asset discovery helps you find the repositories and pipelines that hold cloud access. A free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
