Direct answer
Start with read-only CI tasks such as review or test diagnosis. Pin the revision and tool version, use ephemeral runners and short-lived credentials, deny unnecessary network and repository writes, enforce time and cost limits, save structured output, and require a separate trusted job or maintainer to apply and merge changes.
Key takeaways
- Separate untrusted issue or pull request text from trusted workflow instructions.
- Grant only the repository, command, network, and secret access required for one job.
- Treat agent output as an artifact for verification, not as approval to deploy.
- Keep write-back, release, and merge authority in independent protected gates.
Key facts
| Fact | Verified value | Evidence |
|---|---|---|
| Codex automation | Codex provides a non-interactive execution mode with script-friendly output options. | View source |
| Claude automation | Claude Code headless mode supports non-interactive prompts and structured output formats. | View source |
| Workflow security | GitHub documents least-privilege token permissions, untrusted input handling, and third-party action pinning for Actions workflows. | View source |
| Execution policy | Codex sandbox and approval settings define command and filesystem boundaries for an execution. | View source |
What this guide helps you solve
Design secure and auditable coding-agent jobs for review, testing, maintenance, and pull request workflows.
Verification scope and limits
- Evidence basis
- Official documentationLocal verification
- Verification scope
- Covers non-interactive execution, trust boundaries, credentials, output handling, verification, and protected write-back in CI/CD.
- Limits and invalidation conditions
- - Exact isolation depends on the CI provider, runner configuration, organization policy, and selected tools.
- - Model output is nondeterministic and must not be the sole control for security, merge, or deployment decisions.
Start with a read-only job and immutable inputs
Trigger the job from a fixed commit SHA and record the workflow revision, tool version, prompt template, and allowed paths. Begin with review summaries, failed-test analysis, or documentation checks that do not require repository writes.
Pull request descriptions, issue bodies, source files, and downloaded artifacts are untrusted inputs. They must not be interpolated into shell commands or allowed to override trusted workflow instructions.
Build a least-privilege runner boundary
Use an ephemeral workspace and identity. Restrict repository token scopes, filesystem mounts, network destinations, command execution, and secret availability. Avoid loading deployment credentials into a job that only reads a diff or runs unit tests.
- Pin the source revision and reviewed action or container versions.
- Use separate identities for read-only analysis and approved write-back.
- Set wall-clock, output-size, retry, and budget limits.
- Destroy the runner and temporary credentials after completion.
Define a machine-readable input and output contract
The prompt should describe the task, allowed paths, prohibited actions, expected output schema, and verification commands. Capture stdout, stderr, exit code, structured events, final response, and changed files as separate artifacts where the client supports them.
Fail the job when required output is missing or malformed. Do not parse a conversational sentence as authorization to continue a release.
Put deterministic gates after agent execution
Run repository-owned formatters, linters, tests, builds, policy checks, and secret scans independently of the agent’s claims. If the agent generated a patch, inspect the actual diff and enforce allowed-path limits before publishing it.
Separate write-back and deployment authority
Publish analysis or a patch artifact first. A protected workflow or maintainer can then create a branch, comment on a pull request, or apply the patch with a different credential. Deployment remains behind the project’s existing environment and approval rules.
- 01AnalyzeRun the agent with read-only repository access.
- 02VerifyEvaluate code and policy checks outside the model.
- 03ApproveLet a maintainer or protected rule accept the artifact.
- 04WriteUse a separate identity for the narrowly approved change.
Retain evidence and review pipeline drift
Retain sanitized artifacts long enough to investigate failures, while excluding prompts or logs that contain secrets or private data. Review dependency updates, model or client changes, permission scopes, timeout behavior, and false-positive patterns on a scheduled basis.
Official sources and verification scope
This guide is based on public official documentation. Commands and configuration may change between client versions, so verify the linked sources before use.
Read the verification methodology