TL;DR: AI agents embedded in CI/CD can read repositories, run shell commands, push commits, and reach external services through runner tokens, according to Pillar Security. The governance gap is that static pipeline controls assume text, not runtime agency, so privilege and intent can change after the workflow is parsed.
At a glance
What this is: This is a news analysis of Pillar Security’s agentic CI/CD release, showing that AI agents in pipelines create a runtime governance gap that static scanners cannot see.
Why it matters: It matters because IAM, AppSec, and platform teams now have to govern pipeline authority, not just credentials and workflow files, across NHI and agentic systems.
👉 Read Pillar Security's announcement on agentic CI/CD discovery and runtime controls
Context
Agentic CI/CD means AI agents are operating inside build and delivery workflows with access to code, runners, secrets, and external services. The identity problem is no longer limited to who can start the pipeline. It now includes what the agent can decide to do once the workflow is already running, which is why conventional static controls miss the actual risk.
Traditional CI/CD security assumes deterministic steps and predeclared permissions. Once an AI agent can interpret repository content, user comments, and prompt text as instructions, the pipeline becomes an identity execution environment rather than a fixed script. That shifts governance from code review alone to runtime authority, especially where runner tokens and protected branches are in scope.
Key questions
Q: How should security teams govern AI agents running inside CI/CD pipelines?
A: Security teams should govern agentic pipelines as live identity systems, not just as build automation. That means inventorying the agent’s permissions, controlling its triggers, and monitoring runtime actions such as secret access, branch pushes, and outbound calls. If the agent can interpret untrusted input, it must be treated as a governed actor with bounded authority, not a passive tool.
Q: What breaks when an AI agent can act inside a pipeline without human approval?
A: The assumption that workflow intent is fixed at definition time breaks first. Once the agent can read prompts, comments, or repository text and choose actions at runtime, static policy cannot predict the next step. That creates a governance gap where the real decision happens after the approval point, which is why conventional review models miss the live risk.
Q: How do teams know if agentic CI/CD controls are actually working?
A: Look for evidence that the agent cannot reach secrets, cannot mutate protected branches, and cannot execute shell commands outside its declared boundary. If telemetry shows attempted outbound calls, credential access, or policy violations being blocked or alerted on, the control is operating. If you only see clean workflow files, you do not yet know whether runtime guardrails are effective.
Q: Who is accountable when an AI agent in CI/CD exposes secrets or pushes unauthorized code?
A: Accountability sits with the organisation operating the pipeline, because the agent is acting inside delegated authority. The practical question is which team owns trigger design, secret scoping, runtime detection, and incident response. Governance frameworks for access control and zero trust both expect a clear control owner, and agentic workflows do not remove that responsibility.
How it works in practice
Why agentic CI/CD breaks static pipeline assumptions
CI/CD scanners such as SAST, SCA, and policy-as-code inspect workflow definitions and repository content, but they cannot predict runtime choice. An AI agent can be triggered by a pull request comment, read surrounding context, call tools, and select actions after the workflow file has already been parsed. That means the security question is no longer only whether the pipeline is allowed to run. It is whether the agent can reinterpret harmless-looking text as instruction and then exercise the runner’s authority in ways the static policy never modeled.
Practical implication: treat the runner as a live decision environment and not just a scripted build target.
How runtime guardrails differ from discovery in agentic pipelines
Discovery and posture management answer what agents exist, what authority they hold, and how they were introduced into the pipeline. Runtime telemetry answers what the agent is doing right now, including secret access, outbound calls, shell execution, branch pushes, and MCP or external context ingestion. Those are different control layers. Discovery is inventory and classification. Runtime control is detection and enforcement against live behavior. In agentic CI/CD, the two must be correlated because configuration risk and execution risk are decided in different places and at different times.
Practical implication: connect pipeline inventory to execution telemetry so policy can follow the agent into the runner.
Agentic CI/CD as a non-human identity problem
A coding agent in a pipeline behaves like a non-human identity with delegated authority, but with dynamic intent that changes during execution. The critical issue is not simply that it uses secrets or tools. It is that a prompt, comment, or repository artifact can alter what it chooses to do with that authority in-session. That makes CI/CD identity governance a blend of NHI classification, privilege containment, and behavioral control. The security model has to account for an identity that can move from instruction intake to code execution without a human approval gate in between.
Practical implication: classify agentic pipeline actors as governed identities and scope their access as if runtime decisions will vary.
NHI Mgmt Group analysis
Agentic CI/CD is not a workflow problem, it is an identity governance problem. Once an AI agent can decide how to use runner access, the pipeline is no longer governed by deterministic script execution alone. Static approvals and repository policies still matter, but they no longer describe the full authority boundary. Practitioners should treat pipeline agents as governed identities with live decision power, not as enhanced automation.
Prompt-influenced pipeline behaviour creates a runtime governance gap that static scanners cannot close. SAST, SCA, and policy-as-code can inspect the workflow definition, but they cannot determine which tool the agent will choose at runtime or which secret it will actually reach for. That means the most dangerous part of the attack surface appears after the file is read, not before. The practical conclusion is that runtime behavior has become the real control plane for agentic CI/CD.
Privilege in CI/CD now needs to be judged by runtime agency, not by the neatness of the workflow file. A runner token that looks acceptable on paper can become dangerous once an agent can interpret comments, markdown, or repo content as instructions and combine them with shell and network access. The governance problem is not only over-permissioning, but instruction reclassification inside the execution window. Security teams should assume the identity can redefine its own next action from the material already in scope.
Identity blast radius is now the best way to describe agentic pipeline risk. The same agent can move from prompt intake to secret access to branch modification inside one execution path, which compresses the time between decision and impact. That collapses the usefulness of controls that depend on long-lived review cycles or stable intent. Practitioners should reframe pipeline protection around how far one agent can travel once it is inside the runner.
Access review processes were designed for stable entitlements, and that assumption fails in agentic CI/CD because the agent’s effective privilege is contextual and session-bound. The implication is that existing review cadences do not explain what an agent can do after it has been triggered by untrusted input and given runtime context. What breaks is the belief that access can be fully understood from provisioning records alone.
From our research:
- 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
- Only 33% of organisations report their AI agents have accessed inappropriate or sensitive data beyond their intended scope, which shows the problem is already operational, not theoretical.
- For the broader control model, see OWASP Agentic AI Top 10 for how tool misuse, prompt influence, and identity abuse converge.
What this signals
Identity blast radius is the right planning concept for agentic CI/CD because the same delegated actor can move from prompt intake to code change to secret reach in a single execution path. That compresses detection windows and makes review cadences less useful as a primary control. Teams should align pipeline governance with runtime enforcement and tie it to OWASP Agentic AI Top 10 threat categories.
With 92% of organisations already saying AI agent governance is critical but only 44% having implemented policies, per the 2026 agent security survey, the market signal is clear: control design is lagging deployment. For practitioners, that means pipeline policy, secret scoping, and trigger design cannot wait for a broader AI programme to mature.
The governance question is no longer whether agents will enter delivery pipelines. It is whether your identity programme can prove which agent had authority, what it touched, and where enforcement happened when the run completed. That is where CI/CD security, NHI governance, and AI control planning start to converge.
For practitioners
- Inventory every agentic workflow and classify its authority Map which repositories, triggers, runners, and external services can activate an agent, then record the secrets, shell access, and branch permissions each one can reach. Tie that inventory to the exact workflow files and source-control paths that introduce the agent.
- Separate discovery from runtime enforcement Use discovery to identify agent presence and posture, then pair it with telemetry that detects secret access, outbound calls, shell execution, and protected-branch pushes during live runs. Do not rely on workflow inspection alone for enforcement decisions.
- Restrict untrusted triggers before they reach agent logic Treat comments, issue text, and markdown as executable influence, not documentation, and require allow-listed events before agent activation. Remove write-capable triggers from workflows that expose runner tokens or repository mutation privileges.
- Reduce the blast radius of runner credentials Scope tokens to the smallest possible repository and network boundary, then split build, test, and deploy privileges so an agent cannot carry one credential set across multiple pipeline stages. Revoke any cross-environment token reuse that lets one run pivot into another.
Key takeaways
- Agentic CI/CD changes the identity problem in pipelines because runtime decision-making can override the assumptions built into static workflow controls.
- The evidence points to an operational gap already forming, with agent governance widely recognised as critical but policy coverage still far behind deployment.
- Teams should combine discovery, runtime enforcement, and trigger restriction if they want to contain pipeline agents before their authority expands beyond intent.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | Agentic pipeline behavior and prompt-influenced tool use map to agentic AI risk controls. | |
| OWASP Non-Human Identity Top 10 | NHI-01 | Pipeline agents function as governed non-human identities with scoped authority and secrets. |
| NIST CSF 2.0 | PR.AC-4 | Least privilege and access enforcement are central to protecting CI/CD runners and tokens. |
Classify each agentic runner as an NHI and bound its permissions to the smallest necessary scope.
Key terms
- Agentic Ci/Cd: CI/CD environments where AI agents can interpret inputs, choose actions, and interact with tools during pipeline execution. The key security issue is that the agent’s authority is runtime-shaped, so access and intent can diverge after the workflow is approved.
- Runtime Guardrails: Controls that inspect and constrain what an identity does while it is active, not just what it is allowed to do on paper. In agentic pipelines, runtime guardrails monitor secret access, shell execution, network calls, and branch mutation as they happen.
- Identity Blast Radius: The practical extent of damage a single identity can cause once it has entered a system. For agentic CI/CD, blast radius includes code changes, secret reach, external service access, and the ability to amplify a bad prompt into a broader supply chain event.
- Prompt Injection In Pipelines: A control failure where untrusted text inside a workflow, comment, or repository artifact changes an AI agent’s behavior. In CI/CD, the problem is not just malicious wording, but the fact that the agent may treat ordinary content as operational instruction.
Deepen your knowledge
Agentic CI/CD governance and runtime control are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are trying to secure pipelines where agents can read, decide, and act inside the same run, this is a useful starting point.
This post draws on content published by Pillar Security: Introducing Pillar for Agentic CI/CD. Read the original.
Published by the NHIMG editorial team on 2026-05-03.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org