To secure a coding agent in CI, assume anything it reads can contain instructions, then limit what it can do if it follows them. Control who can trigger it, give it a read-only token by default, scope its tools tightly, keep secrets out of reach, and require human review before its output is merged.
What makes an agent in CI risky?
Three things meet in one job. It reads text written by other people, such as issue bodies, pull request descriptions and code comments. It can take actions with tools. And the job runs with credentials. OWASP's prompt injection page describes indirect injection as an LLM accepting input from external sources such as websites or files, which steer its output. OWASP's excessive agency page explains why that matters: damage depends on the functionality, permissions and autonomy you gave the system.
So the defense is not a cleverer prompt. It is a smaller blast radius.
Who may trigger it?
Treat the trigger as an authorization decision. One agent integration's documentation, for Claude Code's GitHub Action, shows a sensible default: the triggering user must have write access to the repository, and bot actors are rejected unless explicitly allowed. It also notes that on public repositories GitHub withholds secrets from runs triggered by fork pull requests. Whatever agent you use, find the equivalent settings and check them.
Be careful with the pull_request_target trigger. GitHub's guidance says it runs privileged and can expose secrets and write access if it checks out untrusted code, and recommends avoiding it unless necessary.
What may it touch?
Start from the GitHub token. Set the default to read-only and grant write access per job, and only where the agent has to push or comment. Prefer a short-lived identity such as OIDC federation over a stored long-lived key, which the Claude Code documentation also describes as an option. Keep deployment credentials and cloud keys out of the job entirely. If the agent needs to run, give it a runner that holds nothing else, and prefer ephemeral runners, because GitHub warns that self-hosted runners are not ephemeral by default and can be persistently compromised.
What may it do?
List its tools and cut the list. OWASP recommends granular extensions rather than open-ended ones such as arbitrary shell or URL access. Many agents let you pass an allowed tools list and a maximum number of turns, and the Claude Code documentation shows both, along with workflow timeouts and concurrency controls to limit runaway jobs. Use them.
Network matters too. If the job cannot reach arbitrary hosts, a manipulated agent has nowhere to send what it read. Restrict egress where your platform allows it.
Who checks the output?
Never let an agent merge its own work. Branch protection should require a human review and passing checks on the agent's pull request. Run the same scanners you run on human code: secrets scanning, dependency checks and code analysis, since agent output can introduce a vulnerable dependency or a credential just as human output can. Safeguard's CLI and local runner can run these checks in CI, and reachability analysis keeps the findings list short.
How do you notice trouble?
Log every tool call with the identity it ran as, alert on unexpected bursts and on any outbound request to an unusual host, and keep the job logs. The tj-actions incident in March 2025 was found because a runner monitor saw an unexpected outbound request. Do not rely on luck.
What to do
- Restrict triggers to users with write access and block unlisted bots.
- Avoid pull_request_target, and never check out untrusted code in privileged jobs.
- Set default token permissions to read-only and raise them per job.
- Use OIDC or short-lived credentials, and keep deployment secrets out of the agent job.
- Allow only the tools the task needs, and cap turns, time and concurrency.
- Restrict network egress from the runner where possible.
- Require human review and passing scans before merge.
- Log tool calls and alert on unusual outbound traffic.
Quick check
Is prompt injection preventable with a good system prompt?
Not reliably. OWASP lists prompt constraints among mitigations but also recommends least privilege, human approval and treating the model as an untrusted user.
Should the agent hold deployment credentials?
No. Keep deployment credentials in a separate job that only runs after human review.
Sources
- OWASP GenAI: LLM01 Prompt Injection
- OWASP GenAI: LLM06:2025 Excessive Agency
- GitHub Docs: Secure use reference
- Claude Code GitHub Actions documentation
- Unit 42: GitHub Actions supply chain attack timeline
Last reviewed: 18 October 2026.
