CI/CD is becoming a security boundary in the AI era

At a glance

What this is: This is an analysis of how AI-era development is pushing CI/CD pipelines into a more security-critical role, with build visibility, dependency resilience, and egress control emerging as the key findings.

Why it matters: It matters because build systems now sit inside the identity and access perimeter, so IAM, NHI, and platform teams need to govern runners, tokens, and outbound access as production-grade assets.

👉 Read WorkOS's interview on Depot and AI-era build pipeline security

Context

AI is increasing the volume of code, tests, and deployments moving through delivery pipelines, which turns CI/CD into a control point rather than a simple handoff layer. That shift matters for NHI governance because runners, tokens, registry access, and build-time network paths now carry production-level risk.

The practical problem is not just speed. It is trust in the build system itself, especially when third-party dependencies can fail silently and outbound connections can become an exfiltration path. In that environment, identity controls and network controls need to be treated as part of the same delivery boundary.

Key questions

Q: How should security teams govern CI/CD pipelines as identity-bearing systems?

A: Security teams should treat CI/CD as a governed production surface, not a transient utility. That means assigning owners to runners, scoping credentials tightly, reviewing access regularly, and monitoring outbound behavior. The key control is not just who can trigger a build, but what the build identity can reach, change, or exfiltrate during execution.

Q: Why do build pipelines become riskier when AI increases code volume?

A: AI increases the number of build, test, and release events, which expands the opportunity for dependency failure, credential misuse, and unnoticed exfiltration. The more often pipelines run, the more valuable their identities become and the more important it is to control their permissions, dependencies, and network paths.

Q: What breaks when CI jobs can contact any outbound domain?

A: Open outbound access turns the build environment into a data movement channel. A compromised script, leaked token, or malicious dependency can send code, secrets, or metadata outside the organisation without tripping a clear control. Allow-listed egress closes that path and makes abnormal behavior easier to detect.

Q: How do organisations reduce blast radius in software delivery pipelines?

A: They reduce blast radius by limiting what each build identity can access, where it can connect, and how much trust it receives by default. The goal is to keep compromise or failure in one job from becoming a pipeline-wide or environment-wide incident.

Technical breakdown

CI/CD as a production system, not a pass-through layer

Modern delivery pipelines do more than compile code. They execute privileged jobs, fetch dependencies, move artifacts, and often hold credentials that can reach registries, clouds, and internal services. When AI increases the amount of code flowing through the pipeline, the pipeline becomes a production system with its own reliability, identity, and trust requirements. That changes the governance model from simple developer tooling oversight to operational control of a workload that can affect software integrity at release time.

Practical implication: treat CI/CD runners, build tokens, and artifact paths as governed production assets, not disposable tooling.

Build dependencies and silent failure in the software supply chain

Build systems often depend on external services, package sources, and internal infrastructure that are not visible until they fail. The article points to the AWS outage as a reminder that hidden dependencies can break delivery without obvious error signals. In identity terms, this is a trust-chain problem: the build does not just need credentials, it needs assurance that the systems those credentials reach are available and expected. Without dependency mapping, teams discover fragility only when deployment stops.

Practical implication: inventory build-time dependencies and define fallback paths before outage-driven delivery failures expose them.

Egress controls for GitHub Action runners

Outbound network monitoring in CI jobs turns exfiltration into a controllable event rather than a silent risk. If a job can only reach approved domains, a compromised build script, leaked token, or malicious dependency has a much narrower path to move data out. This is a classic blast-radius control: it does not prevent every bad action, but it limits where a build identity can communicate. For NHI governance, that means the runner’s network permissions matter as much as its API permissions.

Practical implication: apply allow-listed egress rules to build identities and fail jobs that attempt unexpected outbound connections.

Threat narrative

Attacker objective: The attacker aims to use the software delivery pipeline to exfiltrate data, corrupt build outputs, or disrupt release velocity through trusted execution paths.

1. Entry occurs through the build pipeline itself, where a CI job, runner, or dependency can act as the initial access point when delivery systems are over-trusted.
2. Escalation happens when the build identity can reach more systems than it should, including registries, caches, or external domains that enable data movement or pipeline manipulation.
3. Impact is delivery disruption or data exfiltration during the build phase, which can corrupt outputs, leak secrets, or block shipping entirely.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

CI/CD governance is now an identity problem as much as a delivery problem. When build runners hold credentials, fetch artifacts, and reach production-adjacent services, they behave like non-human identities with operational authority. That means the old assumption that pipelines are temporary infrastructure is too weak for AI-era delivery. Practitioners should govern runners, tokens, and egress as a single control surface.

