AI coding governance

What is AI-agent change control?

A practical control boundary between an autonomous coding run and the moment a human reviewer is asked to trust its output.

By Joel Rietzle · Updated July 27, 2026 · 7 minute read

AI-agent change control is a pre-review workflow that checks an agent’s authorized scope, observed repository changes, declared verification, sensitive surfaces, and missing evidence before its code enters human review.

Why ordinary code review starts too late

A pull-request diff shows the resulting code. It does not reliably show what the agent was authorized to do, whether the repository was already dirty, which commands actually ran, whether sensitive files require approval, or which parts of the agent’s summary are supported by evidence.

That creates a review-readiness problem. Reviewers spend their first minutes reconstructing the run instead of judging the change. Green CI helps, but it answers whether configured checks passed—not whether the work arrived with a trustworthy boundary and complete enough evidence.

The five parts of a useful control boundary

  1. Authorized scope: the human-approved objective and surfaces the agent may change.
  2. Observed change: the repository delta attributed to the bounded session.
  3. Verification evidence: the declared commands and their recorded pass or failure state.
  4. Sensitive-surface policy: explicit treatment of auth, secrets, infrastructure, deployment, customer data, payments, or external mutation.
  5. Review decision: begin review, block for evidence, or request human approval—with the reason preserved.

Change control is not code correctness

A valid control record cannot prove that generated code is correct. Tests can be incomplete, requirements can be misunderstood, and an authorized change can still contain a bug. The control record should say exactly what it proves and what remains unknown.

It can establishIt cannot establish
Observed scope and files changedAbsence of all bugs
Declared checks passed or failedComplete semantic correctness
Sensitive surfaces were identifiedProduction safety or compliance
Evidence and gaps are explicitBusiness value or ROI

Where the gate belongs

The first useful enforcement point is immediately before AI-agent PR review. The agent finishes its bounded session, the local gate evaluates the recorded evidence, and the reviewer receives a decision before opening raw chat or beginning line-by-line review.

The operating rule is simple: no valid Run Control Receipt, no AI-agent PR review. A failed receipt is not a verdict on the code. It means the work is not yet ready to consume reviewer attention as a reviewable change.

How to introduce it without creating ceremony

Start with one active repository and one real control problem. Name the reviewer, verification commands, sensitive surfaces, approval owner, and evidence-retention path. Run the gate for two weeks and record whether each block caught useful missing evidence or merely repeated information the team already had.

The pilot is valuable only if it changes a real review or security decision. If reviewers ignore the receipt, blocks are confusing, or no one will enforce the rule afterward, the workflow has not demonstrated product value.

Related guide

Use the AI-generated code review checklist to turn this control model into a concrete pre-review workflow.

Test the boundary in one repository.

Run a two-week local/BYOC pilot with one owner, one reviewer, explicit verification, and a real enforcement rule.

Apply for a one-repo pilot