When AI Guardrails Expose Vulnerabilities

CrowdStrike researchers developed Guardrail-based Vulnerability Discovery (GbVD), a method that treats an AI model's refusal to explain code as a signal pointing to a vulnerability, and it was correct in 73 of 86 test scenarios across five vulnerability classes. The approach was triggered when a frontier model declined to explain a single function in a small C web server after explaining every other function, a function containing a one-character max-to-min inversion that creates an out-of-bounds write. CrowdStrike said the technique held up on real open-source projects disclosed through its Coordinated Vulnerability Disclosure program, and argued that every guardrail improvement also sharpens a method cybersecurity practitioners or adversaries can use.

CrowdStrike researchers asked a frontier AI model to explain a function in a small C web server. While it had previously explained every other function in the codebase without hesitation, it refused to explain this one. The request was routine. We'd only asked what the code does; we hadn't asked about security, exploits, or vulnerabilities. But a single token in the code had changed: a max swapped for a min; a one-character logic inversion that creates an out-of-bounds write. It's the kind of bug that slips past code review and that pattern-matching scanners routinely miss. The model never said there were any vulnerabilities, but its refusal to explain the function indicated there could be one. The act of the model changing behaviors on a specific chunk of code showed us exactly where to look for the vulnerability. Its guardrails became the giveaway. That moment changed how we think about AI safety. The guardrails frontier labs build to keep models from helping attackers can't work without first recognizing that something is dangerous. This recognition is a signal that practitioners can read. Most of the industry treats refusals as a dead end; at CrowdStrike, we started treating them as findings. We call this approach Guardrail-based Vulnerability Discovery GbVD . In controlled tests across five vulnerability classes, it was correct in 73 of 86 test scenarios, and it held up on real open-source projects we disclosed through our Coordinated Vulnerability Disclosure CVD program. Safety and capability are usually framed as a trade-off. This research suggests the opposite: Every improvement labs make to their guardrails also sharpens a methodology that cybersecurity practitioners or adversaries can use. This work builds on our earlier research into LLM safety classifiers https://www.crowdstrike.com/en-us/blog/how-attackers-can-bypass-llm-safety-classifiers/ , where we studied how those guardrails can be bypassed. Here, we look at the other side: what guardrails reveal when they work as intended. Breaking Down Guardrail-based Vulnerability Discovery Today, the most visible manifestation of a guardrail is a refusal: The model declines in plain text or with “ reason: cyber ” in standard APIs , which makes the signal trivially readable. But refusals are just one observable among several. Guardrails in deployed AI systems take many forms, and most of them leak: - Explicit refusals : The current dominant case, and the one our experiments exploit. - Model downgrading : Some platforms route sensitive requests to a smaller or more conservative model. The routed response betrays itself through measurable differences: response latency, tokens spent, time-to-first-token, or a sudden drop in output specificity and style. - Output filtering and truncation : A post-hoc filter that redacts or cuts off a response changes its length and shape in detectable ways. - Reasoning interruption : In agentic settings, a guardrail may abort a tool call or halt a chain of reasoning mid-task rather than emit any refusal text at all we observe this in our second case study . Whatever form the guardrail takes, triggering it perturbs some measurable property of the response, such as content, timing, token count, or structure. The defender doesn't need the model to say anything explicitly; rather, they need only to measure the perturbation. Our experiments below use refusals because they are today's loudest channel, but the methodology is agnostic to how the guardrail manifests. A binary, localized signal composes naturally with classic techniques, including bisection : split a codebase or filesystem into halves, ask the model to explain each half, and recurse into whichever half triggers the guardrail. The model never has to say "this is vulnerable"; it only has to behave differently in the right place. Table 1 summarizes our experiments.