Exposed API keys in CI/CD pipelines: the blast radius has changed

The numbers that should end the “we’ll fix it later” conversation

GitGuardian’s State of Secrets Sprawl 2026 report counted 28.65 million new hardcoded secrets added to public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump the firm has ever recorded. Since 2021, leaked secrets have grown 152% while the global developer population grew 98%. Secrets are leaking faster than the people writing the code.

GitHub’s own security data puts the total at more than 39 million leaked secrets across its platform in 2024. These are not draft credentials from weekend side projects. They are production keys, service account tokens, and OAuth secrets sitting in commit history, CI logs, and Slack channels, waiting to be harvested.

IBM’s Cost of a Data Breach Report 2024 puts the average cost of a breach involving compromised credentials at $4.88 million per incident, a 10% rise from the prior year. The more operationally painful number is the detection window: approximately 219 days to identify and contain a cloud breach. That is seven months of quiet lateral movement before anyone raises an alert.

AI tooling is the accelerant, not just a background factor

The secrets problem has a new driver, and it is the same AI-assisted coding workflow that is supposed to make teams faster. GitGuardian found that commits co-authored by Claude Code leaked secrets at roughly twice the baseline rate across public GitHub. At peak, in August 2025, Claude Code-assisted commits reached 31 secrets per 1,000 commits, approximately 2.4 times the human baseline.

The mechanism is not mysterious. AI coding assistants optimise for working code, not for secure credential handling. When a developer asks for a quick integration with an LLM API, the assistant produces a snippet that hardcodes the key because that is the pattern in the training data. The developer ships it. The key lands in version control.

MCP configuration files, the emerging standard for tool-calling in agentic pipelines, exposed 24,008 unique secrets in the period GitGuardian analysed, partly because official documentation actively encouraged hardcoding patterns. Of the ten fastest-growing leak categories, eight are tied to AI services. LLM infrastructure, covering RAG pipelines, orchestration layers, and vector storage backends, leaked five times faster than core model providers. The AI layer of the stack is currently the weakest link in credential hygiene.

Secrets are leaking faster than the developer base is growing, and AI tooling is widening the gap. The blast radius of a single exposed key now extends from billing shock to full supply-chain compromise.

CI/CD pipelines as the primary harvest surface

The tj-actions/changed-files incident in March 2025 is the clearest recent illustration of the supply chain dimension. More than 23,000 repositories depended on this widely used GitHub Action. Attackers compromised the shared dependency and modified it to quietly exfiltrate secrets during workflow execution. The repositories themselves were never touched; the attack lived entirely in the dependency graph.

The TeamPCP campaign of March 2026 ran the same playbook across multiple targets simultaneously, compromising Trivy (Aqua Security), Checkmarx KICS and AST GitHub Actions, and LiteLLM in four waves. Tokens stolen during the Trivy compromise were used five days later to access LiteLLM’s PyPI publishing pipeline. One credential, one pivot, one poisoned package reaching downstream consumers.

When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and in documented cases as quickly as 9 minutes. The assumption that a briefly exposed key can be rotated before anyone notices it is not defensible. The window is shorter than most incident response runbooks can execute.

Internal repositories compound this. GitGuardian found they are six times more likely than public ones to contain hardcoded secrets, precisely because teams treat internal tooling as implicitly trusted. And 28% of incidents originate outside code repositories entirely, in Slack, Jira, and similar collaboration tools. GitGuardian’s research found leaked secrets in 2.4% of corporate Slack channels surveyed.

Remediation failure: the 64% problem

64% of valid secrets leaked in 2022 are still not revoked in 2026. This is not primarily a technical failure. Rotation is straightforward. The failure is governance: no owner, no repeatable remediation path, no authoritative inventory of what credentials exist and what they can reach. Security teams find the leaked key, open a ticket, and discover that nobody knows which service it belongs to or whether rotating it will break a production dependency.

An API key rotation policy that exists only as a document is indistinguishable from no policy at all. What enforces rotation is automation: short-lived credentials issued on demand, secrets managers that reject static keys at the pipeline boundary, and CI runners that hold no persistent credentials between jobs.

What an architectural response actually looks like

The operational controls that reduce blast radius are well understood. The difficulty is applying them consistently across a pipeline that spans multiple clouds, multiple registries, and an expanding set of AI service integrations.

• No static secrets in CI runners. Use OIDC federation to exchange short-lived tokens at job start. The runner never holds a credential that survives the job boundary.
• Centralised secrets management with audit trails. Every secret retrieval is logged, attributed to a pipeline identity, and reviewable. HashiCorp Vault, AWS Secrets Manager, and Azure Key Vault all support this pattern; the choice matters less than the enforcement.
• Pre-commit and pre-push scanning. Tools like GitGuardian’s ggshield or truffleHog run locally before anything reaches the remote. This catches the majority of accidental commits before they enter the history that attackers scan.
• Dependency pinning with hash verification. The tj-actions and TeamPCP campaigns both exploited unpinned action references. Pin every external action to a commit SHA, not a mutable tag.
• Blast radius isolation. Credentials should carry only the permissions the job actually needs. A deployment credential that can also read your entire secrets store is a single point of total compromise.

Network architecture and the credential exfiltration path

One dimension of credential hygiene that rarely appears in the tooling conversation is the network path that exfiltrated credentials travel. When a compromised CI runner calls out to an attacker-controlled endpoint, that traffic crosses the public internet unless the pipeline runs inside a network perimeter with egress controls. We operate 44 points of presence across Europe and the Middle East, with direct peering to AWS, Azure, GCP, Oracle, and Cloudflare at every site. That peering density means customer workloads can run CI/CD pipelines with private, low-latency paths to cloud APIs while egress to arbitrary public endpoints is restricted at the network layer, removing a significant exfiltration vector before any application-level control is even invoked.

Sovereign infrastructure also changes the IAM trust model. When the cloud provider operates under EU law and is not a subsidiary of a foreign entity, the IAM policies governing who can issue credentials, who can read audit logs, and who can respond to an incident are subject to European legal jurisdiction. For organisations under DORA or NIS2, that jurisdictional clarity is not a marketing point; it is a requirement that shapes which providers can sit in the critical path of a regulated workload.

The credential hygiene posture that actually holds

The goal is not zero leaked secrets. Given the volume of AI-assisted code and the pace of pipeline iteration, that is not a realistic target. The goal is a posture where a leaked credential has a short validity window, a narrow permission scope, a fast detection path, and a repeatable revocation process. That combination reduces the blast radius from a supply-chain compromise to a contained incident.

Start with the inventory problem: you cannot rotate what you cannot find. Run a secrets scan across your repositories, CI logs, and collaboration tools before you build anything else. The 64% remediation failure rate exists because teams discover leaks reactively. An authoritative secrets inventory, maintained by automation rather than convention, is the foundation everything else sits on.