A good pre-merge checklist for AI assisted remediation has ten items: reproduce the flaw, confirm root cause, check scope, read the test diff, verify facts at source, rescan, look for suppressions, check sensitive files, name a rollback, and have a named approver. Copy it into your pull request template.
The checklist
Paste this into a pull request template and tick each line.
AI assisted fix checklist
[ ] 1. Reproduced the flaw on the old code (steps in the description)
[ ] 2. The change addresses the root cause, not only the flagged line
[ ] 3. Every changed file ties to the finding (out of scope edits split out)
[ ] 4. Test diff read: nothing deleted, weakened or mocked away
[ ] 5. A test fails before the fix and passes after
[ ] 6. Versions, package names and advisory facts checked at source
[ ] 7. Rescan run with the same configuration: target closed, new findings explained
[ ] 8. No scanner suppressions, config exclusions or lowered thresholds added
[ ] 9. Sensitive files (CI, build scripts, lockfile, rules files) reviewed line by line
[ ] 10. Rollback owner named; approver is a person who did not trigger the fix
Why each line is there
Items 3, 4 and 9 come from failure modes OWASP's guidance on secure coding with AI describes: agents touching files outside the task, deleting or weakening tests to get CI green, and changing build and pipeline files that execute automatically. Item 6 reflects its warning that assistants may suggest outdated versions with known CVEs and package names that do not exist.
Items 1, 2, 5 and 7 turn "it looks right" into evidence. Item 8 closes a shortcut where the scanner is told to look away. Item 10 puts a person on the hook.
Which items can be automated
| Item | Automation idea |
|---|---|
| 3, 9 | CODEOWNERS and a check that flags sensitive paths |
| 4 | A check that flags test deletions or lower assertion counts |
| 6, 7 | Dependency audit and scanner run required in CI |
| 8 | A check that fails when suppression markers appear |
| 10 | Branch protection requiring approval of the latest push |
Items 1, 2 and 5 need a person. Automation can remind, not decide.
Adjusting by risk
For low risk changes, such as a patch bump of a test only package, you may collapse the list to items 3, 6, 7 and 10. For anything touching authentication, cryptography, input handling, infrastructure permissions or the pipeline, use all ten and add a second reviewer. See approval tiers for automated fix PRs for one way to set the tiers.
Try it yourself
Click through it at your own pace, or open it full screen. Look at which checks a pull request must pass, and map them to the items above that you could automate.
Safeguard's policies and gates can enforce required checks on a pull request, and its autonomous remediation is off by default with every category on Manual. For a reviewer oriented companion, see what to check before merging a fix PR.
Quick check
Is ten items too many for every pull request?
For low risk changes, use the short form. The full list is for changes where a mistake would be costly.
Who ticks the boxes?
The reviewer, not the author or the tool that opened the pull request.
Sources
Last reviewed: 19 October 2026.
