Limit each fix pull request by files, lines, directories and new dependencies, and limit how many a bot opens per day. When a change exceeds a cap, it should fall out of the automatic path and go to a person. Caps turn a surprising change into an obvious one.
Why caps work
A bad fix that touches one line is easy to review and cheap to revert. A bad fix that touches forty files is neither. OWASP's guidance on excessive agency recommends limiting functionality and enforcing authorization outside the model, and notes that rate limiting can reduce damage from unwanted actions. Size and scope caps are those ideas applied to a diff.
They also help reviewers. A pull request that fits a screen gets read. One that does not gets skimmed.
Starting limits
These are examples to tune against your own history, not standards.
| Limit | Example starting point | If exceeded |
|---|---|---|
| Files changed | A small handful | Route to a person |
| Lines changed | A few dozen for dependency fixes | Route to a person |
| Directories | One service or package | Split or reject |
| New dependencies | Zero unless the finding requires one | Reject and flag |
| Open bot pull requests | A fixed small number per repository | Queue the rest |
| Opened per day | A fixed number per repository | Defer |
| Path allowlist | Manifests, lockfiles, in scope source | Reject out of scope paths |
Derive your numbers from the last three months of accepted fixes. If ninety percent of accepted dependency fixes changed fewer than five files, a cap slightly above that covers normal work and flags the rest.
Different caps for different categories
A patch level dependency update and a source code change are not the same risk. Give each category its own limits. Container base image changes can touch many layers and deserve a lower volume cap and closer review. Code changes should have tight line limits, since each line carries logic.
Scope: where the change may land
Size is one axis and location is the other. Define allowed paths and block the rest outright:
- Allow dependency manifests and lockfiles for the area of the finding.
- Allow source files named in the finding.
- Block workflow definitions, deployment files, protection settings, secret stores and the bot's own configuration.
Enforce it in code at the pull request stage, using a required check that inspects the diff. See validate AI generated patches with deterministic checks.
Volume caps and queue health
A cap on open pull requests prevents a flood, but a full queue means reviewers are behind. When the cap is hit repeatedly, that is a signal to fix review capacity or grouping, not to raise the cap. See how many fix PRs a bot should have open at once.
When a change exceeds a cap
- The bot does not open it as an automatic candidate.
- It is labeled for human attention with the reason.
- A person decides: split it, accept it with extra review, or defer.
- The decision is recorded.
Never solve repeated cap hits by raising the limit without looking at why they happen.
Review the caps
Each quarter, review rejection rates by cap. A cap that never triggers may be too loose. One that triggers constantly may be too tight, or may point at a repository that needs manual attention.
Safeguard offers autonomous remediation with fix PRs, off by default with every category on Manual, so limits like these are something to decide before any category moves.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how a change moves from finding to a gated decision.
Quick check
What is the right line limit?
There is no universal number. Base it on your own accepted fixes, set slightly above normal, and review it each quarter.
Should caps apply to human fixes too?
Not necessarily. Caps exist because automated changes arrive without a person who wrote and understands them.
Sources
Last reviewed: 19 October 2026.
