Why do long-lived tokens increase risk for CI/CD pipelines and AI agents?

Why long-lived tokens become a standing attack path

Long-lived tokens are risky because they extend the window in which a stolen or over-scoped token can be replayed, reused, or discovered after the original operation is over. In a CI/CD context, that expands the blast radius of a compromised runner or build step. In agentic systems, it can preserve delegated authority well beyond the moment the user or orchestrator intended.

That is why token lifetime is not just a convenience choice. The longer a token remains valid, the more opportunities exist for theft from logs, environment variables, memory, caches, or side channels, and the more likely the token will outlast the trust conditions under which it was issued. RFC 9700: Best Current Practice for OAuth 2.0 Security reflects this by treating sender-constrained access and replay resistance as practical countermeasures to token theft.

Why CI/CD pipelines are especially exposed

Pipeline tokens often exist in a highly dynamic environment, with many transient jobs, shared runners, third-party actions, and frequent handoffs between systems. If the token survives after the job ends, the attacker does not need to win in real time. They can wait until the pipeline completes and still use the token to reach source control, artifact stores, cloud APIs, or deployment targets.

That persistence matters because CI/CD is already a high-trust path. A token that can push artifacts, read secrets, or deploy infrastructure is often enough to move from code execution to environment compromise. When those tokens are long-lived, a single leak can become a durable foothold across multiple releases, not just one failed run. The SLSA model is useful here because build provenance and integrity controls lose value if the pipeline credentials that guard the build path remain reusable long after the build event.

Pipeline security teams should think in terms of exposure windows, not just token count. A token that is technically scoped well can still be dangerous if it remains usable through log retention, reruns, artifact promotion, or delayed attacker access. That is why token expiry, job-bound credentials, and narrow audience binding are operational controls, not optional hardening.

Why agentic systems need fresh authority, not durable delegation

Agents create a different but related problem: they can keep acting after the original instruction has changed, been withdrawn, or become irrelevant. If an agent holds a long-lived token, it may continue to call tools, APIs, or downstream services without a fresh policy decision or human checkpoint. That weakens containment because the agent’s authority stops being tied to the current task state.

The issue is not merely identity. It is the mismatch between autonomous execution and stale authorization. In agentic workflows, a token should usually represent a bounded delegation, not an open-ended right to act. AI Agent Authorisation Guide is directly relevant because it frames task-scoped access, per-action decisions, and human approval as the practical response to excessive or durable agency. Zero Trust for AI Agents adds the operational principle: verify the agent, the principal, and the request each time, rather than assuming earlier approval still applies.

Risk and Threat Considerations

Long-lived tokens increase exposure because theft does not have to be immediately exploitable to remain valuable. Attackers can harvest them from CI logs, compromised runners, agent memory, browser storage, or integration traces and use them later, after monitoring noise has dropped. In agent environments, the same token can also preserve access after the user has moved on, which turns a temporary delegation into a durable abuse path.

Failure mechanism: the control fails when a token remains valid beyond the trust window that justified issuance, allowing replay, reuse, or delayed misuse after the initiating task or approval has ended.

Impact: a stolen pipeline or agent token can enable unauthorized deployment, secret access, data exfiltration, or lateral movement long after the original event, making containment and forensic attribution harder.

Practitioner Guidance

What to verify: confirm that token TTL matches the shortest practical work unit, not the convenience of the integration. If a pipeline job or agent action can complete in minutes, a token that lasts hours or days is usually a governance failure, not an optimization.

Decision rule: if the token can reach production systems, deployment credentials, or sensitive APIs, prefer short-lived, audience-bound tokens with explicit renewal over reusable long-duration secrets. If you cannot bind the token to a job, run, or action context, treat it as standing privilege.

What practitioners underestimate: revocation is only useful if the organisation can actually identify where the token was used and whether it was copied before expiry. For both pipelines and agents, auditability and token lifetime should be designed together.

Practitioner takeaway: long-lived tokens are dangerous because they outlast the decision that created them; the safest pattern is to make authority expire as quickly as the work itself.

Related resources from NHI Mgmt Group

• Why does unrestricted network access increase risk for AI agents in CI/CD pipelines?
• Why do long-lived API keys and tokens increase risk in CI/CD and Kubernetes?
• Why do long-lived user tokens create governance risk for AI agents?
• Why do coding agents increase NHI risk in repositories and CI/CD pipelines?