Introducing: Pillar for Agentic CI/CD  

Today we are introducing Pillar Agentic CI/CD Discovery and Posture Management and extending the Pillar runtime agent from developer workstations to CI/CD workflows. Together they bring AI agent security into the place where those agents now hold authority: the pipeline.

The Agentic CI/CD Pipeline Attack Surface 

CI/CD used to be the deterministic part of the supply chain. You committed code, scripted steps ran, artifacts came out the other side. Agents broke that. A coding agent invoked from a PR comment can read the repo, run shell on the runner, push commits, and reach any external service the runner's tokens authorize. It has the access of a privileged engineer with none of the predictability, and anyone who can trigger the workflow, can prompt it.

What was data is now instruction. PR titles, issue comments, markdown in the repo, content the scanners have always treated as documentation, all of it gets read by the agent as part of its prompt. The secrets sitting in the runner environment have not moved, but the process reading them has.

Scanners like SAST, SCA, and policy-as-code assume the pipeline is static text. They cannot tell you what the agent will do at runtime or which of the credentials in scope it will actually reach for, because the model decides that after the workflow file is done being read.

Introducing: Pillar for Agentic CI/CD Pipelines 

Today's release closes this gap as an extension of the platform we introduced earlier this year for AI coding agents. It ships in two parts, mapped to the two halves of the problem above. Discovery and Posture Management answers what is in our pipelines and what could it do. The runtime agent answers what is it doing right now and should we let it.

1. New: Pillar Agentic CI/CD Discovery and Posture Management

Before an AI agent ever executes, you need to know which agents exist in your pipelines, what authority they hold, and how they got there in the first place. Our new discovery capability scans pipeline configurations across your source-control platforms, identifies the AI agents embedded in them, and classifies the resulting risks against the SAIL framework. Findings come out the other side already named in the language security teams use, with severity, source file, OWASP and MITRE ATLAS mappings, and concrete remediation guidance attached.

The two highest-impact finding types map directly to the dominant attack patterns in agentic CI/CD:

SAIL 6.1 AI Agent with Excessive Agency in CI/CD. Triggered when a workflow grants an autonomous agent the ability to execute arbitrary code, access the runner shell, permissive tools, or push commits to the repository. Combined with broad repository permissions, this is the configuration that turns a prompt injection into a full repository or supply chain takeover.

SAIL 5.3 AI Agent Triggered by Untrusted Input. Triggered when a workflow invokes an agent in response to user-controlled events such as issue comments or pull-request descriptions. Because the agent processes that input as part of its instructions, an attacker can craft a malicious comment to perform prompt injection, and the risk is amplified when access controls allow non-write users or bots to fire the trigger.

Equivalent findings cover secret exposure (sensitive credentials injected into agent environments) and AI supply chain risk. Together they give security teams something they have not had until now: a single, prioritized inventory of every AI agent in their pipelines, scored by what it can actually do.

2. Extended: the Pillar posture and runtime agent, now on CI/CD runners

Static analysis can tell you what an AI agent might do. Only runtime telemetry tells you what it actually did.

The Pillar runtime agent, the same endpoint component we introduced for AI coding agents running on developer workstations, is now extended to CI/CD workflow runners. The behavioral controls security teams already use to monitor AI agents on developer machines now apply on the build host as well. Same agent, same policy model, new place to deploy it.

On a CI/CD runner, the runtime agent collects configuration and runtime data from the host to feed continuous posture, and once policies are in place it detects, alerts, or blocks malicious and out-of-policy actions during execution:

• An agent reaching for a secret outside its declared scope.
• An agent making an outbound network call that violates policy.
• An agent attempting to push to a protected branch.
• An agent executing a shell command that crosses a defined boundary.
• An agent ingesting external context from an MCP server or source that has not been allow-listed.
• Behavioral anomalies: credential harvesting patterns, unusual directory traversal, gateway-bypassing API calls, that already exist in our coding-agent detections, now applied to runners.

Discovery answers what is in our pipelines, and what could it do? The runtime agent answers what is it doing right now, and should we let it? You need both, and you need them stitched into the same platform, because agentic CI/CD risk is one of the few security problems where the configuration and the behavior are decided in different places at different times, and the workstation and the runner are increasingly running the same agents against the same code.

The rest of this post explains the risk class that made today's release necessary: the shift in CI/CD that Security and AppSec teams should be sizing now.

Available Now

If you want to see Agentic CI/CD Discovery and Posture Management or the Pillar runtime agent on your runners, get a demo. For background on the broader platform this release extends, read our earlier announcement, Introducing Pillar for AI Coding Agents, or explore the SAIL framework that powers our findings engine.

‍