A coding agent in CI reads text from issues, pull requests and code, then acts with the credentials your pipeline gives it. The common mistakes are broad tokens, open-ended tools, untrusted input in privileged triggers, unpinned actions, and no human approval for high-impact steps. Fix them by narrowing what the agent can touch.
Why is CI a risky place for an agent?
Pipelines hold secrets and can push code. An agent adds a component that follows instructions written in natural language, and some of that language comes from people outside your team: issue titles, PR descriptions, comments in a dependency's source.
OWASP's LLM06 Excessive Agency names the root causes as excessive functionality, excessive permissions and excessive autonomy. Triggers include hallucination and direct or indirect prompt injection. A CI job gives all three plenty of room.
No attack payloads here. The point is defense.
What are the seven mistakes?
1. A write token by default. If the job only reviews code, it needs read access. GitHub recommends setting the default token permission to read-only and granting more per job.
2. A shell tool with no limits. OWASP gives open-ended extensions, such as a tool that runs shell commands, as a typical example of excessive functionality. Prefer narrow tools, such as a dedicated file-writing tool.
3. Untrusted text in privileged triggers. GitHub advises avoiding pull_request_target and workflow_run unless needed, and never checking out untrusted PR code in those workflows. An agent that reads a fork's PR in that context holds repository secrets while reading attacker-controlled text.
4. Expressions pasted into scripts. GitHub's guidance is to pass values such as a PR title through an environment variable instead of inlining the expression in a script, and to quote shell variables. The same habit applies to prompts you assemble from event data.
5. Unpinned third-party actions. Pin to a full-length commit SHA from the original repository. Tags can be moved or deleted. The agent action you install is code that runs with your token.
6. Long-lived cloud credentials. GitHub recommends OpenID Connect so jobs get short-lived credentials. A static key in a secret is available to every step that can print it.
7. No gate on high-impact actions. OWASP recommends human approval for deletions, merges and similar actions, and downstream authorization that does not rely on the model's judgment. Branch protection, required reviews and CODEOWNERS on workflow files are checks the agent cannot talk its way past.
OWASP adds that logging, monitoring and rate limiting do not prevent excessive agency but limit the damage, so keep them on.
What to do
- Set repository default workflow permissions to read-only.
- Give each agent job its own minimum permissions and a separate identity from deploy jobs.
- Replace general shell access with specific, allowlisted tools where you can.
- Keep agent jobs off pull_request_target for untrusted forks.
- Pass event data through environment variables, never inline.
- Pin every action to a full commit SHA and review updates.
- Use OIDC instead of stored cloud keys.
- Require human review for merges, and put CODEOWNERS on the workflows folder.
- Scan what the agent produces: dependency changes and new code go through the same gates as human work. The Safeguard CLI can run in CI and emit SARIF or JUnit output, so findings land where reviewers already look.
- Log tool calls and set rate limits.
You can try the pipeline side in the CI/CD actions demo.
Quick check
Is read-only access enough for a code review agent?
Usually yes for the repository, plus a narrow permission to post comments. Grant extra access per job only where the job needs it.
Does pinning to a tag count as pinned?
GitHub says tags can be moved or deleted, so a full commit SHA from the original repository is stronger, unless you trust the tag's creator.
Sources
Last reviewed: 18 October 2026.
