Why are CI/CD identities so dangerous when compromised?

Why This Matters for Security Teams

CI/CD identities are dangerous because they are not just “deployment accounts.” They often sit inside trusted automation paths, inherit broad cloud and source-control permissions, and can reach secrets stores, registries, infrastructure APIs, and approval systems. Once compromised, they become an escalation bridge that can alter code, config, IAM, or release artifacts without triggering the same scrutiny as a human login.

This is why secret sprawl in delivery systems is such a persistent problem. GitGuardian’s Guide to the Secret Sprawl Challenge shows how exposed credentials keep resurfacing across modern engineering workflows, while CI/CD pipeline exploitation case study demonstrates how attackers turn trusted automation into durable access. External guidance also points in the same direction: the Anthropic report on the first AI-orchestrated cyber espionage campaign shows how automation can be chained to speed reconnaissance and abuse at scale.

In practice, many security teams encounter pipeline compromise only after release artefacts, cloud roles, or secret material have already been reused elsewhere in the environment.

How It Works in Practice

The danger comes from the way CI/CD systems are designed to be trusted by default. A build runner may authenticate to the cloud, pull secrets from a vault, push images to a registry, and invoke deployment APIs in a single workflow. If an attacker steals that identity, they can often move laterally with very little friction because the pipeline is expected to automate those steps.

Good practice is to reduce standing privilege and narrow what the pipeline can do at each stage. That means separating build, test, sign, and deploy identities; using RBAC only for the baseline role, then layering intent-based authorisation or policy-as-code for runtime decisions; and issuing JIT credentials that expire as soon as the task completes. Where possible, a workload identity model such as SPIFFE or OIDC gives stronger proof of what the runner is, not just what token it happens to hold. This is especially important when secrets are short-lived and automatically revoked after use.

• Use ephemeral secrets for the job, not long-lived tokens baked into runners or environment variables.
• Scope each pipeline identity to one repository, one environment, and one action class.
• Require real-time policy evaluation before deploy or secret retrieval.
• Log every token mint, secret access, and policy decision for later forensics.

GitGuardian’s The 52 NHI breaches Report and Reviewdog GitHub Action supply chain attack both reinforce the same lesson: once automation has trusted access, attackers do not need to break the perimeter again; they simply abuse the trust path already granted. These controls tend to break down when shared runners, legacy service accounts, and broad cloud admin roles are all tied to the same pipeline token because revocation and attribution become ambiguous.

Common Variations and Edge Cases

Tighter pipeline control often increases release overhead, so organisations have to balance speed against blast-radius reduction. There is no universal standard for exactly how much privilege a CI/CD identity should hold, but current guidance suggests the minimum viable access should be enforced per environment and per workflow, not per team.

One common exception is ephemeral build infrastructure. If runners are truly short-lived and isolated, risk drops, but only if the identity is also ephemeral and bound to a workload-attested context. Another edge case is secret retrieval from a central vault: that pattern is safer than hardcoding credentials, yet it still fails if the pipeline token can enumerate or export more than it needs. The same issue appears in repositories and collaboration tools, where credentials leak outside code. The 52 NHI Breaches Analysis and Shai Hulud npm malware campaign show how quickly exposed secrets spread once one automation account is compromised.

For highly regulated environments, the practical answer is not just stronger MFA or more frequent rotation. It is zero standing privilege for deployment paths, short TTLs for tokens, and policy that can deny unsafe actions at request time. Where pipelines also trigger agentic automation, the risk grows further because an autonomous system can chain tools, adapt its actions, and seek additional privileges in ways a static checklist does not anticipate. Best practice is evolving here, and many organisations are still catching up.

Related resources from NHI Mgmt Group

• When do non-human identities pose the greatest risk to organizations?
• Why do non-human identities create more risk than many human accounts?
• Why do non-human identities create more remediation risk than many human accounts?
• What actions should I take if my OAuth tokens are compromised?