What to require before an AI coding agent can merge code

Define the boundary and decision rule

• Operating question: Which controls must be visible before an agent-authored change can reach main, and what does each artifact establish?
• Audience boundary: Founder-operated and small software teams using coding agents
• Excluded: Regulated-enterprise compliance; model or agent comparison; quantified productivity claims; substitution for the team’s own threat model
• Product boundary: GitHub and Codex as documented implementations; equivalent review, status-issuer, bypass, sandbox, network, permission, and credential behavior to be verified—not presumed—when using alternatives

FounderCLI disclosure: User of coding agents; declared interest in agent-assisted development being governable; source-backed product behavior separated below from FounderCLI recommendations

Documented fact: A GitHub protected-branch rule can enforce workflows before a collaborator pushes or merges changes into a branch and, by default, disables force pushes and branch deletion, but its restrictions do not apply to repository administrators or roles with bypass permission unless the rule is configured to include them.

Documented fact: Codex describes sandbox mode and approval policy as separate control layers, with stated local defaults of no network access and writes limited to the active workspace, while secrets configured for cloud environments are available only during setup and removed before the agent phase.

Inference: A small team should grant unattended merge authority according to its defined change risk only after distinct execution, review, test, provenance, and recovery controls produce inspectable evidence, rather than according to model confidence, because the cited controls bound actions and record selected checks but do not establish semantic correctness; for an alternative repository host or agent, equivalence across those boundaries must be verified rather than presumed.

Run the minimum merge path

Operator sequence: Constrain execution → open a pull request → produce test and build evidence → review the current change → serialize the merge when target-branch drift is material

Gate format: Control → evidence and what it establishes → risk not removed → go/no-go rule

1. Recommendation — Control: Run the agent with network disabled, writes limited to the active workspace or read-only mode as appropriate, approval required for boundary-crossing actions, and cloud secrets limited to setup; Evidence: preserve the effective sandbox, network, approval, and credential settings plus any approval or denial produced during the run, establishing the recorded boundary under which the run operated; Risk not removed: these settings are configurable, access can be widened, and some container configurations cannot enforce the documented Linux sandbox, so an outer isolation boundary may carry the burden; Go/no-go: do not permit an unattended path when the intended execution boundary cannot be demonstrated from the effective configuration and run record.
2. Recommendation — Control: Protect main, require pull-request review, dismiss stale approvals or require approval of the latest reviewable push, require named status checks, accept those statuses only from the intended app where possible, and extend protections to administrators and bypass-capable roles where feasible; Evidence: retain the pull request, the review attached to the current change, the required-status states and their designated issuer, and the applicable branch-rule configuration, establishing which configured review and status gates accepted the identified candidate; Risk not removed: a required status can be successful, skipped, or neutral, and a write-capable person or integration can set a status unless the accepted source is constrained, so the gate does not demonstrate correctness; Go/no-go: stop when approval is stale, a required state is absent, its issuer is ambiguous, or an applicable bypass remains unexplained.
3. Recommendation — Control: Make an automated build and continuous-integration assessment a required merge status, covering team-selected tests and, where relevant, checks for leaked credentials, source and dependency provenance, or cryptographic signatures; Evidence: retain the required-status result, test output, logs, alerts, build artifacts, and provenance or signature-verification output linked to the candidate commit, establishing that the selected assessments ran and produced the recorded results for that candidate; Risk not removed: this record establishes only what the selected tools and tests assessed, leaving untested behavior, weak test design, and omitted checks outside its reach; Go/no-go: stop when the required job did not run against the candidate, its output is unavailable, or the evidence cannot be tied to that candidate.
4. Recommendation — Control: Add a merge queue when concurrent changes can make pre-merge results stale, with greatest relevance on a branch receiving many pull requests from many users; Evidence: retain required-status results run with the candidate applied to the latest target branch and to pull requests already ahead of it in the queue, establishing that the configured checks assessed that combined state; Risk not removed: the queue reruns only configured required checks, broadens neither their coverage nor the review, and is not automatically necessary for a quiet branch; Go/no-go: merge through the queue only after its required checks pass, or record why concurrency is low enough for the ordinary protected-branch path and rerun the applicable gates after a material target-branch change.

Release recoverably and record the decision

Recommendation — Control: Before deployment, restrict release access through least privilege, validate production-environment readiness, collect release evidence logs, assign a release owner, and maintain a tested, version-specific rollback procedure; Evidence: retain the effective access configuration, readiness result, release logs, accountable owner, and documented rollback path beside the merge record, establishing that the named release prerequisites and recovery route were recorded; Risk not removed: rollback is a recovery option after an issue rather than prevention of the issue, and it does not guarantee disruption-free recovery; Go/no-go: treat a missing required artifact, unresolved exception, absent owner, or unusable rollback path as a stop condition rather than as evidence that release is safe.

Merge-ready record

• Change scope: Intended behavior; affected components; data, security, and release exposure; reversibility; declared risk class; classification rationale
• Candidate identity: Commit; pull request; target branch; generated-change boundary
• Execution boundary: Sandbox; write scope; network state; approval policy; credential handling; approval and denial record
• Merge gates: Current reviewer; latest-review state; required checks; accepted status issuers; branch-rule and bypass state
• Build evidence: Tests; logs; alerts; artifacts; secret-scan result; provenance or signature output; evidence locations tied to the candidate
• Concurrency: Queue result, or rationale for the ordinary protected-branch path; target-branch state assessed
• Release: Owner; least-privilege access state; readiness result; release-log location; rollback version and procedure
• Exceptions: Missing or altered control; reason; accountable approver; compensating action; expiration
• Decision: Go or no-go; decision-maker; timestamp; open residual risks; explicitly accepted exceptions

Material limit: Evidence that configured controls ran, never a declaration that generated code is safe, secure, or correct