A plaintext OIDC file turns a temporary authentication artifact into a readable secret with real cloud authority. If an agent or process can access it, the file can be exchanged for tokens and used before the job ends. The risk is not federation itself, but the combination of file exposure, token exchange, and the permissions attached to the resulting service account.
Why a plaintext OIDC file on a CI runner changes the threat model
A plaintext OIDC file is not just a convenience artifact, it is a portable bearer of cloud authority. On a ci runner, that matters because the file is often created for short-lived token exchange, but any process that can read it can usually reuse it before the job exits. The problem is exposure plus replay, not the federation model itself.
That is why the risk sits at the boundary between build-time access and cloud access. If the file is readable in logs, workspaces, artifacts, caches, or sidecar processes, the runner has effectively widened the set of principals that can mint cloud credentials. Good token design does not help if the local file is treated as ordinary text.
How the file becomes cloud compromise fuel
Most CI OIDC flows depend on exchanging a locally available assertion for a cloud token or role session. Once the assertion is exposed, an attacker does not need to defeat the IdP again, they only need to beat the job timer and the job’s privilege scope. That means the compromise path can be very short: read file, exchange token, act with the resulting permissions.
This is especially dangerous when the cloud role behind the OIDC exchange has broad permissions, long session duration, or access to production data paths. The readable file is only the starting point. The real blast radius comes from what the exchanged token can do, which is why least privilege and short-lived credentials still matter after federation is adopted.
The pattern is closely related to other token theft and federation abuse cases, including guidance on OpenID Connect Core 1.0 and the OAuth-based exchange model described in RFC 6749: The OAuth 2.0 Authorization Framework. It also aligns with the operational lessons in OAuth 2.0 and OpenID Connect Guide for Identity Teams and Identity Provider and SSO Security Guide, where the trust boundary is the token exchange path, not the mere existence of federation.
What practitioners should watch in CI environments
CI runners are a high-risk place to store anything that can be traded for cloud access because they combine automation, transient workloads, and often inconsistent isolation. A plaintext OIDC file can leak through process inspection, misconfigured workspace sharing, debug output, artifact collection, or a compromised build step. Once exposed, it may be usable from anywhere until it expires.
Readers should also separate the file’s confidentiality from the cloud role’s authorization. The file itself is only dangerous because it can be exchanged for a session with the permissions of the target workload or service account. If that downstream identity is overprivileged, reusable across environments, or able to reach sensitive APIs, the local exposure becomes an account compromise path rather than a minor secret-hygiene issue.
For identity and workload-authentication patterns, NHI Authentication Guide is the most direct internal reference for understanding token exchange, workload federation, and CI/CD authentication choices. For broader identity governance context, IAM and IGA Basics helps frame why permission scope, provisioning, and review matter even when the credential is temporary.
Risk and Threat Considerations
A plaintext OIDC file creates a short-lived but high-value secret exposure. The threat is not that federation is weak, it is that local file readability can convert an intended one-time assertion into a reusable cloud access path before expiry, especially on shared or instrumented runners.
Failure mechanism: An attacker, malicious step, or unintended process reads the file, exchanges it for a token, and inherits whatever permissions the cloud role or service account grants. If the job container, runner host, or adjacent tooling can observe the file, the compromise can happen without any IdP takeover.
Impact: The resulting session can enable cloud resource access, data exposure, privilege escalation, deployment tampering, or lateral movement into adjacent environments. The practical blast radius is defined by token scope, session duration, and the downstream permissions attached to the federated identity.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | CI OIDC exchanges are service-to-service authentication flows. |
| IA-5 — Authenticator Management | The OIDC file functions as reusable authentication material that needs lifecycle protection. | |
| AC-6 — Least Privilege | The risk depends on how much authority the exchanged token receives. | |
| Recommendation — Use IA-9 to authenticate workload-to-cloud exchanges with tightly scoped, short-lived credentials. Apply IA-5 to protect, rotate, and promptly discard authentication material used in the runner. Limit the federated role to the minimum permissions needed for the CI job. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | The issue is an authentication artifact granting cloud access. |
| PR.DS-01 — Data-at-Rest Is Protected | A plaintext file on a runner is exposed data at rest with active access value. | |
| Recommendation — Control CI workload authentication so exposed artifacts cannot be reused for cloud access. Protect sensitive runner files at rest with filesystem, process, and storage controls. | ||
Practitioner Guidance
What to prioritise: Treat the OIDC file as sensitive identity-bearing material until it is exchanged and discarded. Prioritise runner isolation, immediate file removal after use, and strict control over where the file can be read, copied, or logged.
What to verify: Confirm that the cloud role behind the exchange is narrowly scoped, short-lived, and environment-specific. If the same federated path can reach multiple accounts or production systems, the compromise risk is materially higher than a simple build-secrets issue.
What good looks like: The runner can mint only the minimum cloud session needed for the job, the file is never persisted outside the process that needs it, and a read attempt would be visible in logs or telemetry. If you cannot demonstrate those conditions, treat the path as an exposed credential pathway.
Practitioner takeaway: The security question is not whether OIDC is in use, but whether the local artifact can be read before it is exchanged and whether the resulting cloud authority is small enough that a single file read does not become a cloud compromise.
Related resources from NHI Mgmt Group
- Why do long-lived tokens and wide-scoped roles increase the risk of hidden compromise in cloud and CI environments?
- Why do locally stored cloud credentials increase the risk of CI/CD compromise?
- Why do service accounts and CI runners increase cloud breach risk?
- Why do developer endpoints increase the risk of cloud and NHI compromise?