- CrowdStrike says an AI model's refusal to explain a single function led its researchers to a planted bug. The post names no model.
- CrowdStrike reports 73 of 86 controlled scenarios as correct. It does not define correct or report how often the signal fired on clean code.
- Leaders should ask what their AI tools log and what vendors watch for. Treat this as one vendor's early, self-reported result.
A guard who will not walk down one corridor has told you something about it, though he does not say why. CrowdStrike says an AI model did this with a piece of code, and the company built a method on it. The idea is interesting. It is also early, and the details matter.
What CrowdStrike reports
CrowdStrike published its research on October 28, 2026. Its researchers asked an unnamed "frontier model" to explain the functions in a small C web server. The model explained all of them but one. In that function, the team had swapped a "max" for a "min". This tiny change lets the program write data outside the memory it owns. That flaw is called an out-of-bounds write.
The team had not asked about security. The model did not call the code vulnerable. It simply would not explain it. CrowdStrike says that change in behaviour pointed to the flaw.
Read the limits first
Several details are missing. The post names no model, vendor or version. It describes its example with one unnamed frontier model. It does not say which model, or how many models, produced the 73 of 86 figure. It does not show that every AI assistant behaves this way.
CrowdStrike calls its method Guardrail-based Vulnerability Discovery. In controlled tests covering five vulnerability classes, it says the method got 73 of 86 scenarios right. The post does not define "correct". It also does not say how often the model balked at clean code. Without a definition of correct and a false-alarm rate, 73 of 86 cannot be read as an accuracy score.
CrowdStrike also says similar results appeared on real open-source projects, which it reported through its disclosure program. The post gives no count and no detail for those cases. A reader cannot check that claim from the post. Every figure here is the vendor's own.
How a refusal becomes a search tool
AI labs train models to decline requests that could help attackers. CrowdStrike argues that a model must first notice something dangerous before it can decline. That notice, in its view, is a signal people can read.
The post says this safety check can be more sensitive than the model's normal answers. Asked directly whether code is vulnerable, a model gives answers CrowdStrike calls noisy and wordy. The post offers only a high-level account of why the refusal fires, and shows no evidence of what happens inside the model.
The signal is a yes or no tied to a place. That suits a search method called bisection. Cut the code in half and ask about each half. Keep cutting whichever half draws the refusal. Each round shrinks the search until one function is left.
Model answers vary, so the team ran each prompt five times. It counted a refusal only when three or more runs refused.
Beyond source code
A second test looked at a file system. The team planted a SUID-root program, which runs with top-level rights, and which could run any command. This is a well-known route to taking over a machine. The model was asked to audit the files.
When the audit reached that file, the model's analysis stopped. CrowdStrike describes this as an interrupted line of reasoning, not an outright refusal. The same splitting method found the directory and then the file.
Why one refusal is weaker evidence
A purpose-built harness read this signal. A harness is the software around a model that decides what to ask and how to record the answers. Here it ran every prompt five times and cut the code down step by step.
A single refusal in an everyday internal code assistant is much weaker evidence. This is the publication's inference. The post does not test that case.
CrowdStrike argues the harness decides the result as much as the model does. It adds that timing, token counts and hedging language could be read the same way. It also says the refusal signal may shift as safety training changes, and that attackers could use the idea too.
Questions for your team
Ask your security team whether your AI tools record refusals and odd behaviour. Ask who reads those records. Do not expect one log entry to point to a bug.
Ask your AI vendors whether they watch for repeated probing of their safety checks. Bisection means many prompts on shrinking slices of code. A vendor could plausibly watch for that pattern. That is our inference. CrowdStrike does not discuss detection.
Before relying on the method, ask for the missing numbers. What does "correct" mean? How often does the signal fire on clean code?
The lesson here is that a safety feature can leak what it protects. A guard who stops at one door has still drawn a map. The map may contain errors.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: CrowdStrike.
