Limit the blast radius of automated fixes with five controls: cap how many PRs can be open, group related updates, delay brand new releases, scope automation to a few repositories first, and keep a kill switch. Each control turns a possible all-at-once failure into a small, reviewable event.
Cap open pull requests
A bot that opens fifty PRs overnight creates review fatigue, and fatigue leads to rubber stamping. Dependabot illustrates the idea: its open-pull-requests-limit setting caps version update PRs open at any time. Per its documentation, once the limit is reached no further PRs are raised until some are merged or closed, and setting it to zero disables version updates for that package manager. Security update PRs have a separate fixed limit of 10 open pull requests that this option cannot change.
Whatever tool you use, find the equivalent knob and set it low enough that one person can review the queue in a day.
Group deliberately
Grouping combines updates into fewer PRs. By default Dependabot opens one PR per dependency, and when groups are defined, dependencies matching a rule go into one PR. Grouping reduces noise, but a large group makes it hard to find the change that broke something.
A sensible split: group patch updates of low risk libraries together, and keep anything critical or major as its own PR so a revert is clean.
Delay brand new releases
Dependabot applies a default cooldown of 3 days to version updates, so a new version is not considered until three days after release, and that default does not apply to security updates. You can set longer periods per semver level. The aim is to let the community notice a bad release before you take it. Security fixes are the exception, because waiting has its own cost. See dependency cooldown periods as a malware defense.
Scope by repository and category
Start with repositories that have good tests and low business risk. Keep sensitive services, such as payments and authentication, on manual approval longer. Treat categories separately: dependency fixes, configuration changes and code edits do not share a risk profile. The pilot guide explains how to run this in practice.
Limit what the bot can touch
A bot that can only open pull requests cannot push to main. Remove bypass rights, restrict write scopes, and keep deploy credentials out of its reach. See least privilege for a remediation bot token.
Keep a kill switch
Know in advance how to stop the automation in one step: disable the category, pause the schedule, or revoke the credential. Write the steps down and test them once. During an incident you will not want to read documentation.
Watch the early signals
If the bot's PRs start failing checks in bulk, or several fix PRs are reverted in a week, pause and investigate before opening more. Track this using the fix PR quality metrics.
Quick check
What is a reasonable cap on open fix PRs?
There is no standard number. Pick one that a reviewer can clear in a working day, and raise it only when merge times stay short.
Safeguard's autonomous remediation is off by default with every category on Manual, which is the narrowest blast radius to start from.
Sources
Last reviewed: 19 October 2026.
