Permissions for an agent on a pull request
A coding agent in CI can explain a failed test, suggest a patch, or prepare a dependency update. The same agent can also encounter hostile instructions inside a pull request. The useful comparison is not between an agent that is trusted and one that is not. It is between capabilities that produce reviewable evidence and capabilities that create consequences before review.
Start with a read-only job. Add permissions individually, with enforcement outside the model. These paired boundaries make a practical starting policy.
§ Reading a change alongside accessing credentials
Allow: Read the proposed diff, relevant source files, and selected test output. Treat repository text, issue descriptions, and logs as untrusted input, even when they resemble instructions from a maintainer.
Restrict: Access to environment variables, deployment credentials, signing keys, and unrelated repositories. Never run an untrusted fork's code in a privileged job merely because the agent needs context. Redact sensitive logs before sending them to a model; prompt instructions are not a secret boundary.
§ Proposing a patch alongside publishing it
Allow: Generate a patch artifact in an isolated workspace. Limit writable paths and reject changes outside them. A first deployment might permit application code and tests while excluding workflow files, ownership rules, and release configuration.
Restrict: Direct pushes to protected branches, automatic merges, and edits that expand the agent's own permissions. If a separate service publishes the patch as a branch, give that service narrowly scoped credentials. Review the final diff, not just the agent's summary.
§ Running checks alongside choosing arbitrary commands
Allow: Request predefined operations such as a formatter, a targeted test suite, or a static check. Execute them in disposable workers with CPU, memory, disk, and time limits. Assume tests and build scripts from the proposed change can execute hostile code.
Restrict: Unbounded shell access, privileged containers, host mounts, and access to the container runtime socket. A command allowlist helps, but an approved test command can still invoke changed scripts. Isolation must remain effective even when the selected command behaves maliciously.
§ Fetching dependencies alongside unrestricted networking
Allow: Reach approved package mirrors and the configured model endpoint through explicit egress rules. Keep dependency installation separate from jobs holding publishing credentials. Where feasible, use locked dependencies and prepared images.
Restrict: General outbound access, cloud metadata endpoints, and arbitrary uploads. Network access can turn a readable file into an exfiltration target. If a task genuinely requires another destination, approve that destination explicitly rather than temporarily removing the entire boundary.
§ Model access alongside workflow authority
Allow: Give the worker a dedicated inference credential, short-lived where supported, and keep it out of the agent's readable files and tool output. With Vana API, teams can use one endpoint through OpenAI-compatible, Anthropic Messages, or Gemini native protocols. This can simplify routing while leaving CI permissions unchanged.
Restrict: Treating a model choice or API compatibility as evidence that a job is safe. Vana API bills per real token with no monthly fee; still enforce request, token, and retry budgets in the runner. Create a Vana API account if you want to test this setup in a small, isolated workflow.
§ Agent evidence alongside independent approval
Allow: Attach the patch, executed commands, exit codes, and relevant logs to the run. Re-run required checks independently against the exact commit proposed for merging. Make stopping on budget exhaustion or uncertain results a normal outcome.
Restrict: Letting the agent certify its own work, approve its own changes, or waive failing checks. Require human review for permission changes, dependency updates, and sensitive code paths. Deployment should remain a separate authorization decision.
A useful initial boundary is simple: the agent may inspect, propose, and test inside a disposable environment; another identity decides whether anything leaves that environment. Expand that boundary only when a specific task requires it, and record the reason alongside the permission.