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

At a glance

What this is: Astrix Security describes Sub:jugation, a CI/CD OIDC trust flaw where reclaimable repository namespaces can let attackers assume cloud roles tied to deleted or reused identities.

Why it matters: It matters because cloud IAM trust policies for NHI credentials can survive long after the original CI/CD repository or namespace is gone, creating hidden takeover paths.

By the numbers:

• In AWS, 14% of discovered namespaces were not registered and available to be taken.
• 24%.

👉 Read Astrix Security's analysis of Sub:jugation in CI/CD OIDC trust

Context

Sub:jugation is a cloud identity governance problem created when CI/CD platforms mint OIDC tokens from a shared issuer and the subject claim depends on a namespace that can later be reused. In practice, that means an NHI trust relationship can outlive the repository or organization that originally justified it.

For IAM and NHI teams, the failure is not token issuance alone. The deeper issue is lifecycle mismatch: repository deletion, organization rename, or namespace recycling can leave behind phantom cloud identities that still satisfy cloud trust conditions. That is a governance gap, not just a platform bug.

The article’s starting point is typical for modern CI/CD estates: teams adopted OIDC to avoid static secrets, but offboarding never caught up. That makes the pattern broadly relevant wherever workload identity trust is built on externally controlled claims.

Key questions

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. In that case, the platform validates the token correctly, but the trust policy authorises the wrong party. That is why abandoned OIDC trust becomes a takeover path rather than a harmless leftover configuration.

Q: Why do reusable repository namespaces create NHI risk in cloud IAM?

A: Reusable namespaces weaken the identity permanence that OIDC trust depends on. If the subject claim is built from a path that can be reclaimed, the cloud role is trusting a name, not a lasting owner. That makes namespace lifecycle management part of NHI governance, not just source control hygiene.

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. Safe roles also need periodic recertification after renames, deletions, or migrations. If any of those events occurred without a trust update, the role is suspect.

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.

Technical breakdown

How global OIDC issuers create phantom cloud identities

OIDC-based federation works by exchanging a signed token from a trusted issuer for short-lived cloud credentials. In these CI/CD platforms, the issuer is global, while the cloud role trust policy usually keys on the token subject claim. That design is safe only if the subject remains uniquely bound to a stable identity. Once a repository, user, or namespace is deleted and later recreated, the same subject string can reappear under new control. The cloud still sees a valid token, because signature verification succeeds and the trust condition matches. The failure mode is not cryptography. It is identity continuity across a lifecycle that was never actually continuous.

Practical implication: Treat the subject claim as a mutable identifier unless you can prove the namespace is non-reusable and actively governed.

Why namespace reuse breaks workload identity trust

Namespace reuse turns a human-readable path into a reusable security boundary. A trust policy that expects repo:owner/project can be satisfied by whoever currently controls owner and project, not necessarily by the team that originally configured the role. That is why the article’s Phantom Cloud Identities matter: the cloud role remains live after the upstream identity has been decommissioned. This is a workload identity problem, but it also behaves like a lifecycle problem, because the trust anchor depends on external naming governance. The architecture looks deterministic, yet the identity state behind it is not.

Practical implication: Add namespace ownership checks to every OIDC trust review, especially after renames, migrations, and project shutdowns.

What repository search reveals about exposed OIDC trust

The article shows that reconnaissance does not require cloud access if workflows expose enough detail in code search. Public YAML can reveal the presence of id-token: write, the cloud provider being targeted, and sometimes the role or service account name in cleartext. That combination lets an attacker identify which namespaces are worth reclaiming. The technical lesson is that OIDC reduces secret sprawl but does not eliminate identity exposure. Metadata in workflows can still disclose the path from issuer to cloud role, and that path is often enough to operationalise takeover if offboarding is weak.

Practical implication: Scan workflow code for exposed role names, provider bindings, and stale trust conditions before an attacker does.

Threat narrative

Attacker objective: The attacker wants short-lived but valid cloud credentials for a forgotten deployment role so they can access the victim’s environment through a trusted path.

1. Entry begins when an attacker re-creates a deleted or recycled CI/CD namespace and submits a workflow that can request an OIDC token from the shared issuer.
2. Escalation occurs when the cloud provider validates the token signature and accepts the reused subject claim because the trust policy still matches it.
3. Impact follows when the attacker assumes the stale cloud role and inherits the permissions originally granted to the abandoned pipeline identity.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

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

