Sub:jugation exposes phantom cloud identities in CI/CD OIDC trust

At a glance

What this is: This research describes Sub:jugation, a CI/CD OIDC trust flaw where reclaimable namespaces can be used to mint tokens that still match cloud trust policies.

Why it matters: It matters because IAM teams may believe short-lived OIDC credentials remove the need for lifecycle offboarding, when the real control gap is stale trust in deleted or renamed namespaces.

By the numbers:

• In AWS, 14% of discovered namespaces were not registered and available to be taken.
• In Azure, the percentage jumps to 24%.
• On average a single deleted namespace had more than 12 different NHIs trusting one of its repositories.

Context

Sub:jugation is a trust-reuse problem in CI/CD, where an OIDC subject claim can become reusable after a repository, user, or namespace is deleted or renamed. For IAM teams, the issue is not token strength but whether the cloud role still trusts an identity path that no longer has a legitimate owner.

Astrix Security argues that modern CI/CD OIDC flows create a false sense of permanence because the issuer is global while the subject string is namespace-derived. That makes lifecycle management the weak point: if namespace control changes, the cloud trust decision can still succeed for the wrong party.

The article's core claim is that phantom cloud identities are left behind when cloud roles are never offboarded after a project ends. That is a normal failure mode in immature NHI governance, not an edge case.

Key questions

Q: What breaks when a CI/CD namespace is deleted but its cloud trust remains?

A: The trust relationship outlives the identity source. A cloud role that still accepts an OIDC subject from a deleted namespace can be assumed by whoever reclaims that namespace, which turns a normal lifecycle event into a reusable access path. The failure is stale authorization, not token forgery.

Q: Why do reclaimed OIDC subjects create cloud access risk?

A: Because the cloud provider only sees a matching subject claim, not whether the current namespace owner is the same party that originally configured the trust. If the namespace can be reused, the trust decision can be replayed by a different actor without changing the policy.

Q: How can security teams tell whether CI/CD OIDC trust is becoming stale?

A: Look for deleted, renamed, or abandoned repositories and organizations that still appear inside cloud trust policies. If the subject string points to a namespace that is no longer under active control, the role is no longer tied to a dependable identity relationship.

Q: What should happen when a repository or organization is retired?

A: Every cloud role that trusts that namespace should be reviewed and either removed, retargeted, or revalidated against the new owner. The goal is to prevent a trusted subject from becoming a phantom cloud identity after offboarding.

Technical breakdown

How global OIDC issuers create reusable trust paths

GitHub Actions, GitLab CI, and Terraform Cloud issue OIDC tokens from shared public endpoints, then rely on claims such as sub to distinguish tenants, repositories, and workflow context. Cloud providers validate the signature and then compare those claims against trust policies. If the subject string is built from a namespace that can later be reclaimed, the trust decision still succeeds even though the original owner is gone. The technical weakness is not token forging but namespace recycling combined with trust policies that assume the subject remains stable over time.

Practical implication: cloud trust policies must be reviewed as lifecycle objects, not as static authentication settings.

Why deleted namespaces become phantom cloud identities

A phantom cloud identity exists when a cloud role still trusts an OIDC subject that once belonged to a real repository or organization, but the namespace has been released and can be recreated by someone else. Once the attacker reclaims the path, the OIDC token minted by the CI/CD platform matches the old subject string and the cloud provider sees a valid assertion. This is a lifecycle failure across identity systems: the cloud role persists after the namespace owner has changed, so authentication and authorization remain coupled to a name rather than to a continuing relationship.

Practical implication: offboarding has to cover both the CI/CD namespace and every cloud role that depends on it.

Why short-lived OIDC tokens still leave standing trust risk

OIDC removes long-lived secrets from pipelines, but it does not remove standing trust in the policy that accepts the token. The token may expire quickly, yet the cloud role trust relationship can remain indefinitely unless someone revokes it. That means the attack surface shifts from secret theft to trust reuse. In practice, the security boundary moves from credential storage to identity lifecycle hygiene, which is exactly where many programmes are weakest.

Practical implication: replacing secrets with OIDC is not enough unless trust conditions are continuously revalidated against the live namespace owner.

Threat narrative

Attacker objective: The attacker aims to assume stale cloud roles and obtain legitimate cloud access through a reclaimed CI/CD identity path.

1. Entry occurs when an attacker reclaims a deleted or renamed CI/CD namespace and creates a repository path that matches an old OIDC subject claim.
2. Credential access follows when the attacker requests an OIDC token from the global issuer and presents a token whose subject still satisfies the cloud trust policy.
3. Privilege escalation occurs when the cloud provider exchanges that token for temporary credentials to the trusted role, even though the original owner no longer controls the namespace.
4. Impact is the use of those cloud credentials to inherit whatever deployment or resource permissions the stale role still carries.

