TL;DR: GitHub Actions OIDC federation replaces long-lived cloud keys in CI/CD with job-scoped tokens exchanged for short-lived AWS, GCP, or Azure credentials, eliminating the leaked secret pattern that drives many workflow compromise incidents, according to Scramble ID. The control only works when subject claims are tightly restricted and environment approvals block production access.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Scramble ID's blog post: GitHub Actions OIDC federation across AWS, GCP, and Azure uses short-lived, job-scoped federation to remove the long-lived CI secret pattern that keeps causing leaks.
Why it matters: It matters because IAM teams need to treat CI/CD as a non-human identity and trust-boundary problem, not a secret-storage problem, if they want to reduce standing cloud access and workflow abuse.
Context
GitHub Actions OIDC federation replaces stored cloud keys with token exchange. A workflow asks GitHub for a job-scoped OIDC token, and the cloud exchanges that token for short-lived credentials if the claims and trust policy match.
The governance problem is not just secret sprawl, but trust sprawl inside CI/CD. Once a workflow can mint cloud access, the real control point becomes the subject claim, the environment gate, and the scope of the role that receives the federated credential.
Key questions
Q: What breaks when CI/CD still relies on stored cloud keys?
A: Stored cloud keys turn every workflow that can read them into a standing access path, which means compromise can happen through poisoned actions, malicious pull requests, or insider misuse. The failure is lifecycle control, not just storage. Once the key exists, revocation is manual and the blast radius persists until rotation closes it.
Q: When should teams require approval before federated deployments can run?
A: Teams should require approval whenever a workflow can reach production, customer data, or privileged cloud roles. Approval gates matter most when federation is tied to protected environments, because they stop routine build activity from becoming implicit release authority. Without that boundary, federation only replaces one standing credential with another broad trust path.
Q: What are the signs that an OIDC trust policy is too broad?
A: Look for wildcarded subject rules, branch-agnostic allowlists, and trust conditions that accept whole repositories or entire organisations instead of one deployment path. Those patterns indicate that temporary federation is being used as if it were unrestricted standing access, which expands blast radius across workflows.
Q: How should teams govern federated identity across GitHub Actions and cloud IAM?
A: Treat GitHub, the cloud provider, and the deployment environment as one governance chain. GitHub issues the assertion, cloud IAM decides whether it is acceptable, and environment controls decide whether the action should proceed. If any one of those layers is broad, the whole path becomes harder to defend and easier to abuse.
Technical breakdown
How GitHub Actions OIDC token exchange works
GitHub Issues an OIDC token to a workflow when id-token: write is enabled. That token is not a reusable secret; it is a signed identity assertion carrying claims such as issuer, subject, audience, repository, and workflow context. AWS, GCP, and Azure each validate those claims through their federation mechanisms, then exchange the token for short-lived cloud credentials. The important distinction is that the workflow never stores a long-lived cloud key at rest, so compromise has to occur at issuance or trust-policy level rather than through secret theft.
Practical implication: move CI authentication to federation and treat the trust policy as the real control boundary.
Why subject claims and environment gates matter
The subject claim is the narrowest part of the trust decision. In AWS it is enforced through the role trust policy, in GCP through attribute conditions, and in Azure through federated identity credential subjects. If the subject pattern is broad, any workflow in scope can assume the role. Environment protection rules add a second gate by requiring approval before sensitive deployments proceed. Together, they turn federation from a convenience feature into a scoped authorization model that separates routine builds from production access.
Practical implication: bind production roles to specific branches or environments and require approval for protected deployments.
Where federated CI still fails in practice
Federation removes the secret, but it does not remove every misuse path. Pull-request workflows can become an escalation path if they are trusted to assume powerful roles. Reusable workflows can inherit access in ways teams do not expect. Long credential TTLs widen the exposure window after issuance, and stale OIDC thumbprints can break validation or create operational workarounds. The architecture is only as strong as the narrowest trust condition and the shortest practical token lifetime.
Practical implication: review which workflow types can trigger cloud access and keep credential lifetimes aligned to task duration.
Threat narrative
Attacker objective: The objective is to turn a trusted CI workflow into a path to cloud execution without needing to steal a persistent secret.
- Entry begins when a workflow is allowed to request an OIDC token with cloud trust attached, either from a main branch, a protected environment, or an overly broad pull-request path.
- Credential access occurs when the cloud exchanges the token for short-lived AWS, GCP, or Azure credentials, giving the workflow temporary authority that replaces static secrets.
- Impact follows when that federation path is too permissive, allowing malicious or unintended workflows to reach production actions, deploy changes, or access downstream services.
Breaches seen in the wild
- 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.
- tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
GitHub Actions OIDC federation changes CI/CD from secret custody to claim-based authorization. The control boundary is no longer where a key is stored, but which workflow claims the cloud is willing to trust. That shifts the security question from vaulting secrets to constraining identity assertions, which is a better fit for non-human identity governance.
Long-lived CI credentials create trust debt that federation can retire. Every stored cloud key inside a workflow is a standing privilege path that survives code review, branch protection, and repository ownership changes. Short-lived federation reduces that debt, but only if the trust policy is narrow enough to match the deployment intent.
Subject-claim conditions are the named control plane for federated pipeline identity. In this pattern, branch scoping, environment scoping, and workflow scoping are not implementation details. They are the mechanism that decides whether CI/CD behaves like controlled automation or like unbounded cloud access.
Production approvals and federated identity should be governed together. Environment protection rules, approval gates, and federated role trust are separate controls that only work as a system. When one is broad and the other is permissive, the result is not defense in depth but redundant permissioning.
Secret sprawl in CI/CD is really lifecycle failure across machine identity and pipeline identity. The article shows that organisations still over-rely on static credentials because they manage workflow access as a storage problem instead of a lifecycle problem. Practitioners should treat issuance, scope, and revocation as one governance chain across NHI and cloud IAM.
From our research library:
- 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: CI/CD Pipeline Identity Security Guide
What this signals
Secretless CI only works when federation is narrower than the workflow fleet. Teams that keep broad subject claims, reused workflows, or pull-request access to production will recreate the same exposure pattern with different plumbing. The practical shift is from secret rotation to trust-policy governance across the entire pipeline.
Pipeline identity now behaves like a non-human identity lifecycle problem. Issuance, scope, and revocation need to be designed together because the credential exists only for a task, not for a person. That is why CI/CD belongs in the same governance conversation as service accounts, workload identity, and other NHIs.
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
For practitioners
- Tighten OIDC subject conditions Restrict cloud trust policies to exact branches, repositories, or protected environments, and exclude pull-request workflows from production-grade roles.
- Pair federation with environment approvals Require GitHub environment protection rules for production deployments so cloud credential issuance only follows reviewable approval gates.
- Shorten credential lifetimes to task duration Set the exchanged cloud credential TTL to match the workflow's actual execution window rather than the longest allowed session.
- Inventory reusable workflow trust paths Review called workflows, inherited permissions, and actor-based trust rules so a downstream repository cannot silently inherit deployment authority.
- Replace stored cloud keys in CI Remove static AWS, GCP, and Azure keys from repositories, secrets stores, and workflow variables wherever federation can supply the needed access.
Key takeaways
- GitHub Actions OIDC federation removes the need to place long-lived cloud keys inside CI workflows, which reduces one of the most common pipeline compromise patterns.
- The deciding control is not the token exchange itself but the precision of the subject claim and the deployment approval boundary around it.
- Teams that keep broad workflow trust, reusable execution paths, or long credential lifetimes will still carry meaningful exposure even after adopting federation.
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 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centers on removing leaked CI secrets from workflow authentication. |
| NHI-04 — Insecure Authentication | OIDC federation depends on correctly constrained identity assertions and trust policies. | |
| NHI-07 — Long-Lived Secrets | The article argues against persistent cloud keys in pipelines in favour of short-lived credentials. | |
| Recommendation — Eliminate stored CI credentials that can leak into logs, actions, or repository secrets. Constrain federated authentication with exact subject and audience conditions. Replace long-lived CI credentials with short-lived federated tokens wherever possible. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Federated workflow access hinges on tightly governed permissions and entitlements. |
| Recommendation — Restrict workflow entitlements so only approved claims can assume cloud roles. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article's core control problem is credential lifecycle and token lifetime management. |
| IA-9 — Identification and Authentication (Non-Organizational Users) | GitHub Actions federation authenticates a non-organizational workload to cloud services. | |
| Recommendation — Apply authenticator lifecycle controls to limit token validity and revoke stale access paths. Use federated authentication for workloads instead of embedding reusable cloud keys. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The abuse pattern is secret capture followed by expansion into cloud control paths. |
| Recommendation — Map CI secret exposure to credential-access and lateral-movement detections across pipeline tooling. | ||
Key terms
- GitHub Actions OIDC Token: A short-lived federated credential issued to a workflow so it can authenticate without storing long-lived secrets. In security programmes, the token is only as safe as the workflow permissions, repository trust, and downstream services that accept it.
- 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.
- Environment Protection Rules: GitHub controls that require approval or other checks before a workflow can deploy to a protected environment. They add an explicit governance gate to federated access, preventing routine build activity from automatically becoming production authority.
- Workload Identity Federation: A mechanism allowing workloads in one environment to authenticate to another using short-lived tokens rather than stored credentials, based on mutual trust between identity providers.
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 building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 22, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org