NHI Mgmt Group analysis

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.

Shared OIDC issuer design creates a governance asymmetry between authentication and ownership. A cloud provider can verify a token, yet it cannot know whether the namespace behind that token was deleted, recycled, or legitimately transferred. That is why OIDC trust for CI/CD must be paired with namespace lifecycle controls and periodic trust-policy recertification. Otherwise, the most modern authentication path becomes a durable persistence path for attackers.

Sub:jugation is a workload identity issue, not only a CI/CD issue. The affected cloud role is the real security object, because it controls what the pipeline can do after federation succeeds. In NHI governance terms, the boundary that needs review is the role trust relationship, the namespace ownership record, and the offboarding event that should have closed both. Practitioners should treat these as linked controls, not separate operational tasks.

Namespace reuse turns least privilege into least assurance. A precise subject string looks granular, but the precision is fragile if the namespace can be reclaimed by someone else. That weakens the security value of path-based trust conditions and raises the bar for control validation. Security teams should consider whether the subject they trust is stable enough to justify cloud access at all.

The market signal is clear: cloud identity tooling now has to understand external identity lifecycles. NHI governance cannot stop at discovering roles and tokens. It also has to model whether the upstream identity, repository, or organization can be reused, transferred, or orphaned. Practitioners should expect offboarding, recertification, and drift detection to converge into one control plane.

From our research:

• 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.
• From our research: 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.
• Forward pivot: For teams mapping the lifecycle angle, Top 10 NHI Issues is the clearest companion resource for understanding where offboarding and over-trust failures tend to cluster.

What this signals

The practical lesson is that OIDC federation reduces credential storage risk but increases the importance of lifecycle control. 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.

Identity subject drift: when externally controlled names remain embedded in trust policies after ownership changes, the security model quietly shifts from least privilege to least assurance. Teams should expect namespace reuse, project renames, and repo deletion to trigger access recertification by default, not by exception.

The governance response should be to join workload identity review with CI/CD offboarding and detection for stale federation paths. That also aligns with zero standing privilege thinking, because standing trust is just standing access by another name when the subject can be reused.

For practitioners

• 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. Prioritise roles tied to deleted projects, renamed organisations, or old deployment repositories.
• 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. If the pipeline is retired, the role should not remain eligible for token exchange in production accounts.
• 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. Cleartext identifiers make reconnaissance easier because an attacker can move from namespace discovery to target validation without internal access.
• Tie namespace changes to access review triggers Trigger a trust-policy review whenever a GitHub organisation, GitLab namespace, or Terraform workspace is renamed, deleted, or transferred. That review should confirm the downstream cloud role was updated or retired in the same change window.

Key takeaways

• OIDC federation does not eliminate identity risk when the subject claim depends on a reusable namespace.
• The scale of the issue is material, with Astrix reporting 14% of discovered AWS namespaces and 24% of Azure namespaces already unregistered.
• Security teams should recertify cloud trust whenever a CI/CD namespace changes ownership, name, or lifecycle state.

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.
• Subject Claim: The subject claim is the identity string inside an OIDC token that tells the relying party who the token represents. In CI/CD federation, that string often encodes repository or namespace data, so its security depends on the upstream naming model being stable, non-reusable, and actively governed.
• 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.
• Federated Cloud Trust: Federated cloud trust is the arrangement where a cloud provider accepts an external token from an identity issuer and exchanges it for cloud credentials. It reduces static secret exposure, but it also shifts risk to the issuer, the token claims, and the lifecycle of whatever identity those claims describe.

What's in the full report

Astrix Security's full article covers the operational detail this post intentionally leaves for the source:

• Step-by-step exploit flow for GitHub Actions, GitLab CI, and Terraform Cloud namespace reclamation.
• Platform-by-platform detection examples showing how cleartext role and provider identifiers were discovered in workflow files.
• Disclosure timeline details for GitHub, GitLab, and Terraform, including the reported fix progression.
• Practitioner checklist for finding and remediating phantom cloud identities across existing cloud estates.

👉 Astrix Security's full post covers the attack chain, namespace reuse mechanics, and remediation steps

Deepen your knowledge

CI/CD workload identity and lifecycle offboarding are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for federated cloud access from a similar starting point, it is worth exploring.