Breaches seen in the wild

• Megalodon GitHub Actions attack 2026: Compromised GitHub tokens pushed 5,718 malicious commits to 5,561 repos, adding workflows that steal CI secrets, cloud keys and OIDC tokens.
• reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Namespace permanence is now a false assumption in CI/CD trust design: Cloud roles that trust OIDC subjects were designed for namespaces that stay bound to the same owner. That assumption fails when repository names, usernames, or organisations can be released and reclaimed by someone else. The implication is that trust policies built on stable naming alone are already brittle.

Phantom cloud identities are an offboarding failure, not a token failure: The article shows that short-lived OIDC credentials can still anchor persistent risk when the role itself is never removed. A role that continues to trust a deleted namespace is effectively a dormant identity waiting for namespace reuse. Practitioners should treat stale trust as the primary defect, not the token format.

Sub:jugation exposes identity blast radius inside CI/CD federation: One deleted namespace can map to multiple cloud roles, which means the blast radius is determined by how broadly subject strings were reused across trust policies. That is a governance issue spanning CI/CD, IAM, and NHI lifecycle. The practitioner takeaway is to inventory every role that depends on externally controlled namespace paths.

Reclaimable subject claims: This is the article's sharpest concept, and it describes cloud trust that survives namespace turnover. When the subject claim can be regenerated by a different actor, the cloud provider cannot distinguish the original owner from the namespace squatter. That breaks the assumption that subject equality implies identity continuity.

OWASP-NHI and zero trust both point to the same gap here: The issue is not merely overprivilege, but the absence of continuous validation of who controls the identity source behind the token. Static trust policies do not adapt to namespace churn. The control question is whether your programme still trusts names that no longer have accountable owners.

From our research library:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
• 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
• Read next: NHI Lifecycle Management Guide

What this signals

Reclaimable subject claims: CI/CD federation now needs the same lifecycle discipline that IAM teams already apply to service accounts and certificates. If the namespace that anchors a subject claim can be recycled, the trust relationship must be treated as temporary and continuously revalidated.

Short-lived OIDC tokens reduce secret sprawl, but they do not solve the governance problem created by stale trust conditions. The programme question shifts from how credentials are stored to how identity ownership is retired, reassigned, and reviewed across CI/CD and cloud IAM.

Regulatory and audit perspectives matter here because a deleted namespace with an active role is still an access-control failure, even when the token itself is ephemeral.

For practitioners

• Inventory all roles trusting global OIDC issuers Find every cloud role that trusts token.actions.githubusercontent.com, gitlab.com, or app.terraform.io and map each one to the namespace it depends on.
• Validate namespace ownership before renewal Check whether each repository, user, or organization named in a sub claim is still active and under the expected administrative control.
• Offboard cloud roles when projects end Remove or update every cloud trust policy when a repository, team, or namespace is retired so the stale subject cannot be reused.
• Search for cleartext identity identifiers in workflows Review workflow files for hard-coded role ARNs, application registration details, or workload identity provider values that make phantom identities easier to find.
• Treat namespace reuse as a control failure Reassess any OIDC trust policy that assumes a subject string remains unique over time, especially where namespace churn is common.

Key takeaways

• The core risk is not secret theft but trust reuse, where a cloud role still accepts an OIDC subject tied to a namespace that no longer has the original owner.
• The article reports that 14% of discovered AWS namespaces and 24% of Azure namespaces were unregistered, showing that stale trust is already common enough to be operationally relevant.
• The control that would have limited the exposure is lifecycle offboarding for both the namespace and the cloud role that trusts it.

Key terms

• Phantom Cloud Identity: A phantom cloud identity is a cloud role, service account, or federated access path that still exists after the upstream owner, project, or namespace has been retired. The credential path appears valid to the cloud, but the business justification and ownership are gone, creating hidden takeover risk.
• Sub:jugation: Sub:jugation is a namespace-reuse attack pattern against OIDC federation in CI/CD systems. An attacker reclaims a deleted or renamed namespace, reproduces the expected subject claim, and satisfies an existing cloud trust policy without needing to steal the original token.
• OIDC Group Claims: OIDC group claims are identity token attributes that describe a user’s group membership at the moment the token is issued. They let applications make authorization decisions from current identity state, but they only work safely when the underlying entitlement changes are governed correctly.
• Namespace Reuse: Namespace reuse happens when a deleted or renamed repository, organisation, or workspace name becomes available for someone else to claim. In identity terms, reuse is dangerous when trust policies depend on that name as if it were permanent, because the same subject can later point to a different owner.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.