Triage AI-generated security pull requests with a fixed gate: a reproduction you can run, a test that fails before the change and passes after, and a diff small enough to read. If any of the three is missing, ask for it once and close the pull request if it does not arrive.
The problem is volume, not origin
Whether a person typed the patch or a model drafted it does not decide its quality. What changes is cost. Generating a plausible looking pull request is cheap, and reviewing it is not. A maintainer who treats every one as a full review will lose the week.
So move the work back to the sender. Your gate should make a good pull request easy to pass and a careless one expensive to produce.
A three part gate
| Gate | What you ask for | Why |
|---|---|---|
| Reproduction | Exact steps or a script that shows the flaw on current main | Proves the problem exists |
| Failing test | A test that fails before and passes after the patch | Proves the patch addresses it |
| Small diff | One concern per pull request, no drive-by edits | Keeps review honest |
Put the gate in your CONTRIBUTING file and in the pull request template so the reply is a link, not an essay. A template sentence can read: "Security fixes need a reproduction and a test. Pull requests without them may be closed."
Signs worth a closer look
You cannot reliably detect machine-written text, and trying wastes time. Look at behavior instead:
- The description names a function or file that does not exist in your repository.
- The patch fixes a pattern that is not reachable from any public entry point.
- Tests were added that assert the new behavior but never exercised the old flaw.
- The change quietly adds or swaps a dependency.
- The author cannot answer a plain follow-up question about their own change.
Any of these is a reason to pause. None proves bad intent.
A reply that saves you time
Thanks. Before I review this I need three things: steps to reproduce
the issue on main, a test that fails without your change, and a diff
limited to the fix. If you can add those I will take another look.
Send it once. If nothing comes back in a couple of weeks, close with a pointer to the same text. You have been fair and you have your time back.
Keep your supply chain in view
A plausible looking pull request that edits a lockfile, a build script, or a workflow deserves the same care as an unknown contributor, whoever or whatever wrote it. See how to review a lockfile only security pull request for the dependency side, and pull request target risks for open source maintainers for CI exposure.
Where Safeguard fits
Safeguard's reachability analysis is built for the question that most of these pull requests skip: does your code actually call the vulnerable path? You can try a free scan at https://gold.safeguard.sh/scan on your own project. It gives you evidence to quote in a reply. It does not replace reading the patch.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how many findings disappear when only reachable code paths count.
Quick check
Should I ban AI-written pull requests outright?
That is your call as the project owner. A written policy that focuses on evidence (reproduction, test, small diff) is easier to apply fairly than a ban on how the text was produced.
How long should I wait for a reply before closing?
There is no rule. Two weeks is a common, polite window. State it in your template so nobody is surprised.
Last reviewed: 19 October 2026.
