A small, named group, with a second person approving and every change logged. The setting that decides whether a bot can propose or merge fixes is a control on your software supply chain. If anyone can change it quietly, your review gates are only as strong as the weakest account.
Why the setting deserves protection
A mode or category switch changes how much the automation can do without a human. Moving from a manual mode to something more autonomous changes your risk the same way a branch rule change does. Yet it often sits in a settings page with looser access than the repositories it affects.
OWASP's excessive agency guidance names excessive autonomy as a root cause and recommends human approval for high impact actions. The decision to grant more autonomy is the highest impact action in the whole chain, so it should get the same scrutiny.
A simple policy
- Named roles. Two or three people can change modes: for example a security engineering lead and a platform lead. Everyone else has read access.
- Two person rule. The requester cannot also approve. See the related post on whether the person who triggered a fix PR can approve it for the same principle applied to pull requests.
- A written reason. Each change links to evidence: the proposal count, acceptance rate and revert rate from the manual period.
- One change at a time. One category per change, so effects can be attributed.
- A review date. Every increase gets a scheduled check, with the option to step back.
- Alerting. A mode change notifies a channel the team watches.
What the record should hold
| Field | Why |
|---|---|
| Who requested and who approved | Accountability and separation of duties |
| Setting before and after | Reconstruction |
| Date and time | Ordering against incidents |
| Linked evidence | Justifies the decision |
| Review date | Prevents drift into permanent trust |
Keep it where you keep other change records, not in chat.
Treat reductions differently
Lowering autonomy should be easy. Anyone on call should be able to move a category back to manual during an incident without a second approver, then report afterwards. Asymmetry is intended: raising risk needs approval, reducing it does not. For the stop procedure itself, see how to pause every fix PR during an incident.
Check who really has access
Run a quarterly access review of the settings page, the API tokens that can change it, and any service account with the same reach. Tokens are the usual gap. A script with an old admin token can change a mode without anyone seeing the page.
Auditor view
Reviewers of change management controls tend to ask for the same things: who is authorized, who approved this change, and where is the evidence. If you answer with a role list, a ticket and an access review, you have a coherent story. Avoid describing it as meeting any specific standard unless your own assessor has said so.
Safeguard offers autonomous remediation with fix PRs, off by default and Manual in every category. Whoever changes that, apply the policy above.
Quick check
Should lowering autonomy need the same approval as raising it?
No. Make reductions fast, so responders can step back during an incident, and review them afterwards.
Where do API tokens fit in?
Any token that can change the setting is as powerful as an admin login. Inventory them and review them on a schedule.
Sources
Last reviewed: 19 October 2026.
