Securing coding agents in CI: a hands-on checklist

A coding agent running in CI acts with the pipeline's token and secrets, and it reads text that outsiders can write, such as issues and pull request titles. Secure it by shrinking token permissions, treating all input as untrusted, pinning dependencies, using short-lived credentials and requiring human approval for risky steps.

What is the threat model?

Two facts frame it. First, a pipeline job holds real power: repository write access, deployment credentials, package publishing rights. Second, an agent follows instructions found in text, and in CI that text can come from a pull request, an issue, a commit message or a file in a dependency.

OWASP's excessive agency entry states the consequence. Damaging actions follow unexpected, ambiguous or manipulated model output, including from direct or indirect prompt injection, and the impact depends on what the system can reach. So the main control is to limit what the agent can reach.

What is the checklist?

Token and permissions

1. Set the default GITHUB_TOKEN permission to read only for repository contents, and raise it only in the individual jobs that need more. This is GitHub's own recommendation.
2. Give the agent job its own workflow with its own minimal permissions, not the release workflow.

Untrusted input 3. Treat issue text, pull request titles and bodies, branch names and commit messages as hostile. GitHub advises assigning such expressions to an intermediate environment variable and quoting it in scripts, or passing it as an argument to an action, rather than building inline scripts around it. 4. Avoid the pull_request_target trigger unless you truly need a privileged context. GitHub says workflows with that trigger must not explicitly check out untrusted code. Do not give an agent that combination. 5. Do not let the agent execute instructions it finds in fetched content or dependencies without a gate.

Dependencies 6. Pin third party actions to a full length commit SHA, and confirm the SHA comes from the action's own repository and not a fork. Tags can be moved or deleted. 7. Audit the source of any action you use, however it is pinned.

Secrets and identity 8. Do not give the agent long-lived cloud keys. Use OpenID Connect so each run gets a short-lived token valid for one job. 9. Store sensitive values in environments with required reviewers, so jobs cannot read them until a person approves. GitHub notes this does not isolate the job, so self-hosted runner risks still apply. 10. Create a separate secret for each value, register derived values as secrets too, and if a secret appears in a log, delete the log and rotate it.

Runners 11. Avoid self-hosted runners for public repositories. GitHub warns that anyone can open a pull request and compromise the environment. Limit data and network access on any runner you do use.

Tools the agent can call 12. Offer only the tools needed, and replace open ended ones such as shell or fetching any URL with narrow ones. This is OWASP's guidance. 13. Run tools with the minimum downstream permissions, and enforce authorization in the downstream system, not in the prompt.

Approval and logging 14. Require human approval before the agent merges, publishes, deploys or changes protected files. Show the actual diff. 15. Log every tool call and keep the logs. OWASP notes logging does not prevent harm but limits damage.

How should you test it?

Create a throwaway repository with the same workflow. Open a pull request whose description contains instructions aimed at the agent, such as asking it to print environment values or edit a protected file. Check that the token permissions, approvals and tool limits stop each action, and that logs show the attempt. Use harmless test values and never real secrets.

What to do

1. Audit current workflows against items 1 to 15 and mark gaps.
2. Fix permissions, triggers and action pinning first, since they are cheap.
3. Move credentials to short-lived tokens.
4. Add approval gates for merge, publish and deploy.
5. Run the test above once per quarter and after any workflow change.

Where Safeguard fits

The Safeguard CLI supports CI use with SARIF and JUnit output and can gate a pipeline. Secrets scanning checks for committed credentials. Try the CI/CD demo below. The controls in this checklist apply regardless of which agent or CI system you use.

Open the CI/CD actions demo

Quick check

Sources

• GitHub Docs, Secure use reference
• GitHub Docs, About security hardening with OpenID Connect
• OWASP, LLM06:2025 Excessive Agency

Last reviewed: 18 October 2026.