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.
Why This Matters for Security Teams
A deleted namespace should not be treated as a clean boundary event. If the trust policy on a CI/CD role still points at that namespace, the role can stay reachable through the same OIDC subject pattern after the namespace is recreated or reclaimed. The platform may validate the token as designed, yet the trust decision can still land on the wrong workload. That is a classic non-human identity failure: the credential path is intact, but the identity meaning has drifted.
This is why abandoned OIDC trust is more dangerous than an expired secret. A stale namespace reference creates a durable authorisation path that bypasses the normal human expectation that “deleted means gone.” In practice, this is adjacent to the broader secrets exposure problem described in the State of Secrets Sprawl 2026 and the CI/CD pipeline exploitation case study, where build systems and runners become the real target. NIST’s NIST Cybersecurity Framework 2.0 remains useful here because the issue sits at the intersection of identity governance, change control, and continuous monitoring.
In practice, many security teams discover this only after a deleted project, recycled namespace, or abandoned runner name has already been turned back into an access path.
How It Works in Practice
Most CI/CD systems use OIDC to let workloads assume cloud roles without long-lived cloud keys. The trust policy usually matches token claims such as issuer, audience, repository, branch, and namespace. That is sound only if the namespace remains uniquely tied to the intended workload. Once the namespace is deleted, the reference becomes a latent trust object. If an attacker can later recreate the same namespace name or otherwise satisfy the subject claim, the role may become assumable again even though the original owner is gone.
The operational fix is not just “delete the namespace carefully.” It is to treat OIDC trust as lifecycle-bound NHI governance. Security teams should:
- Inventory every cloud role that trusts CI/CD-issued OIDC tokens.
- Bind trust to immutable workload identifiers where possible, not only human-readable namespace names.
- Revoke or rewrite trust policies when repositories, runners, clusters, or namespaces are decommissioned.
- Use short-lived tokens and JIT issuance so trust windows stay narrow.
- Monitor for recreated namespaces, duplicate claim values, and stale federated identities.
The broader lesson aligns with the Guide to the Secret Sprawl Challenge and the Reviewdog GitHub Action supply chain attack: CI/CD is a privileged production surface, not a disposable automation helper. Current guidance suggests treating federated trust the same way as key material, because stale trust can outlive the code that created it. NIST’s identity and monitoring principles support that posture, but there is no universal standard for exact claim design across every cloud and pipeline vendor yet.
These controls tend to break down when teams reuse namespace names across environments, because the trust policy may still match the recreated subject exactly.
Common Variations and Edge Cases
Tighter OIDC trust often increases operational overhead, requiring organisations to balance safer identity binding against deployment speed. That tradeoff is most visible in large platform engineering environments where namespaces are cloned, ephemeral preview stacks are common, or multiple clusters share similar naming conventions.
The main edge case is when the platform deletes the namespace but not the federation trust, and the cloud provider treats the subject claim as sufficient proof of continuity. Another is when teams rely on RBAC inside the cluster but ignore the cloud role outside it. That creates a gap between local permissions and external authorisation. Best practice is evolving toward intent-aware trust, but for CI/CD today the practical answer is still immutable identifiers, aggressive cleanup, and continuous review of every OIDC relying party.
Another common mistake is assuming that a deleted namespace cannot be recreated with the same name by another project, another tenant, or a compromised automation path. The Shai Hulud npm malware campaign illustrates how supply chain compromise can turn ordinary automation into a credential-harvesting path long before anyone notices. For teams formalising this into governance, NIST CSF is still the baseline control map, but the practical control objective is simple: retire trust when the workload dies, and prove that no orphaned subject claim can resurrect it.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Stale OIDC trust is an NHI lifecycle and trust-boundary failure. |
| NIST CSF 2.0 | PR.AC-4 | Federated access via OIDC must be governed with least privilege. |
| NIST Zero Trust (SP 800-207) | PA-7 | Trust should be continuously evaluated rather than assumed from namespace history. |
Track every workload identity from creation to decommissioning and remove federated trust when the workload ends.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 2, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
