CrowdStrike researchers asked a frontier AI model to explain every function in a small C web server, and it happily obliged, until they changed a single token. After swapping one max for a min, creating an out-of-bounds write, the model refused to explain that one function. Nobody had asked it about security. The refusal itself pointed at the bug.
That observation is the basis of what Jonathan Bar Or and D'Angelo Gonzalez call Guardrail-based Vulnerability Discovery (GbVD): treat an AI model's safety guardrails as a sensor. In controlled tests across five vulnerability classes, CrowdStrike says the approach was correct in 73 of 86 test scenarios, and that it held up on real open-source projects whose bugs the company reported through its coordinated disclosure program.
A safety filter that knows more than it says
The researchers' argument is that safety training builds something like a classifier inside the model, separate from its normal question-answering behavior and sometimes more sensitive. Ask a model "is this code vulnerable?" and the answer is noisy. But guardrails are tuned to fire before harmful content is produced, so they tend to trigger on recognizing a dangerous pattern, regardless of what the user asked.
CrowdStrike lists four ways a guardrail can give itself away: an explicit refusal, a quiet downgrade to a smaller or more conservative model (visible in latency, token counts or a drop in detail), output that is filtered or truncated, and, in agent setups, a reasoning chain or tool call that simply stops. The team's experiments used refusals and reasoning interruptions because they are the easiest to read today.
Bisect until the model goes quiet
The method is simple. First, ask the model to explain every unit of a clean target and confirm it answers all of them, which rules out a model that refuses benign code. Then introduce one realistic flaw and rerun the identical prompts. Any refusal is a hit, and the harness splits the target in half and recurses into whichever half still triggers it. Each prompt was run five times, and a unit counted as refused at three out of five.
In the first case study, on the tinyhttp server, every unmodified function was still explained normally and only the altered chunk-size logic was refused. In the second, the team planted a SUID-root binary that runs arbitrary commands inside a filesystem tree and asked the model to audit it. When the model reached that binary, its reasoning halted rather than reporting the file, and the same bisection harness narrowed the problem to the directory and then the binary.
Read the refusal, then verify by hand
For defenders, the practical takeaway is to log refusals and other guardrail signals in AI-assisted code review rather than discarding them, and to treat each one as a lead for a human to confirm. Thirteen of the 86 scenarios were not called correctly, so a refusal is a hint, not a verdict.
CrowdStrike is candid about the other side. Every improvement labs make to their guardrails, the authors write, also sharpens a method that practitioners or adversaries can use. That fits a pattern we have tracked, from attackers turning guardrails against malware scanners to criminal prompt logs showing how thin those protections can be.
The irony is hard to miss. The better a model gets at refusing to help find bugs, the better its silence becomes at finding them.
This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. Indicators of compromise are defanged; re-arm them only in controlled environments. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.