Blast-radius control has become the defining design principle for build systems. The article’s egress-control example shows that the relevant question is not whether a job can run, but what it can reach while it runs. A build identity that can only contact approved domains is materially different from one with open outbound access. Practitioners should stop treating build network policy as a side control and start treating it as release integrity.

Hidden dependency visibility is a governance prerequisite, not an engineering luxury. The AWS outage example shows that build pipelines fail differently when third-party services disappear without warning. This creates a dependency accountability gap between platform teams and the business outcomes that rely on shipped code. Practitioners should map delivery dependencies with the same seriousness they apply to production services.

Agentic software development widens the trust boundary around code delivery. As agents write more code and trigger more builds, the pipeline becomes a downstream decision point for both human and machine actors. That increases the number of identities that can influence what gets built, tested, and released. Practitioners should align CI/CD governance with both workload identity and emerging agentic workflows.

Runtime trust in build systems now depends on proving what was allowed to happen, not assuming it did. The core governance shift is from implicit trust in a CI job to explicit control over its network, identity, and dependency behavior. That is where modern delivery security is heading, and teams that cannot observe it cannot govern it.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• For a broader view of secret exposure and machine-driven abuse, see LLMjacking: How Attackers Hijack AI Using Compromised NHIs for how quickly exposed credentials attract attacker activity.

What this signals

Build systems are becoming a governance edge for NHI programmes. As AI drives more delivery activity, the control problem shifts from application code alone to the identities that move code through the pipeline. Teams that already struggle with secret hygiene should expect build runners and release automation to surface the same accountability gaps, especially where access is broad and reviews are infrequent.

Identity blast radius now extends into software delivery. Once a CI job can reach registries, caches, and external services, one weak credential can affect more than one release. That is why the most useful control questions are about reach, not just authentication. Organisations that align delivery controls with the NIST Cybersecurity Framework 2.0 will have a cleaner path to govern, protect, detect, and recover around build-time identity risk.

Secret exposure and pipeline trust are converging problems. The same governance discipline that shortens secret remediation also helps contain build abuse. If your programme still treats CI/CD as engineering plumbing, it will miss where identity now sits inside the release chain. The next maturity step is to govern build identities with the same seriousness as production service accounts.

For practitioners

• Classify CI runners as governed non-human identities Assign owners, scope, and review cadence to every build runner, service token, and registry credential. Put them into the same governance inventory as other privileged non-human identities so access is not left implicit.
• Add outbound allow lists to build jobs Require GitHub Action runners and other CI jobs to use monitored egress rules, then fail any job that attempts to reach an unapproved domain. This narrows exfiltration paths and makes suspicious build behavior visible.
• Map hidden delivery dependencies before outages expose them Document which external services, package sources, caches, and internal systems a build depends on. Include fallback steps for each dependency so outage handling is designed before release pressure makes it urgent.
• Separate build trust from developer convenience Do not grant broad network or registry access just because a pipeline is used frequently. Use narrow permissions for the specific build task and revisit them when code volume or automation changes.

Key takeaways

• AI-era delivery pipelines now behave like production systems, which makes identity, dependency, and egress governance inseparable from release security.
• Hidden third-party dependencies and open outbound access create silent failure paths that can interrupt shipping or move data out of the build environment.
• Practitioners should govern runners, tokens, and network reach as a single control surface if they want to contain blast radius in CI/CD.

Key terms

• CI/CD Identity: A CI/CD identity is the set of credentials and permissions a build, test, or release job uses to interact with tools and infrastructure. In practice, it behaves like a non-human identity with limited but real authority, so it needs ownership, scope, and review like any other privileged account.
• Build Egress Control: Build egress control restricts where a pipeline job can send outbound network traffic. It reduces exfiltration risk, blocks unexpected communication, and makes build behavior observable. For delivery security, it is one of the simplest ways to constrain the blast radius of compromised jobs or dependencies.
• Delivery Dependency: A delivery dependency is any internal or external service a build pipeline needs to compile, test, cache, package, or release software. These dependencies matter because they can fail silently, create hidden trust chains, or become an outage point that affects deployment reliability and release integrity.

Deepen your knowledge

CI/CD governance in the AI era is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are trying to bring build runners, tokens, and release controls into one governance model, it is worth exploring.

This post draws on content published by WorkOS: Depot is making builds fast enough for the AI era. Read the original.