Why do developer tokens and CI/CD secrets create such high risk in agentic environments?

Why This Matters for Security Teams

Developer tokens and CI/CD secrets are high risk in agentic environments because they are not just credentials, they are executable trust. An agent can read code, invoke tools, and chain actions across repositories, runners, and cloud APIs, so a single leaked token can become broad automation impersonation. Traditional assumptions about “internal” systems fail when the same workstation that edits code also launches untrusted prompts or agents. Current guidance suggests treating these secrets as live NHIs, not convenience artifacts. The Guide to the Secret Sprawl Challenge shows how quickly this exposure scales in practice.

OWASP and NIST both frame this as a control-plane problem, not a simple password problem. The OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework both point toward runtime governance, least privilege, and traceability. In practice, many security teams encounter token abuse only after an agent has already pushed code, opened a new cloud path, or exfiltrated secrets from a build runner.

How It Works in Practice

In agentic pipelines, risk compounds because secrets are often available in environments that can also execute arbitrary code. A developer token used for Git access may also unlock package publishing, issue tracking, container registry actions, or cloud deployment. If an AI coding assistant, autonomous agent, or multi-step workflow can access those secrets, it can inherit the same trust boundary as a human operator but act at machine speed.

Good practice is evolving toward separating identity, authority, and secret material. That means giving the agent a workload identity, then issuing dynamic, short-lived secrets only when a task requires them. The CSA MAESTRO agentic AI threat modeling framework and NIST Cybersecurity Framework 2.0 both support this direction through stronger access governance and continuous monitoring.

• Use workload identity for agents and runners, not shared developer tokens.
• Issue JIT credentials per job, with narrow scope and short TTL.
• Bind secrets to the task context, repository, branch, runner, and environment.
• Revoke credentials automatically when the workflow completes or fails.
• Log every secret access and tool invocation for later investigation.

NHIMG research has shown how quickly this becomes operationally real: the Reviewdog GitHub Action supply chain attack demonstrates how one compromised automation path can expose many downstream credentials. These controls tend to break down when long-lived secrets are mounted into general-purpose runners that also execute untrusted code, because the agent can inherit trust faster than defenders can revoke it.

Common Variations and Edge Cases

Tighter secret controls often increase pipeline friction, requiring organisations to balance delivery speed against blast-radius reduction. That tradeoff is especially visible in monorepos, ephemeral preview environments, and developer sandboxes where teams want fast iteration but also need strong separation. There is no universal standard for this yet, but current guidance suggests that static secrets should be the exception, not the default, in agentic workflows.

One edge case is third-party automation that cannot yet support workload identity or per-task token minting. Another is legacy CI/CD tooling that caches credentials across jobs or reuses runners across projects. Those environments may need compensating controls such as secret scanning, egress restrictions, per-job vault brokers, and aggressive revocation. The CI/CD pipeline exploitation case study and NIST AI Risk Management Framework both reinforce that the control objective is to prevent an agent from turning one stolen credential into broad, persistent access.

Another practical exception is human-in-the-loop review. Review gates help, but they do not solve the core problem if the secret is already present in memory, logs, or local files on a machine that the agent can reach. In environments with many ephemeral agents, the safer pattern is to remove standing secrets wherever possible and rely on task-scoped authorisation plus fast revocation.

Related resources from NHI Mgmt Group

• Why do short-lived tokens still create major risk in CI/CD environments
• Why do stolen publishing tokens create such a large supply chain risk?
• Why do SPN and UPN collisions create such a high-risk identity control failure?
• How should teams respond when CI or developer secrets are exposed?