After you merge repositories, cloud roles that trust GitHub OIDC tokens by repository name stop matching, because the token now names the monorepo. Do not fix that with a wildcard. Update each trust rule to the new repository plus an environment or branch condition, so each service still gets its own narrow role.
What the token says
GitHub's OIDC documentation shows the token a job receives. It is a JSON web token, unique for each workflow job. The example uses a subject like repo:octo-org/octo-repo:environment:prod, and also carries claims for the repository, owner, ref, workflow and more. The cloud provider checks whether the subject and other claims match the conditions set on the role's trust definition.
Before the migration, each service had its own repository, so a role trusted repo:acme/payments:... and another trusted repo:acme/search:.... The repository name quietly separated services from each other.
What breaks
After the move, every job runs in repo:acme/platform. Old trust rules never match, and deploys fail with an authentication error. The tempting fix is to trust the whole repository for every role. That makes any workflow in the monorepo able to assume any service's role, including one added by a contributor who should only touch docs.
A safer pattern
- List every cloud role with a GitHub trust rule. Cloud audit logs show which roles were assumed from GitHub recently.
- For each role, decide which service it belongs to and which environment it serves.
- Add a GitHub environment per service and stage, for example
payments-prod. The subject then includes the environment name, as in the documentation example. - Change each trust rule to match the new repository and that exact environment value.
- Put required reviewers on the production environments, so the token for prod is issued only to an approved job.
- Remove the old rules after a successful deploy from the monorepo.
| Trust condition | Result in a monorepo |
|---|---|
| Repository only | Any workflow can assume the role |
| Repository plus branch | Narrower, but one branch covers all services |
| Repository plus environment | One role per service and stage |
Custom claims
The documentation also describes adding custom repository properties to the token claims at the organization or enterprise level. That can help with grouping, though a clear environment name is simpler to reason about and review.
Test the failure case
A good test is a negative one. Open a workflow on a branch that references the wrong environment and confirm the cloud provider refuses it. If it succeeds, the rule is too loose. For more on the ownership side, see who gets write access when repositories merge.
Safeguard's policies, gates and guardrails can enforce checks on the changes that touch workflow files, which is where these identities are defined.
Quick check
Can I trust the repository name alone in a monorepo?
It works, but it lets every workflow in that repo use the role. Add an environment or similar condition to keep services apart.
Does OIDC remove the need to migrate secrets?
For cloud access, mostly. You migrate a trust rule instead of a stored credential, and tokens last for a single job.
Sources
Last reviewed: 19 October 2026.
