Enforcing Human Review at the Build‑Intent Gate for Agent Writes

The hidden risk of unchecked agent writes

A typical deployment lets an autonomous agent call the Build‑Intent endpoint, receive a proposal, and write the files straight to the repository. The code that decides “I should add this helper” runs in the same process that ultimately mutates the code base. When the agent’s internal prompt or configuration is wrong, the repository receives an unwanted change without any human eyes on it. The failure mode is clear: the gate between decision and commit is bypassed, so policy cannot intervene and code approval never happens.

Why the Build‑Intent gate is a reliable control point

The Build‑Intent gate is the moment an agent submits a write request. At that instant the system knows the full intent – the list of files, the diff, the target branch – before any filesystem operation occurs. Because the gate is model‑independent, the request can be inspected, logged, and rejected without relying on the agent’s internal state. This makes it the natural place to enforce agent governance. If a policy check runs after the write, the damage is already done; if it runs before, the write can be stopped outright.

Enforcing a mandatory policy review

The policy we need is simple: every Build‑Intent proposal must be marked pending review and cannot progress to the commit phase until a human reviewer explicitly approves it. The implementation consists of three steps.

1. Register a review‑required flag – When the agent calls the Build‑Intent endpoint, the request payload includes a requiresApproval field. The gate sets this flag to true for all proposals, regardless of the agent’s origin.

1. Reject any commit without a verdict – The gate checks the flag before allowing the write. If the flag is still true, the response is a 403 with a message “approval required”. The agent receives a dry‑run result that can be inspected in the preview sandbox.

1. Expose a human approval UI – A lightweight dashboard lists pending proposals, shows the diff, and lets a reviewer click Approve. The approval flips the flag and re‑submits the same intent, this time passing the gate.

Because preview runs remain free, the agent can still test its changes in an isolated sandbox. The sandbox execution is recorded by the certification harness, yielding a PROVISIONAL verdict that the reviewer can examine. No code ever reaches the repository without a human sign‑off.

A concrete walk‑through

Imagine an agent that generates a new logging helper. It sends the following JSON to the Build‑Intent endpoint:

{
  "files": [
    {
      "path": "src/utils/log.ts",
      "content": "export const log = (msg) => console.log(msg);"
    }
  ],
  "branch": "feature/log-helper",
  "requiresApproval": true
}

The gate receives the request, stores the diff, and returns a preview URL. The agent runs the preview in the sandbox; the harness records a PROVISIONAL verdict because the code compiles and the tests pass. The pending proposal appears in the approval dashboard:

Proposal: Add src/utils/log.ts
Branch: feature/log-helper
Status: awaiting human approval

A senior developer opens the diff, verifies that the helper follows the project’s logging conventions, and clicks Approve. The system flips requiresApproval to false and re‑invokes the same Build‑Intent payload. This time the gate lets the write pass, and the commit lands on the target branch.

The entire flow is governed by the same gate that already meters agent proposals, as described in the pillar post /blog/governing-code-agents-at-the-build-intent-gate. No additional runtime checks are needed inside the agent, and the repository never sees an unauthorised change.

What you can do on Monday

Add a global policy rule that sets requiresApproval: true on every Build‑Intent request. Deploy the simple approval UI to your internal tooling, and point your agents at the same endpoint they already use. Run a single preview on an existing repository to confirm that the gate returns a preview URL and that the write is blocked until you click Approve. After a day of observation you will have a concrete audit trail and a clear line of responsibility for every agent‑generated change. This small change mitigates a key risk in agent governance without altering your existing CI pipelines.