Yes. GitHub's guides for AWS, Google Cloud, and Azure all say you must define at least one condition in the cloud trust, so untrusted repositories cannot request access tokens for your resources. Without a condition, the token issuer alone proves nothing about which repository is calling.
Why the issuer is not enough
The GitHub token issuer signs tokens for every repository on GitHub, not just yours. If your cloud role says only "trust tokens from this issuer", then a token minted for someone else's repository satisfies it. The condition is what narrows "any GitHub job" to "this job in my repository".
Think of the issuer as a passport office and the condition as the border officer asking who you are and where you are going.
How each cloud expresses it
| Provider | Where the condition lives | Typical fields |
|---|---|---|
| AWS | Role trust policy | The aud and sub condition keys under token.actions.githubusercontent.com |
| Google Cloud | Workload identity provider attribute condition, plus the service account binding | Mapped attributes such as the subject or repository |
| Azure | Federated credential on the Entra application | Issuer, subject, and audience |
For AWS, the recommended audience is sts.amazonaws.com when using the official action, and the sub key is token.actions.githubusercontent.com:sub. GitHub's Google Cloud guide says you create an identity pool, configure the mapping and add conditions, then connect the pool to a service account that holds the roles/iam.workloadIdentityUser role. For Azure, the guide recommends api://AzureADTokenExchange as the audience value.
A cross cloud checklist
- Open the trust definition for each role, provider, or application that accepts GitHub tokens.
- Confirm an audience condition exists and matches the value the login action uses.
- Confirm a subject or repository condition exists and names your repository, not a pattern that includes others.
- Check for wildcards. A match on the whole repository allows every branch and pull request.
- Check Dependabot. GitHub notes that Dependabot update jobs have the event name set to dynamic, so if your provider supports event name conditions, allow only the event names your workflows expect.
- Remove unused providers and roles. Each one is a standing way in.
- Run a negative test from a repository you do not own, or from a feature branch, and confirm the login is refused.
GitLab and other issuers
The same principle applies to any CI issuer. GitLab's guidance says third party services can reject tokens that do not match their bound audience, and recommends including stable identifiers such as the project id and namespace id alongside the subject. Names can change; identifiers stay put.
What a condition cannot do
A condition proves where a token came from. It does not limit what the role can do once assumed. Give each role only the permissions the job needs, and split roles so a read only task never holds deploy rights.
Quick check
Is one condition enough?
It is the minimum GitHub requires. A tight setup combines audience, subject, and sometimes the event name, with exact matches.
Does Azure use the same sub formats as AWS?
The GitHub subject claim is the same, but each provider writes the condition differently. Check the provider's own documentation for the exact syntax.
Safeguard asset discovery can help you list repositories and pipelines in scope for a review like this, and compliance and evidence automation can keep the results as evidence. A free scan is at gold.safeguard.sh/scan.
Sources
- GitHub Docs: OpenID Connect in Amazon Web Services
- GitHub Docs: OpenID Connect in Google Cloud Platform
- GitHub Docs: OpenID Connect in Microsoft Azure
- GitHub Docs: OpenID Connect reference
- GitLab Docs: ID token authentication
Last reviewed: 19 October 2026.
