Coding Agents in CI Pipelines: What to Allow

A coding agent in CI can investigate failures, suggest fixes, and prepare patches. It should not automatically inherit the permissions of the pipeline that launched it. Treat the agent as a contributor operating on untrusted input, then grant only the capabilities its task requires.

This walkthrough starts with a read-only assistant and adds narrowly controlled write access. The goal is useful automation without turning repository content or model output into authority.

§ Step 1: Define the task before granting access

Start with one bounded job: explain a failed test, identify a likely regression, or propose a fix within a specific directory. Define the expected output and the conditions that end the run.

• Allow: reading relevant source files, selected logs, and project documentation.
• Require approval: expanding the task beyond its original scope.
• Deny: production changes, releases, and unrestricted repository maintenance.

Instructions inside issues, source comments, dependencies, or logs are task data, not permission grants. A prompt telling the agent to ignore those instructions helps, but enforcement must happen outside the model.

§ Step 2: Separate trusted and untrusted triggers

A pull request from a fork is not equivalent to a maintainer-approved branch. Untrusted submissions should run without repository write credentials, deployment secrets, or access to internal services.

On GitHub Actions, do not combine a privileged pull_request_target workflow with execution of code checked out from an untrusted pull request. More generally, never let an external contribution choose the commands executed in a privileged job.

Use a separate approval step to start any higher-trust operation. Approval should identify the exact commit being authorized; new commits should invalidate it.

§ Step 3: Isolate the agent and its commands

Run the agent in an ephemeral environment with no host credentials, Docker socket, or shared writable workspace. Limit filesystem access, runtime, memory, process count, and outbound network destinations.

Reading code and executing code are different permissions. Tests, package installation, and build scripts can all execute attacker-controlled instructions. Run them in a restricted sandbox, with no sensitive credentials, and apply time and resource limits.

Prefer a small set of approved tools over unrestricted shell access. Enforce command policy in the tool layer rather than relying on the agent to follow it voluntarily.

§ Step 4: Keep model access separate from repository authority

The credential used to call a model should not also authorize repository changes. Use a dedicated model credential where supported, monitor usage, and enforce request, token, and spending limits through your gateway or CI wrapper.

Vana API provides one OpenAI-compatible endpoint that also supports Anthropic Messages and Gemini native protocols. This can simplify model access across existing agent tools without changing the permission boundaries around them. Usage is billed per real token, with no monthly fee.

Keep the model credential out of subprocess environments that execute repository code. Ideally, a separate broker makes authenticated model requests. Review what source and logs leave your runner, and redact sensitive material before transmission.

§ Step 5: Allow patches, not direct merges

Make the agent produce a patch or a proposed branch first. Validate the resulting diff with deterministic checks before publishing it.

• Restrict modified paths and maximum diff size.
• Block unexpected binaries, symlinks, and generated artifacts.
• Require separate approval for CI configuration, dependency changes, security controls, and deployment files.
• Run formatting, tests, and security checks independently of the agent.

If automation opens a pull request, give that publishing component narrowly scoped credentials. Keep those credentials outside the agent sandbox. A passing test suite is evidence, not permission to merge.

§ Step 6: Gate privileged actions explicitly

Require human approval for merging, releasing, changing infrastructure, accessing secrets, or modifying access policies. Bind approval to the reviewed patch or commit, not merely to a workflow name.

Treat agent-generated artifacts as untrusted when passing them to later jobs. A privileged job must not blindly execute a script or load configuration produced by the agent.

§ Step 7: Audit, measure, and expand gradually

Record the input commit, tool calls, approved actions, patch, validation results, model usage, and final outcome. Redact secrets from audit records. Add a kill switch and a procedure for revoking credentials.

Begin with read-only investigations, then enable patch proposals after reviewing real runs. Expand permissions only when a concrete task requires them. To try this setup with your existing agent tooling, create a Vana API account and keep the first CI integration read-only.