What breaks when CI/CD pipelines rely on long-lived API keys or OAuth clients?

Why This Matters for Security Teams

Long-lived API keys and OAuth clients turn CI/CD into a persistence layer, not just an automation layer. When a single credential can build, deploy, promote, or call downstream services for months at a time, compromise becomes durable and difficult to notice. This is especially risky because pipeline systems often sit close to source control, artifact stores, cloud control planes, and production secrets.

NHIMG research shows the problem is not theoretical: the State of Secrets Sprawl 2026 reports that 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations. That shifts the threat model from isolated developer mistakes to operational compromise of the systems that move code into production. NIST guidance on secret handling and access control, including NIST SP 800-53 Rev 5 Security and Privacy Controls, supports minimizing standing access and bounding the lifetime of credentials.

In practice, many security teams discover the blast radius only after a pipeline token has already been reused to reach a build runner, artifact registry, or cloud tenant.

How It Works in Practice

The core failure is that static secrets assume a stable trust relationship, while CI/CD is a high-churn, event-driven environment. Pipelines start, stop, fork, retry, and fan out across ephemeral runners. A long-lived API key or OAuth client secret does not express the job being performed, the environment it is running in, or the exact time window in which access is valid. That makes it hard to separate legitimate automation from abuse.

Current guidance suggests replacing standing secrets with short-lived, scoped credentials issued at runtime. For example, a pipeline can authenticate with workload identity, exchange that identity for a narrow token, and revoke it automatically when the job ends. This is the operational pattern behind zero standing privilege and just-in-time access. It also reduces the value of exfiltration from logs, environment variables, or misconfigured secret stores. NHIMG’s CI/CD pipeline exploitation case study and Reviewdog GitHub Action supply chain attack both illustrate how quickly one exposed secret can cascade through build systems and deployment trust chains.

• Use federated workload identity instead of embedding API keys in pipeline configs.
• Issue ephemeral tokens per job or per deployment stage, with the shortest practical TTL.
• Bind authorization to repository, branch, environment, and runner context, not just a secret value.
• Revoke and reissue credentials automatically after failures, retries, or workflow changes.

These controls tend to break down when self-hosted runners share network reach and filesystem state, because one stolen token can be replayed across many jobs before detection catches up.

Common Variations and Edge Cases

Tighter credential controls often increase implementation overhead, requiring organisations to balance delivery speed against reduced exposure. That tradeoff is real in hybrid environments, legacy deployment scripts, and third-party build plugins that still expect static OAuth clients. There is no universal standard for every pipeline pattern yet, but the direction of best practice is clear: secrets should be short-lived, narrowly scoped, and automatically revoked whenever possible.

Edge cases usually appear where teams confuse authentication with authorization. A pipeline may authenticate with a long-lived client secret and then rely on broad RBAC for everything else, which expands the damage when that secret leaks. Better practice is to pair runtime identity with policy checks at the point of use, so a token for test deployments cannot later approve production changes. The Salesloft OAuth token breach is a useful reminder that OAuth clients are not safe simply because they are “app credentials.”

For organisations evaluating secret rotation versus elimination, the distinction matters: rotation reduces dwell time, but federated identity removes the standing secret entirely. In CI/CD, that difference is often the line between recoverable exposure and repeatable compromise.

Related resources from NHI Mgmt Group

• What breaks when AI agents rely on long-lived API keys?
• What breaks when CI/CD pipelines can list tables with long-lived credentials?
• What breaks when agents use long-lived API keys or shared credentials?
• What breaks when CI/CD pipelines rely on static secrets?