Why does agentic AI in your pipeline need a new security approach?

CI pipelines were built to run fixed scripts. An agent in the pipeline decides its own next step based on text it reads, and that text can come from issues, pull requests, logs and dependencies. Fixed-script controls assume the steps are known in advance. With agents they are not, so limits must sit outside the agent.

What is different about an agent in CI?

A classic job runs the same commands on every run. You review the script, pin the actions, and the behavior is bounded by what you wrote.

An agent chooses commands at run time. It might read a failing test log, open a file, call a tool, edit code and open a pull request. Those choices depend on inputs the attacker may influence. OWASP's agentic list names goal hijack, tool misuse, identity and privilege abuse, unexpected code execution and agentic supply chain vulnerabilities as separate risks, and a CI agent touches all five.

Why do old controls fall short?

Code review covers the diff, not the run. Reviewing the agent's pull request does not show which files it read or which tools it called to produce it.

Secrets sit in the environment. CI jobs usually hold publish tokens and cloud credentials. An agent that can run shell commands can read them. The LiteLLM incident in March 2026 is reported to have started with a security scanner in the project's CI pipeline that had access to publishing credentials, which shows how much a single tool in a pipeline can reach.

Pinning covers code, not behavior. Pinning an agent's version does not pin what a model does with new input.

Allow lists are written for commands, not for intent. A permitted command can still be used to harm.

What limits work?

Put controls where the model cannot negotiate with them.

• Least privilege tokens. Give the agent job its own short-lived credentials with read access, and keep publish and deploy credentials in a separate job that the agent cannot trigger.
• Isolation. Run the agent without secrets in a sandbox with restricted network egress.
• Tool allow lists. Name the tools and arguments it may use. Log each call.
• Human approval for irreversible steps. Merge, publish and deploy need a person.
• Treat inputs as hostile. Text from issues and logs is data, never instructions.

A constructed example

A team adds an agent that triages failing builds and proposes fixes. First version: it runs in the main build job with the deploy token present. A tester plants an instruction in a test log asking the agent to print environment variables. It complies in a staging run. Second version: the agent runs in a separate job with no secrets, read access to the repo, no outbound network except the model endpoint, and it can only open a draft pull request. The same planted text now does nothing useful.

How to check or apply this

1. List every agent or AI tool that runs in CI and what credentials each can see.
2. Split jobs so that agents never share an environment with publish or deploy secrets.
3. Use short-lived tokens issued per run.
4. Restrict network egress for agent jobs to what they need.
5. Log tool calls with the agent's identity, arguments and outcomes.
6. Require approval on merge and publish steps.
7. Test with benign planted instructions in logs and issues and confirm they are ignored.
8. Treat the agent's tools and plugins as dependencies: pin and review them.

Safeguard offers MCP Guardrail for tool calls, agent identity controls, and policies and gates in pull requests, which fit steps 2, 5 and 6. They work alongside your pipeline controls and do not replace them.

Open the MCP Guardrail demo in its own page.

Quick check

Sources

• OWASP GenAI Security Project, Top 10 for Agentic Applications for 2026
• PureAI, PyPI removes compromised LiteLLM releases
• NIST NCCoE, Software and AI Agent Identity and Authorization

Last reviewed: 18 October 2026.