A coding agent in CI can summarize a change, suggest a test, or prepare a patch, but a workflow that runs on a pull request is a security boundary. The submitted code, repository instructions, issue text, and build scripts may all be controlled by the contributor. Separate routine checks from trusted jobs that can access secrets or write to the repository.
Treat pull request content as untrusted input
A workflow can execute code from a pull request through a test command, package installation, build script, or action. That code can read the files and environment available to its job. An AI agent adds another route for untrusted text to influence tool calls, so a request to review a change should not automatically receive permission to publish, deploy, or read credentials.
GitHub documents the difference between pull_request and pull_request_target. The latter can run with access to secrets and a more powerful token. Checking out and executing code from a fork in that privileged workflow can expose the repository. Keep the workflow code and the untrusted code at separate trust levels.
Keep the first job read only and disposable
For untrusted contributions, start with a job that has only the permissions needed to inspect the change. Do not pass production credentials or broad personal tokens into the agent. Use a fresh runner or isolated workspace for each run so one contributor’s files cannot affect another task.
If the agent only needs to comment with a summary, route its output through a separate trusted step that validates the content and uses a narrowly scoped token. Do not let model generated text become an unchecked shell command, workflow file, or API request.
| Job | Useful boundary |
|---|---|
| Test untrusted pull request | Read only token, no secrets, fresh runner |
| Agent review | Limited repository context and no deployment access |
| Publish status or comment | Separate step with narrow write permission |
| Deploy or release | Trusted branch, required approval, protected environment |
Use minimum permissions and review triggers
Set explicit token permissions for each workflow and job. Check every event trigger, including issue comments and workflow runs, because a workflow can become privileged even when its name sounds like a review task. Pin third party actions to reviewed versions and limit which secrets are made available.
Never respond to a failed agent run by granting it broader permissions without understanding the failure. If private dependency access is required, split the work so a trusted process supplies only the dependency artifact the untrusted test needs, or use a carefully reviewed environment boundary.
- List every event that can start the workflow.
- Identify which steps execute contributor supplied code.
- Remove secrets and write permissions from those steps.
- Keep release jobs on trusted refs and require human approval.
- Review the agent output and logs before allowing a follow up action.
Check the boundary after each workflow change
A safe workflow today can become unsafe after a new event trigger, action, token permission, or artifact handoff. Review the workflow diff as carefully as application code. Test with a harmless fork pull request and confirm that the token is read only, secrets are unavailable, and the agent cannot publish or deploy.
For local agent safety, see the prompt injection guide. For general CI setup, start with the existing guide to running an AI coding CLI in CI and apply these trust boundaries before adding automation.