In June, we argued that AI in CI/CD is the security gap most teams are ignoring: pipelines hold the keys to everything, and an agent that runs there inherits them. The argument drew on Verizon's 2025 Data Breach Investigations Report, which found third-party and vendor involvement in breaches doubling to 30%. CI is one of the highest-privilege environments any automation ever touches.
A few months later the question has shifted from "should we?" to "how, safely?" Teams have seen what an agent does to a backlog of flaky tests, dependency updates and release chores, and they want it in the pipeline. The pressure is real and the use cases are good. The exposure has not changed.
So this is the practical version: not whether to run AI in CI, but what to require before you do. Think of it as the acceptance criteria you hand to whoever proposes it, product-neutral and usable against any approach.
CI is different because the blast radius is the whole pipeline
Start by naming why CI is not just "another place the agent runs." A developer laptop holds that developer's access. A CI pipeline holds the organization's: production deployment roles, package registry publish tokens, database migration credentials that are often the most permissive role you have, signing keys, SSH access to infrastructure.
When a human-written script uses those, the risk is bounded by what the script says. When an agent uses them, the bound is gone, because the agent reasons and improvises. OWASP's Top 10 for LLM Applications has a name for this: Excessive Agency, an agent granted more capability than its task requires, acting without a confirmation gate. CI is where excessive agency meets the most dangerous set of credentials you own.
Require scoped credentials, not the whole secret store
The first requirement: the agent gets only the credentials the specific task needs, not every secret the pipeline has ever held.
A code review agent does not need a package publish token. A test-writing agent does not need database migration credentials. OIDC federation helped here for cloud access, and you should keep using it, but notice its limit: GitHub's own documentation describes OIDC for cloud providers, while your npm token, your internal API keys and your SSH keys are still static secrets sitting in the CI store. The requirement is least privilege per task and per run, across all of those, not just the slice OIDC covers.
Require audited egress you can read afterward
The second requirement: every outbound connection the agent makes during a run is recorded, in a place you own, with enough detail to answer a question after the fact.
The question you are buying the ability to answer is "did this run send anything it should not have, and where?" That means the destination, the verb and the path, and the verdict, not just a count of bytes. Treat the same host reached two different ways as two different actions, because a read from a package registry and a write to it are not the same event. A record that lives only in a vendor's dashboard does not meet this requirement; the point is that you can run the query yourself, during an audit or an incident.
Require supply chain controls on what the run fetches
The third requirement: packages and components the agent pulls in during a run are subject to policy, not fetched freely.
An agent that can npm install anything into an environment holding production credentials is a supply chain risk distinct from your existing dependency scanning, which assumes a reviewed manifest. The year's incidents, including a compromised npm release that targeted AI tool configs directly, show why. Require that installs during a run go through the same egress and policy controls as everything else, and that the exact set of components a run used is recorded.
Require isolation between jobs and a headless approval path
The last two requirements go together, because both are about what happens at the boundaries of a run.
Isolation: one job's agent must not leave residual state, environment variables, temp files, credentials or context, for the next. Each run starts clean and is torn down clean.
And a blocked-request workflow that works with nobody watching. Interactive approval prompts assume a human at a terminal. In CI there is not one. When an agent hits something outside its authorized scope, a new destination, an operation it was not granted, the request has to surface to the right people with enough context to decide quickly, without blocking the pipeline forever and without defaulting to "allow" because the job was waiting. An approval model that only works interactively is not a CI control.
The short version you can hand to a reviewer
Before an agent touches your pipeline, require that it: holds only the credentials its task needs; makes only egress you can later read; fetches components only under policy; runs isolated and is destroyed afterward; and escalates anything out of scope to a human through a path that works headless. None of these is specific to a product, and all of them are testable. If a proposed approach cannot demonstrate one of them, that is the gap to close before the agent runs, not after.
Running AI in CI safely is the same security model as interactive sessions, applied where the credentials are most dangerous: scoped access, audited egress, supply chain policy, job isolation, and an approval path that works with nobody at the keyboard. The automation does not make these optional. It makes them more important.
This builds directly on the problem statement from AI in CI/CD: the security gap your team is ignoring →
Marshal applies the same controls to agents in CI as to interactive sessions: scoped credentials, audited egress, per-verb policy, and isolation per run. Book a demo →