How should security teams reduce secret sprawl in CI/CD and agent workflows?

Why This Matters for Security Teams

Secret sprawl in CI/CD and agent workflows is not just a hygiene issue. Every duplicate token, cached credential, and embedded API key expands the blast radius when a runner, plugin, chatops workflow, or AI agent is compromised. The operational risk is compounded because build systems and agents often touch production-adjacent assets faster than humans can review them. NHIMG’s Guide to the Secret Sprawl Challenge frames this as a visibility problem as much as an access problem. Industry data reinforces the point: 88% of security professionals are concerned about secrets sprawl, and 64% of valid secrets leaked in 2022 are still valid and exploitable today.

That persistence matters because CI/CD pipelines and agentic systems routinely reuse credentials across stages, forks, sandboxes, and tool calls. Static secrets tend to survive long after the original task, while autonomous workflows can copy them into logs, prompts, memory stores, or downstream actions before anyone notices. Current guidance suggests treating every secret as a time-bound capability, not a reusable asset, and pairing that with workload identity and request-time issuance. The risk is highest when secrets are exposed through process arguments, environment files, build artifacts, or agent memory that outlives the task.

In practice, many security teams discover the sprawl only after a pipeline credential has already been reused outside the intended trust boundary.

How It Works in Practice

The most effective reduction pattern is to centralise secret storage, then issue access only at request time to a trusted workload identity. For CI/CD, that means replacing long-lived environment variables and repository-stored tokens with short-lived credentials minted for a specific job, runner, or stage. For agents, the same approach applies, but the identity signal must also reflect the task context, not just the machine or service account. That is where workload identity, ephemeral tokens, and policy evaluation at request time become the practical control stack.

In implementation terms, security teams should map each secret to its owning system, then remove every duplicate copy that is not strictly necessary for execution. A secure pattern usually looks like this:

• Store the secret once in a dedicated secrets manager or vault.
• Authenticate the pipeline or agent with workload identity, not a shared static password.
• Issue a short-lived credential only when the task begins.
• Bind the credential to scope, TTL, and environment so reuse becomes harder.
• Revoke or expire the credential automatically when the job or agent step completes.

This aligns with the direction described in the OWASP Non-Human Identity Top 10 and the NIST AI Risk Management Framework, both of which support stronger identity, containment, and lifecycle controls for non-human workloads. NHIMG’s CI/CD pipeline exploitation case study is a useful reminder that runners, build steps, and shared tooling often become the real exposure point rather than the application code itself. For agentic workflows, pair this with the OWASP Agentic AI Top 10 and the CSA MAESTRO agentic AI threat modelling framework to make sure tool access, memory, and action scope are all constrained. These controls tend to break down in legacy pipelines that require shared secrets across many jobs because the same credential must survive too many stages to remain low risk.

Common Variations and Edge Cases

Tighter secret controls often increase delivery overhead, requiring organisations to balance developer speed against reduced exposure. That tradeoff becomes sharper in mixed environments where legacy CI systems, third-party actions, and agent tooling all expect credentials in different formats. Best practice is evolving, especially for agentic workflows, because there is no universal standard yet for how much context an authorisation decision should inspect before releasing a secret.

Two edge cases deserve attention. First, secrets embedded in logs, artifacts, or prompt histories may survive even after the primary credential is rotated, so rotation alone is not enough. Second, some agent workflows need temporary access to multiple downstream systems in sequence. In those cases, short-lived secrets should be scoped per step, not per session, to prevent one successful action from becoming a reusable foothold. The Analysis of Claude Code Security shows why AI-assisted development raises the stakes: fast-moving toolchains can multiply credential exposure before human review catches up. For broader operational context, the Anthropic AI-orchestrated cyber espionage report illustrates how autonomous systems can chain actions in ways that make static secret assumptions unreliable.

Where this guidance weakens is in heavily stateful build farms and long-running agents that cache credentials to survive retries, retries, and human handoffs, because persistence requirements compete directly with short-lived security posture.

Related resources from NHI Mgmt Group

• How should security teams reduce secret sprawl in machine identities?
• How should security teams reduce secret sprawl on developer workstations?
• How can security teams reduce environment poisoning risk in agent workflows?
• How can security teams reduce secret exposure in LLM-driven workflows?