Notifications
Clear all
Topic starter
02/06/2026 8:49 pm
TL;DR: Astrix Security says shared OIDC issuers in GitHub Actions, GitLab CI, and Terraform Cloud can let attackers reclaim deleted namespaces and assume stale cloud roles, with 14% of discovered AWS namespaces and 24% of Azure namespaces already unregistered. The real problem is offboarding failure: identity trust outlives the repository name it depends on.
NHIMG editorial — based on content published by Astrix Security: Sub:jugation and phantom cloud identities in CI/CD OIDC trust
By the numbers:
- In AWS, 14% of discovered namespaces were not registered and available to be taken.
- In Azure, the percentage jumps to 24%.
Questions worth separating out
Q: What breaks when CI/CD OIDC trust still points to a deleted namespace?
A: The cloud role can remain assumable if the deleted namespace is later reclaimed and the subject claim still matches.
Q: Why do reusable repository namespaces create NHI risk in cloud IAM?
A: Reusable namespaces weaken the identity permanence that OIDC trust depends on.
Q: How do security teams know whether OIDC-based roles are actually safe?
A: They should verify that the upstream namespace is still active, still owned by the expected team, and still bound to the intended repository or workflow.
Practitioner guidance
- Review all OIDC trust policies for stale namespaces Inventory every cloud role that trusts token.actions.githubusercontent.com, gitlab.com, or app.terraform.io, then verify that the referenced namespace still exists and is still under your control.
- Offboard abandoned CI/CD-linked cloud roles Disable or remove any cloud role whose subject depends on a repository or namespace that no longer has an active owner.
- Search workflow code for exposed role identifiers Look for id-token: write, role-to-assume, client-id, workload_identity_provider, and similar fields in workflow files.
If a repository name can be reclaimed, the control boundary is no longer the token, it is the continuity of the namespace and the retirement of the cloud role behind it?
👉 Read Astrix Security's analysis of Sub:jugation in CI/CD OIDC trust →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
02/06/2026 8:52 pm
Phantom Cloud Identities are the real control failure here. The trust policy still exists, but the identity it trusts no longer has a legitimate owner. That means standard secrets hygiene is not enough, because the problem is stale federation state rather than exposed static credentials. Teams need to govern the lifecycle of the identity subject, not just the token format.
A few things that frame the scale:
- 28,65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded, according to the State of Secrets Sprawl 2026.
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: Who is accountable when a reclaimed namespace can assume a cloud role?
A: Accountability sits with the team that owns the cloud role, the CI/CD namespace, and the offboarding process that should have removed the trust. Federation makes the control shared, but shared control does not mean shared responsibility. The role owner must prove the trust condition still matches a legitimate active identity.
👉 Read our full editorial: Sub:jugation exposes phantom cloud identities in CI/CD OIDC trust
