AI Remediation Approval: Where the Human Review Gate Belongs

Automated remediation has a trust problem, and it is not about whether the agent can write the fix. It is about where a human signs off, what they are shown when they do, and what happens to the fixes nobody looks at.

Get the AI remediation approval gate wrong in one direction and you have an agent opening pull requests nobody asked for, in repositories whose owners never agreed to it. Get it wrong in the other and every fix waits for a security engineer to click a button, which rebuilds the exact bottleneck automation was supposed to remove. This post is about putting the gate in the right place.

Two different approvals, often confused

An agent-written fix passes through two decisions, and they belong to different people.

• Should this change be proposed at all? This is a policy question: which findings, which repositories, which kinds of change are allowed to turn into a pull request without someone asking. It belongs to whoever owns the remediation program.
• Should this change be merged? This is a code review question: is the diff correct, is it safe for this codebase, does it pass the checks this repository requires. It belongs to the repository's owners.

Most arguments about "human in the loop" collapse these into one gate. The result is either a security team reviewing code it does not own, or engineering teams receiving PRs they never agreed to take. Separate them, and each gate gets simpler.

Gate one: before a pull request opens

The first gate controls what reaches a repository. The question is not "is the fix good?" but "is this the kind of fix we want opened here, now, without asking?"

There are three workable positions, and a mature program uses all three for different classes of change:

1. Open automatically. The agent writes the fix, validates it, and opens the pull request. Right for high-confidence, low-complexity changes such as a direct dependency upgrade within a major version, on repositories that have opted in.
2. Hold for approval. The agent writes and validates the fix, then stops. An administrator reviews what it did and releases or discards it. Right while you are building trust in a new ecosystem, a new repository or a new class of fix.
3. Do not attempt. Some changes should always start with a human: major-version jumps in core frameworks, changes to authentication code, anything in a repository with no tests.

A held fix is only useful if the reviewer can judge it quickly. That means the approval screen has to show the proposed diff, the validation that ran and its result, and the exact findings the change claims to resolve. A reviewer shown only "the agent wants to open a PR" is approving blind.

Gate two: the merge

The second gate already exists, and you should not build a new one. It is your normal code review and branch protection.

An agent-written pull request should arrive looking like any other contributor's: a clear title in the format the repository uses, a body that says what changed and why, the CI results, and commits that satisfy the repository's rules, including signed-commit requirements. It then goes through the same required reviewers and the same status checks as a human's change.

The strongest argument against auto-merge is not that agents are unreliable. It is that merge authority is the one control your engineering organization already trusts, audits and understands. Routing automated fixes around it, even good ones, creates a second path to production that nobody reviews. Keep one path.

What makes a fix reviewable

Reviewers approve changes they understand and reject or ignore changes they do not. For automated remediation, reviewability comes from a few specific properties.

Validated before anyone sees it

A fix that has not been built and tested pushes the validation work onto the reviewer. Running the project's own build and test suite before the PR opens, and iterating on failures, is what separates a merge-ready change from a suggestion.

Grouped the way reviewers think

Ten near-identical pull requests for ten related dependency bumps in one repository is ten reviews, ten CI runs and ten merge conflicts waiting to happen. One validated PR that resolves all ten findings is one review. The reverse is also true: when reviewers want to accept or reject changes independently, one PR per fix is the better shape. The grouping should be a choice, not a side effect of the tool.

Scoped to the finding

A remediation PR that also reformats files, bumps unrelated packages or adds build artifacts gets rejected, and it should. The diff should contain the fix and nothing else.

Correctable in place

When a reviewer spots a problem, the fastest path is to say so in a PR comment and have the change updated, not to close the PR and start over.

The trust ramp

No team turns on fully automatic remediation on day one, and none should. Trust in automated fixes is earned the same way trust in a new engineer is: small, checkable changes first, then more autonomy as the record builds.

• Weeks 1 to 4. Hold every fix for approval. Restrict to the highest-confidence class, such as critical-severity direct dependencies with an available fix. Read every diff.
• Weeks 5 to 8. Let that class open automatically on repositories whose owners opted in. Keep holding everything else.
• After that. Widen by ecosystem and complexity, one step at a time, watching merge rate and revert rate.

Two numbers tell you whether to widen. Merge rate: what share of automated PRs are merged without changes. Revert rate: what share are merged and then undone. A high merge rate with a near-zero revert rate is the evidence that justifies the next step. Anything else is a reason to tighten the gate, not loosen it.

Common mistakes with AI remediation approval

• Security approves code it does not own. The security team becomes the reviewer of record for changes in hundreds of repositories. It does not scale and it is not their call.
• Approval without evidence. The approver sees a title and a button. No diff, no test results, no list of resolved findings.
• Auto-merge as the end state. The goal is fixes that need little review, not fixes that skip it.
• No audit trail. Six months later nobody can say who approved a change, what it claimed to fix, or which run produced it.
• One policy for everything. A patch release of a logging library and a major upgrade of a web framework do not deserve the same gate.

How Heeler places the gates

Heeler's remediation agent validates every fix through your own CI before anything is proposed, as described in Validate and Merge-Ready. Whether a validated fix opens a pull request immediately or waits is controlled by an Open pull requests automatically setting. It starts from a tenant-wide default and can be changed per workflow. With it off, the run stops at Awaiting Approval with the patch written and no pull request yet, and an administrator approves or discards it in Agent Executions, which also keeps the record of what ran and where each pull request stands.

Heeler opens the pull request. Merging stays with your reviewers and your branch protection. Remediation commits are signed, so they satisfy rules that require verified commits. A single run can resolve several findings in the same repository in one validated pull request, and bulk fixes can instead open one pull request per remediation when reviewers want each change on its own. Once a pull request is open, reviewers can ask for a change in a comment on it.

That is the model SCA Auto-fix and SAST Auto-fix run on: policy decides what gets proposed, your existing review decides what gets merged, and every step is recorded.

FAQ

Should AI-generated fixes ever be auto-merged?

Keep merge authority with your existing code review and branch protection. The aim is fixes that are quick to review because they are validated, scoped and explained, not fixes that bypass review.

Who should approve an automated remediation before the PR opens?

Whoever owns the remediation policy, usually the AppSec team or a platform team. They decide what classes of fix are proposed. Repository owners then review and merge the resulting pull request as they would any other.

What should an approver see before releasing a held fix?

The proposed diff, the build and test results from validation, and the list of findings the change resolves. Without all three, approval is a guess.

How do I know when to let more fixes open automatically?

Track merge rate and revert rate for each class of fix. Widen automation only where automated PRs are merged without changes and stay merged.

Is one PR per fix or one PR for many fixes better?

It depends on how your reviewers work. Related dependency upgrades in one repository review well as a single validated PR. Unrelated or risky changes are easier to judge one at a time.

The approval gate belongs in two places: a policy gate before a pull request opens, and your normal review before it merges. To see validated fixes held for approval or opened as merge-ready pull requests under that model, Get a demo.