Pick two or three repositories, keep every action on manual approval, define success measures before you start, and review the results on day 10. A good proof of concept answers one question: would your team merge these pull requests, and would it trust the process behind them.
Before day one
Write down what a pass looks like. Vague goals produce vague results.
| Criterion | Example target you set |
|---|---|
| Merge rate of proposed PRs | A level your team finds acceptable |
| Build breaks after merge | None, or fewer than your manual baseline |
| Review time per PR | Lower than doing the fix by hand |
| Evidence quality | Reviewers say descriptions are enough |
| Setup effort | Hours, not weeks |
Choose repositories with different stacks, with an owner who will actually review. Avoid your most fragile service and your quietest one.
Days 1 to 3: connect and scope
Install with minimum permissions, as in what permissions a remediation bot should have. Confirm the tool respects your branch protection and does not require merge rights. Set a cap on open pull requests.
Days 4 to 10: review for real
Treat every proposed PR as production work. Use the fix PR reviewer checklist. Record for each: merged as is, edited, or closed, with a reason. Note anything surprising, such as an edit to a file you did not expect.
Days 11 to 14: assess and decide
Compare with the criteria. Also ask the less obvious questions:
- Does it explain why a fix is right, with evidence?
- Can you turn everything off, and is that the default state?
- Is there an audit record of each action and approval?
- How does it handle a dependency with no fix?
- What happens to our data, and where does scanning run?
Red flags
A tool that opens many pull requests at once, ignores your ownership files, edits generated code, or cannot show why it chose a version. Also a tool that needs wide permissions for a narrow job.
What the result should be
A short written decision: proceed, proceed with changes, or stop, with the numbers behind it. If proceeding, use the 90 day rollout plan rather than switching on everything. More buying questions are in questions to ask before a tool opens fix pull requests.
Where Safeguard fits
Safeguard's autonomous remediation ships off by default with every category on Manual, which suits a proof of concept. You can start with a free scan.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how findings move from detection toward a fix and what a reviewer sees along the way.
Quick check
Can a proof of concept run in production repositories?
Yes, if the tool only opens pull requests and branch protection stays on. Do not give it merge rights.
How many pull requests make a fair sample?
Enough to cover each change type you care about. If volume is low, extend the period instead of lowering the bar.
Last reviewed: 19 October 2026.
