They increase risk because they can act with the same execution authority as trusted automation while still being influenced by external content. If the runner account can deploy code or access secrets, a malicious workspace file can turn that trust into credential theft, lateral movement, or downstream compromise.
Why agentic workflows make build pipelines easier to subvert
Agentic workflows raise supply-chain risk because they collapse the gap between trusted automation and externally influenced input. In a build pipeline, that means a workspace file, prompt, dependency change, or task instruction can affect a process that already has deploy rights, signing rights, or secret access. The danger is not autonomy by itself, but autonomy coupled to privileged execution.
An agent that can modify code, fetch packages, open pull requests, or trigger releases becomes part of the delivery trust chain. If it is also allowed to read tokens, credentials, or signing material, a malicious instruction can move from content manipulation into code injection, artifact tampering, or secret exposure. That is why build pipelines are especially sensitive to agentic design choices that would be tolerable in a low-privilege assistant.
This is also where supply-chain risk becomes compounding rather than local. A single compromised step can influence source, dependencies, build outputs, provenance records, or release automation. Once the agent can act across those boundaries, the pipeline no longer only builds software, it can also propagate compromise downstream into repositories, registries, and production deployment paths.
Where the trust boundary fails in practice
The core failure is that the agent may be treated as if it were a disciplined automation job, while it is actually processing untrusted instructions and data at the same time. That creates a confused-deputy style problem: the system behind the agent trusts the runner, but the runner is being steered by workspace content, repository text, issue comments, dependency metadata, or other external sources.
In build systems, that trust often spans more than one sensitive function. The same identity may be able to access source code, package registries, deployment targets, and environment secrets. If the agent can reach those capabilities without a tight policy boundary, compromise can jump from a single manipulated file into broad operational impact. AI coding agents in CI/CD are especially exposed when secrets and over-scoped tokens are available in the same execution context.
The problem is worsened by hidden coupling. Build steps often inherit permissions from the CI runner, not from the individual task the agent was asked to perform. That means a harmless-looking review, refactor, or dependency update can still execute under credentials that are capable of publishing packages or touching protected infrastructure. Once those credentials are present, the question becomes how to constrain action, not merely how to validate output.
Why the blast radius grows quickly across source, artifacts and deployment
Supply-chain compromise in agentic pipelines is rarely limited to one artifact. An agent with write access can alter code, with network access can reach external services, and with secret access can authenticate as trusted automation. Those are different attack surfaces, but in a pipeline they often sit close enough together that one unsafe decision can affect all three. Zero trust for AI agents is relevant here because the useful control pattern is per-action verification and removal of standing privilege, not broad trust in the workflow container.
Build pipelines also amplify persistence risk. If an agent can modify scripts, manifests, or dependency pins, the compromise can survive beyond the initial run and reappear in later builds. If it can influence release metadata or provenance, downstream consumers may inherit a poisoned artifact with no obvious sign that the original build step was manipulated. Agentic AI security guidance is useful because the relevant threat model spans inputs, tools, orchestration and identity, not just prompt abuse.
This is also why supply-chain controls matter more than simple output review. A build system can produce a technically valid artifact that is still unsafe if the agent was allowed to act with excessive privilege or if secrets were reachable during the run. Once compromise reaches package publication, signing, or deployment, the impact is no longer confined to development. SLSA matters because provenance and build integrity are the control plane that help limit how far a tainted build can travel.
Risk and Threat Considerations
Agentic workflows increase risk most when the build runner can both interpret untrusted content and perform sensitive actions. In that condition, a malicious dependency, repository file, or task instruction can pivot from ordinary build manipulation into token theft, artifact tampering, or lateral movement through connected systems.
Failure mechanism: The agent is granted more authority than the specific step needs, then is steered by external content into using that authority against the pipeline itself or adjacent systems.
Impact: Compromise can propagate from a single build execution into code repositories, registries, deployment targets, and any downstream environment that trusts the resulting artifact or credential.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while SLSA and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Build agents can expose tokens and secrets during pipeline execution. |
| NHI-05 — Overprivileged NHI | Pipeline agents with deploy or publish rights have excessive authority. | |
| NHI-07 — Long-Lived Secrets | Persistent CI secrets widen blast radius when an agent is manipulated. | |
| Recommendation — Keep secrets out of agent context and rotate any exposed credentials immediately. Reduce agent permissions to the minimum action needed for each build step. Replace long-lived pipeline secrets with short-lived credentials and frequent rotation. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agentic workflows fail when untrusted inputs steer privileged actions. |
| ASI04 — Agentic Supply Chain Vulnerabilities | The subject is supply-chain compromise inside agentic build pipelines. | |
| Recommendation — Bind each agent action to an explicit authorization check before execution. Assess build inputs, tools and outputs for supply-chain abuse paths. | ||
| SLSA | Supply-chain Levels for Software Artifacts | Build provenance and artifact integrity are central to this pipeline risk. |
| Recommendation — Adopt provenance and verification controls that tie artifacts to trusted build inputs. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Pipeline secrets and tokens need lifecycle control when agents can access them. |
| AC-6 — Least Privilege | The workflow risk depends on whether the runner has excessive execution authority. | |
| SI-7 — Software, Firmware, and Information Integrity | Tainted build inputs and outputs must be detected before release. | |
| Recommendation — Manage credential issuance, storage, rotation and revocation for build identities. Limit each build identity to the minimum permissions required for its task. Verify integrity of build inputs and outputs before promotion or deployment. | ||
Practitioner Guidance
What to prioritise: Treat the runner identity as a high-value production control, not as disposable build plumbing. If that identity can deploy, sign, publish, or read secrets, scope it to the smallest possible action set and separate those capabilities across different jobs or approval points.
What to verify: Confirm whether the agent can reach long-lived credentials, release tokens, or signing material during ordinary workspace processing. If it can, assume the pipeline has a trust-boundary problem even if builds currently appear successful.
Decision rule: If a pipeline step can be influenced by repository content and can also perform sensitive actions, require explicit policy checks and short-lived credentials before allowing the step to proceed. Do not rely on the agent to self-limit.
Practitioner takeaway: The key control question is not whether the agent is useful, but whether any input that can influence it is also able to steer a privileged action path. When those two conditions meet, supply-chain risk becomes an authority problem, not just a code-quality problem.
Related resources from NHI Mgmt Group
- Why do mirrors and caches increase supply-chain risk in build pipelines?
- Why do build pipelines, registries, and base images increase software supply chain risk in cloud native environments?
- Why do privileged build workflows increase supply chain risk so quickly?
- Why do automated build identities increase supply chain compromise risk?