Auto-approve a request when the package is already on your approved list, the change is a version bump within an agreed range, and every automated check passes. Send everything else to a person. The goal is to spend human attention only where a decision is truly open.
What "auto-approved" should mean
Auto-approval does not mean unchecked. It means the checks are machine-run and the result is recorded. A bump gets approved because a set of rules said yes, and that set is written down, versioned and reviewed like code.
If you cannot list the rules, you do not have auto-approval. You have a missing review.
Signals that allow auto-approval
All of these should hold together.
- The package name is already approved and has an owner on your list.
- The new version is a patch or minor release, and the previous version has run in your builds without incident.
- The version has been public for the cooling-off period you set. A related guide covers dependency cooldown periods.
- No new install scripts or native build steps appeared compared with the last approved version.
- The license is unchanged and still on your allowed list.
- A vulnerability scan shows no new finding at or above your blocking severity.
- The package still resolves to the same publisher and source as before.
Signals that force a human review
Any one of these is enough.
- A new package name, even a small one.
- A major version change, which often changes behaviour on purpose.
- A change of maintainer or repository owner.
- New or changed install-time scripts.
- A license change.
- A jump in the number of new transitive dependencies.
- A name that is close to a popular package, which can indicate typosquatting.
A decision table you can adapt
| Request | Decision | Reason |
|---|---|---|
| Patch bump, approved package, clean scan | Auto-approve | All signals hold |
| Minor bump, new install script | Review | Install path changed |
| Major bump, approved package | Review | Behaviour may change |
| New package, small, no scripts | Review, light | New name needs an owner |
| Package fails license policy | Block, exception route | Policy decision |
| Package flagged malicious by advisory | Block | No exception lane |
Keep a sample audit
Once a month, pull a random sample of auto-approved changes and have a person re-check them. The point is not to catch the machine out. It is to find rules that drifted, such as a scan that quietly stopped running for one ecosystem.
Record the rule version that approved each change. When an advisory later names a package you auto-approved, you can answer why it went through, and whether the rule needs a change.
Where Safeguard fits
Safeguard policies and gates can express rules like these and apply them to each pull request, and dependency scanning supplies the inputs. Autonomous remediation, if you turn it on, is off by default with every category on Manual, so nothing merges without your say. The free scan shows what a first pass finds.
Quick check
Can a major version bump ever be auto-approved?
You can allow it for a narrow, well-tested set of packages, but treat that as an explicit exception in the rules, not the default.
Does auto-approval remove the need for a security team?
No. It removes the repetitive cases so the team can focus on new packages, ownership changes and exceptions.
Last reviewed: 19 October 2026.
