A refusal from an AI system can look straightforward. A request was submitted, the system declined to answer, and the interaction ended.
But that response does not reveal what actually happened.
The request may have reached the underlying large language model, which then refused it because of its learned safety alignment. Alternatively, a separate guardrail may have intercepted the request and blocked it before the model ever saw it.
Those are two fundamentally different security events. Yet in production AI systems, they can produce almost identical responses.
Mindgard’s new research paper, “Behind the Refusal: Determining Guardrail Activation via Behavioral Monitoring,” introduces a black-box reconnaissance methodology for separating them. With no knowledge of the model, guardrail or system architecture, the approach detects whether a guardrail is present, identifies the types of content it is designed to block and learns how its activation can be recognized in future interactions.
Guardrails and LLM safety alignment protect different layers of an AI system.
A guardrail is typically deployed as middleware that evaluates prompts or model outputs against predefined security and safety criteria. It may look for prompt injection, jailbreak attempts, toxic content or other policy violations and prevent that content from reaching the model or end user.
Safety alignment, by contrast, is learned by the LLM during training. When the model recognizes a request as harmful or prohibited, it generates its own refusal.
The distinction matters because bypassing these defenses requires different approaches.
Guardrail evasion techniques attempt to exploit gaps in a classifier or detection system. Jailbreak and prompt injection techniques target the model’s learned refusal behavior or the instructions governing the wider AI application.
An attack that cannot determine which layer rejected its prompt may continue mutating against the wrong defense. That wastes queries, reduces effectiveness and creates a threat model that does not accurately represent attacks against real production systems.
Many automated jailbreak, prompt injection and guardrail evasion techniques depend on feedback from the target.
A multi-turn attack might interpret a refusal and use it to decide how the next prompt should be changed. An adversarial evasion technique might repeatedly alter an input until the guardrail’s classification changes.
In many research environments, the attacker is given direct or indirect access to the guardrail decision. They know that a guardrail exists and can tell when it has activated.
Production systems rarely provide this level of visibility.
A guardrail block might return a non-200 status code, an explicit explanation or a special response header. But it can also return a standard 200 response containing a generic phrase such as “I’m sorry, I can’t help with that.”
From the outside, that may be indistinguishable from a refusal generated naturally by the LLM. The feedback signal that many attacks rely on has effectively disappeared.
Behind the Refusal addresses this gap by adopting a stricter and more realistic threat model: the system is entirely unknown and the researcher can observe only the responses returned through its API.
The methodology analyzes how an AI system behaves under benign and malicious interactions. It consists of four stages.
The process begins by sending benign prompts to the target. These prompts cover different subjects and interaction styles but are designed not to trigger either a guardrail or the model’s safety alignment.
The responses establish a baseline for how the system normally behaves.
Separate malicious prompt sets are then used to test categories such as prompt injection, jailbreaks and toxicity. Each set is designed to activate a relevant guardrail without unnecessarily provoking the underlying LLM into generating its own refusal.
Because the methodology assumes black-box access, it relies only on information visible through the API. The researchers group these signals into three categories:
A guardrail may, for example, return a different status code, add a content-filter header or repeatedly produce the same canned response. It may also respond more quickly because the request was blocked before the LLM began generating content.
The system statistically compares the features observed during benign and malicious interactions.
Significant changes can reveal that an additional defensive component has intervened. The direction of each change is also considered. An increase in non-200 responses or a reduction in total generation time, for example, may indicate a guardrail block.
The research found that HTTP and lexical signals were the most reliable indicators. Timing provided useful supporting evidence but could also produce false positives because malicious prompts sometimes cause an unprotected LLM to generate shorter responses.
Once the approach detects a guardrail, it records the combination of signals associated with its activation.
This block-pattern fingerprint can include status codes, response structures, headers, recurring language and other characteristics. It can then be applied to future interactions to determine whether a new refusal came from the guardrail or the underlying model.
The methodology also compares results across different malicious prompt categories. This reveals whether the guardrail appears to detect prompt injection, jailbreaks, toxicity or a combination of these categories.
Mindgard evaluated the methodology using nine guardrail systems, six different blocking patterns and three underlying LLMs: GPT-4.1, Claude Sonnet 4-6 and Gemini 2.5 Flash. Together, these produced 162 distinct guardrail-enabled AI system configurations, alongside a no-guardrail control.
Each reconnaissance run used only 40 prompts: ten benign prompts and three malicious sets containing ten prompts each.
The approach detected guardrail presence with 100% accuracy across the evaluated targets and produced no false positives against the unprotected control. Every evaluated guardrail showed highly significant behavioral separation between benign and malicious interactions.
By comparison, an approach relying only on HTTP signals achieved 67% detection accuracy because some blocking patterns did not visibly change the HTTP layer. An LLM judge reviewing response bodies achieved 86% detection accuracy but incorrectly identified a guardrail in 33% of the no-guardrail controls.
The methodology also recovered all six expected block-pattern fingerprints. When these fingerprints were tested against 100 previously unseen prompts, they distinguished guardrail blocks from LLM refusals with an average F1 score of 98%. Five of the nine evaluated guardrails achieved perfect separation.
The recovered content categories also broadly matched the capabilities stated by guardrail vendors. One additional weak jailbreak signal was found for a classifier described as detecting prompt injection, illustrating the overlap that can exist between prompt injection and jailbreak content.
Reconnaissance is a fundamental part of conventional offensive security. Before choosing an exploit, an attacker gathers information about the target’s technologies, defenses and behavior.
AI red teaming requires the same discipline.
Without reconnaissance, a test may treat every refusal as though it came from the same defensive mechanism. This can lead researchers to apply jailbreak techniques to a guardrail classifier or guardrail evasion techniques to an LLM’s safety alignment.
Behind the Refusal provides the missing feedback layer.
By detecting hidden guardrails and learning their blocking behavior, red teams can adapt their testing to the system they are actually facing. They can determine which categories appear to be protected, identify where defenses may overlap and distinguish an unsuccessful jailbreak from an input that never reached the model.
This makes automated attacks more effective, but it also makes the resulting assessment more realistic. Security teams receive evidence about how their deployed AI system behaves as a complete stack, rather than results based on assumptions about its individual components.
A generic refusal should not be treated as proof that an AI system’s guardrails are working.
The refusal may have come from the underlying model. A guardrail may be present but configured to detect only certain content categories. Multiple defenses may also produce similar responses, masking which control actually intervened.
For defenders, the research reinforces several practical principles:
Behind the Refusal shows that even when an AI system conceals its internal architecture, its defenses can still leave measurable behavioral signals.
Understanding those signals gives offensive security researchers a more realistic way to test AI systems. It also gives defenders a clearer view of which security layer is responding, what it appears capable of detecting and where further testing is required.
Read the full paper on arXiv: https://arxiv.org/pdf/2607.02121
Mindgard, the leading provider of AI security solutions, helps enterprises discover, assess, and defend their AI systems. Spun out from over a decade of AI security research at Lancaster University and headquartered in Boston and London, Mindgard combines AI red teaming with offensive security expertise and AI research to identify exploitable vulnerabilities in AI models, agents, and applications before attackers do.
