What to require before an AI coding agent can merge code

Disclosure: FounderCLI uses coding agents and benefits from presenting agent-assisted development as governable. The risk-tiered policy here is FounderCLI advice, not a universal rule documented by the sources.

Before an AI coding agent’s change reaches main, require a protected branch with human review and named checks, a narrowly bounded execution environment, and a prepared recovery path. FounderCLI recommends letting the change’s risk determine who may complete the merge. This playbook uses those controls to gate process conditions; it does not treat them as a correctness test.

This is a practical playbook for a founder-operated team, not a compliance guide, model comparison, product configuration, or replacement for your threat model. Use the same decision record for every agent change while scaling the acting person to the tier.

1. Put a person and reproducible checks at the branch boundary

Protected-branch rules can restrict deletion and force-pushes. Required reviews can require a specified number of approvals (review requirements). Settings can dismiss stale approvals after new commits or a changed merge base (fresh-review behavior). For collaborators subject to the configured protected-branch rule, required checks must be successful, skipped, or neutral before they can make changes to that branch (status-check behavior). Across workflows, duplicate job names can create ambiguous status results and block a pull request from merging (unique check names).

FounderCLI recommends this branch gate: protect main, route every agent change through a pull request, require a designated human approval, and apply named checks to the revision under review. Identify the branch rule, approval state, evaluated commit, and check results in the pull request. Use the gate record to identify which configured process conditions the merge decision required. FounderCLI does not treat that record as proof of semantic correctness or bug-free code. Compare the approval with the evaluated commit. Record the named checks and the results accepted by the branch rule. For collaborators subject to those protected-branch requirements, the change cannot proceed until the required approval and an allowed check state exist. Budget for the human decision and, when concurrency matters, the queue, rather than waiving either gate.

2. Recheck freshness and bound the agent’s execution

When concurrent work makes target-branch freshness material, FounderCLI recommends using a merge queue. GitHub says the queue applies a pull request to the latest target branch and pull requests already ahead in the queue, then reruns required checks (merge-queue behavior). Record the queue result with the tested revision so the integration context is visible. Use that result as integration evidence, not as a correctness test or a guarantee that the configured checks cover every relevant failure.

Treat the agent as untrusted execution. Restrict filesystem and network access to what the task needs, and run it without elevated process privilege. The OpenAI security guidance says permission profiles constrain commands but do not replace the action’s process-level safety strategy (permission-profile boundary). It gives drop-sudo or an unprivileged-user as process-safety examples (process-safety examples). Use equivalent controls when the agent runs elsewhere. Record the access profile, privilege mode, and run identity so the reviewer can see which boundary was selected.

Isolate an agent-modified host, or place it behind an explicit job-ordering boundary, before later privileged work uses it. Keep the isolation artifact or job-order record with the run so the reviewer can check which control was selected. Treat that record as evidence of the selected control, not proof that the boundary was enforced. The security guidance warns that a loose-permission run can leave processes alive, alter other action code, or write configuration for later privileged work (post-run host-state risk). It also shows that read-only filesystem access and no network do not suffice when passwordless sudo can expose an API key through privileged host information such as procfs (credential-exposure counterexample). The documented residual risk is that a loose-permission run can leave host state changed, and passwordless sudo can expose an API key despite read-only and no-network settings.

3. Make recovery evidence part of merge authority

Make release recovery part of the merge decision. FounderCLI recommends a decision path grounded in the NCSC guidance. Before merge, test thoroughly and retain a path to roll back to a specific version (testing and rollback). Control access in deployment and production environments (deployment access control). Plan a progressive rollout to a subset of users (progressive deployment). At the release boundary, verify code integrity or provenance before installation (integrity and provenance).

FounderCLI recommends separating the merge decision from the release decision when the artifact is built after merge. Before merge, record the evaluated commit, predeployment test result, intended build input and version, deployment and production access controls, rollback target, and progressive-rollout plan. FounderCLI recommends treating the branch and review gate as non-waivable: missing pre-merge items stop the merge. A risk owner may accept residual software risk, but may not waive that recommendation.

Use this closing rule for a real change. Start by writing the recovery boundary: the application and infrastructure inventory, evaluated commit, execution boundary, approved environments, restorable artifact version, and access-control configuration. For a low-risk change, allow automation to merge after a designated reviewer approves it and every gate passes; it stays inside the inventory, changes no production behavior, access, data handling, schema, dependency, or infrastructure, and has a named rollback version. For a medium-risk change, require a human to merge after a designated reviewer approves it; no high-risk trigger applies, but it alters production behavior or data handling, or changes a listed dependency or infrastructure component within the tested rollback path. For a high-risk change, require a risk owner to accept the residual risk and initiate the merge; the change alters production access or a sensitive-data path, reaches an unlisted component, or lacks a usable rollback path. Before a high-risk merge, add any unlisted component to the inventory and recovery boundary and satisfy every non-waivable branch, review, test, access-control, and rollback gate. Before merging, perform this final check: compare the pull request’s approval and named-check state with the evaluated revision, then check the execution boundary, queue result when concurrency matters, and recovery path for the tier. If an item is absent, stop the change and route it to a human decision-maker: the designated reviewer for low- or medium-risk changes, or the risk owner for high-risk changes.

FounderCLI recommends granting autonomy according to change risk and independently inspectable controls, not model confidence.

After the merge and before installation, verify the built artifact’s integrity or provenance. FounderCLI proposes making this verification a release gate: if it is missing, stop installation or release. This proposed gate does not replace the pre-merge branch gate. After deployment begins, record what was deployed, who authorized it, and the initial rollout scope. Progressive deployment can help manage risk and reduce the impact of a potential compromise, but post-release issues remain possible (progressive deployment). The NCSC guidance states: “No software will remain bug-free throughout its lifetime” (bug-free limit). Write this minimum-merge-path policy into the team’s change process, retain the evidence named at each stage, and route any change outside its evidence and recovery boundary to a human decision-maker.