Most engineering teams are comfortable letting AI agents write code, review pull requests, and answer questions about the codebase. Most of those same teams are deeply uncomfortable letting those agents run inside CI/CD pipelines.
The discomfort is rational. It's not superstition or technophobia — it's a recognition that CI runs with credentials and permissions that are categorically different from anything a developer has in their local environment. And the current tooling for securing AI agents in CI doesn't provide the guarantees that make that risk acceptable.
This is the next major unsolved problem in AI agent security. According to Verizon's 2025 Data Breach Investigations Report, third-party and vendor involvement in breaches doubled to 30% this year — and CI/CD pipelines are one of the highest-privilege environments any vendor or automation tool ever touches.
CI pipelines hold the keys to everything
A typical CI/CD pipeline has access to:
- Production deployment credentials (cloud provider roles, Kubernetes service accounts, Helm release tokens)
- Package registry credentials (npm publish tokens, PyPI API keys, internal Artifactory credentials)
- Database migration credentials — often the most permissive database role in your entire organization
- Code signing keys
- Secrets for internal APIs and service integrations
- SSH keys for infrastructure access
These credentials exist in CI because CI needs them. The pipeline runs tests, builds artifacts, publishes packages, deploys services, and migrates databases. It needs access to do all of it.
When a human-written script does these things, the risk is relatively bounded: the script does what it's written to do. When an AI agent does these things — with the ability to reason, improvise, and take actions the person who prompted it didn't explicitly specify — the blast radius of every individual decision expands dramatically.
OIDC is progress. It's also not enough.
The best practice for CI credentials over the last few years has been OIDC federation: instead of storing long-lived cloud provider credentials in your CI secret store, you configure your cloud provider to trust your CI platform's OIDC tokens, and exchange them for short-lived credentials at runtime.
GitHub's documentation on OIDC for Actions describes this clearly: OIDC allows workflows to access cloud resources "without having to store any credentials as long-lived GitHub secrets." AWS, GCP, and Azure all support it well on the receiving end.
This is real progress — for cloud provider access.
Your database migration credentials are not OIDC-federated. Your npm publish token is not OIDC-federated. Your internal API keys are not OIDC-federated. Your SSH keys for production infrastructure are not OIDC-federated. These live as static secrets in your CI secret store, injected into the environment at runtime — the same model that has existed for fifteen years, with all the same risks. Only 38% of organizations have automated secrets detection in their pipelines, per Snyk's State of Open Source Security report — meaning the majority of teams have no automated visibility into where static credentials exist or how they're used.
When an AI agent runs inside a CI pipeline, it has access to every secret that pipeline has access to. The OIDC story is a partial improvement on a small slice of the problem.
What changes when AI agents enter CI
The security model for CI secrets has always been: these credentials exist in the pipeline, the pipeline code is reviewed before it runs, so the attack surface is the pipeline code itself plus anything it fetches at runtime.
AI agents change this in fundamental ways.
First, the agent can take actions that weren't explicitly written in the pipeline definition. It reasons and decides. A pipeline script does exactly what it says. An agent might decide to do something adjacent to what it was asked — calling an API to verify something, writing to a path it inferred was correct, installing a package it determined would help. OWASP's 2025 LLM Top 10 identifies this as LLM06 Excessive Agency: LLMs granted more capability than a task requires, operating without human confirmation gates before consequential actions.
Second, the agent may fetch code and packages during execution. Every package fetched during a CI run can execute code on install. In a standard CI environment, this risk is bounded by a reviewed manifest. An AI agent can decide to install packages that weren't in any reviewed manifest — and as documented incidents like event-stream and node-ipc demonstrate, malicious package code is designed to be subtle.
Third, the agent's context window may contain secrets. If the agent reads a config file, processes environment variables as part of a task, or inspects the pipeline environment for debugging purposes, that information is in its context. Where that context goes — and what the agent does with it — is not controlled by your CI platform.
The legitimate use cases are enormous
It's important to say clearly: there are extremely compelling reasons to run AI agents in CI.
Automated code review that actually understands context. Test generation that covers edge cases a human reviewer would miss. Dependency update PRs with real analysis of what changed and why it matters. Performance regression detection that goes beyond "this took 5% longer" to "here's why." Automated triage of failing tests — not just which test failed but what it means and how to fix it.
These are real productivity multipliers. The teams that figure out how to run AI agents in CI securely will have a significant advantage over the teams that either prohibit it or deploy it without the right guardrails.
The answer to the security problem is not to keep AI out of CI. It's to build a security model that makes it safe to run there.
What a secure CI AI model actually requires
The guarantees you need to safely run AI agents in CI are not fundamentally different from what you need for interactive development sessions — but the context makes them harder to achieve and more important to get right.
Scoped credential access. The agent should have access only to the credentials required for the specific CI task it's running — not every secret the pipeline has ever needed. A code review agent doesn't need database migration credentials. A test-writing agent doesn't need a package registry publish token. The principle of least privilege, applied per-task, per-session.
Audited egress. Every outbound connection the agent makes during a CI run should be logged: the domain, the protocol, the response code. This is both a security control and a compliance requirement — it's how you answer the question "did this CI run exfiltrate any data?" after the fact.
Supply chain controls. Packages fetched during a CI run should be subject to the same policy as packages in your dependency manifest. An agent that can install arbitrary packages into a CI environment with production credentials is a supply chain risk that's distinct from anything your existing dependency scanning tools address.
Isolation between jobs. A CI agent that processes one pipeline job should not have residual state that carries over to the next. Environment variables, temporary files, credentials, and context should be scoped to the job and destroyed at its end.
Blocked request workflows that work in CI. When an agent in CI hits something that needs human approval — a new domain, an operation outside its authorized scope — the workflow needs to work without a human sitting at a terminal watching the job run. Approval requests need to surface to the right people with enough context to make a decision quickly, without blocking the pipeline indefinitely.
The organizational dynamic
The teams most resistant to AI in CI are often the ones with the most to gain from it. A large, complex CI pipeline with many moving parts is exactly where AI assistance is most valuable — and exactly where the credential exposure is most significant.
The conversation at most security-conscious organizations right now is: "We'd like to use AI in CI. We're not comfortable with the exposure. Can we wait for the tooling to catch up?"
The tooling is catching up. But teams shouldn't wait for it to catch up passively — they should be thinking now about what guardrails they'll require before they enable AI in their most sensitive pipelines, so they're ready to move quickly when the infrastructure supports it.
Marshal supports AI agents in CI environments with the same security model applied to interactive sessions: scoped credentials, audited egress, per-verb tool policy, and real-time session controls. The model doesn't change because the context is automated rather than interactive — if anything, the automation makes the controls more important, not less.
Running AI agents in CI/CD requires the same security model as interactive sessions — scoped credentials, audited egress, and real-time controls. See how Marshal handles it →