Authorize the job, not the agent in general
Define the repository, branch, permitted paths, task, test commands, network access, credentials, budget, and stop conditions for each job. A broad standing permission makes it difficult to tell whether a specific action was intended.
Use short-lived credentials and the least privilege required for the proposed change. Production credentials and unrelated repositories should remain outside the job environment.
Review the plan before the diff
A code review starts earlier than the pull request. Confirm the customer problem, acceptance criteria, architecture decisions, affected surfaces, and excluded work before implementation begins.
This catches a perfectly implemented wrong solution before it becomes a large diff. It also creates a stable reference for evaluating whether the agent stayed inside scope.
Treat tests as evidence with limits
Record exactly which checks ran, what environment they used, what passed, what failed, and what was skipped. A green suite supports a conclusion about those checks; it does not prove the change is defect-free or safe in every environment.
Reviewers should inspect security boundaries, permission changes, migrations, external effects, and generated tests with the same skepticism applied to the implementation.
Keep merge authority outside the build job
Open a normal branch and pull request. Let existing CI, required reviewers, branch protections, and release processes remain authoritative. The job that created a change should not grant itself permission to merge or deploy it.
A useful audit trail links the original evidence, approved requirement, job scope, model or tool configuration, diff, tests, cost, and human decision. Tamper evidence can show that a record was not changed; it cannot prove that the recorded event or conclusion was correct.