Autonomous remediation should start off because a tool that changes your code needs trust earned in your environment, and trust cannot be assumed on day one. Start with every category on manual approval, watch the quality of the pull requests for a few weeks, then widen autonomy one category at a time.
What "off" really means
Off does not mean useless. A well designed remediation tool can still analyse, propose and open fix pull requests in a manual mode, where a person approves each action. What stays off is the ability to act without a human decision.
This matters because the first week with any automation reveals mismatches nobody predicted. Your repositories have odd build steps, unusual branch rules, forks, vendored code and tests that only run on Tuesdays. A tool tuned on average projects meets your outliers first.
Four reasons to start conservative
Your tests are the safety net, and you have not measured the net. Automated changes are only as safe as the checks that catch a bad one. Until you know how often your suite fails on a broken upgrade, you are guessing.
Different categories carry different risk. Updating a patch version of a dependency is not the same as changing a security posture setting or editing code. Treat them as separate decisions.
Review habits form early. If the first ten PRs are rubber stamped because they look tidy, reviewers learn to rubber stamp. If the first ten are read carefully, the team learns what a good fix looks like.
Auditors and customers ask who approved a change. A clear approval trail from day one is easier than reconstructing one later. See change management evidence for automated pull requests.
A sensible path from manual to more automatic
- Weeks 1 to 2: every category on Manual. Review every PR. Record why you reject any.
- Weeks 3 to 4: pick the lowest risk category and the lowest risk repositories. Keep approval manual, but shorten review expectations.
- After that: consider limited automatic merging only for changes that meet written criteria: small version jump, passing required checks, owner approval rules satisfied.
- Always: keep a kill switch and a rollback plan. The rollback plan template shows one.
Write the criteria down before you flip anything. "It has been fine so far" is a feeling, not a rule.
What to watch while it is manual
Count how many PRs you merge unchanged, how many you edit, and how many you close. Those three numbers tell you whether the tool understands your repositories. A high close rate means the tool needs tuning or the scope is wrong. Our post on metrics for fix PR quality covers this.
Where Safeguard fits
Safeguard's autonomous remediation ships off by default, and every category is set to Manual. Turning on more autonomy is an explicit choice you make per category. Gates and policies let you express the rules a change must meet before it merges.
Quick check
Does off by default slow down security fixes?
Slightly at first, because a person approves each change. The cost is small compared with learning about a bad automated change in production.
When can a category move beyond manual?
When you have written merge criteria, measured the acceptance and revert rates, and have a tested rollback path. Move one category at a time.
Last reviewed: 19 October 2026.
