Why do CI tokens behave like privileged non-human identities?

Why This Matters for Security Teams

CI tokens are not just build-time convenience artifacts. They authenticate automated jobs, request cloud and SaaS APIs, and often carry repository or deployment authority that is broader than most human users receive. That makes them behave like privileged non-human identities, with the added risk that their usage is triggered by code, pipelines, or merged pull requests rather than by a person making an intentional access request.

The security problem is lifecycle, not label. Long-lived tokens tend to spread across jobs, runners, secrets stores, and logs, which mirrors the failure modes documented in the OWASP Non-Human Identity Top 10 and in NHIMG research such as the Guide to the Secret Sprawl Challenge. NHIMG’s 2025 research found that 44% of NHI tokens are exposed in the wild, often in collaboration tools, tickets, and code commits, which is exactly how CI credentials end up becoming enterprise-wide exposure points.

In practice, many security teams encounter token abuse only after a pipeline secret has already been reused, leaked, or inherited by a downstream workflow, rather than through intentional governance of the build identity itself.

How It Works in Practice

A CI token becomes NHI-like when it is used by an automated system that acts with authority but without human review at the moment of execution. The token is the proof of identity, while the pipeline, runner, or job is the workload that wields that identity. In that model, the right question is not “who typed the password,” but “what workload is allowed to do this action, under what conditions, and for how long?”

Current guidance suggests treating CI access as workload identity rather than as a shared secret. That means using short-lived credentials, scoped to a specific repository, branch, environment, or deployment stage, and issuing them just in time when a job starts. Where possible, bind trust to the workload itself using cryptographic identity primitives such as OIDC or SPIFFE-style workload identity, rather than baking static tokens into environment variables. For policy enforcement, teams increasingly rely on runtime evaluation rather than fixed role assignments, which is consistent with the direction of NIST Zero Trust Architecture and the operational focus of the Salesloft OAuth token breach coverage, where token misuse translated directly into broad data access.

• Inventory CI tokens as privileged machine identities, not as miscellaneous secrets.
• Set tight TTLs and revoke on completion, not on a quarterly schedule.
• Bind each token to one workflow, one environment, and one narrow purpose.
• Log token use at the job level so abnormal reuse is visible quickly.
• Rotate automatically when repository ownership, runner trust, or deployment scope changes.

These controls tend to break down in shared runner fleets and monorepo pipelines because one token often serves many jobs, making least-privilege scoping difficult to enforce without redesigning the build architecture.

Common Variations and Edge Cases

Tighter CI token governance often increases build friction and operational overhead, so organisations have to balance delivery speed against blast-radius reduction. That tradeoff is real, especially when legacy pipelines depend on static credentials, third-party integrations, or cross-account deployments that were never designed for ephemeral identity.

There is no universal standard for this yet, but current guidance suggests several patterns are safer than broad static reuse. Ephemeral OIDC federation is usually preferable to stored tokens because it removes the need to persist a reusable secret. Separate tokens for build, test, release, and infrastructure tasks reduce lateral movement when one workflow is compromised. For high-risk environments, policy-as-code can block token use unless the request matches expected context such as repo, branch, runner trust level, and target environment.

Edge cases appear when CI systems trigger other automation, especially in chained pipelines or multi-tenant runners. A token that seems harmless in one job can become privileged once a downstream action inherits its context. NHIMG’s secret sprawl research and the JetBrains GitHub plugin token exposure case both reinforce the same point: once automation can reuse or export credentials, the token behaves like an NHI with poor governance rather than a simple pipeline variable.

Related resources from NHI Mgmt Group

• Should organisations treat certificates and tokens like other non-human identities?
• Why do non-human identities make privileged access governance harder?
• How should security teams govern privileged non-human identities in virtualisation environments?
• How should security teams govern OAuth tokens as non-human identities?