# Evasion: Refusal Suppression via Forbidden Response Strings

- **Severity:** High
- **Signature ID:** `d09b2519-5739-4f23-ab77-fef4d6056b78`
- **MITRE ATLAS:** AML.T0054 (LLM Jailbreak)
- **OWASP:** ASI01 (Agent Authorization and Control Hijacking), LLM01 (Prompt Injection), LLM09 (Misinformation)

## Summary

This attack targets the words an AI assistant is allowed to use, not its actual goals. By banning refusal phrases like 'I'm sorry' or 'I cannot' before it ever asks the harmful question, the attacker tries to strip the model of its normal way of declining.

## How the attack works

The attacker writes a prompt that lists forbidden words or phrases the response must never contain, typically refusal or apology language such as 'I cannot', 'I'm not able to', 'I'm sorry', or 'I must decline'. Some versions phrase this as a numbered rule set ('1. Do not apologize 2. Never say the words cannot, unable...'). This instruction is placed before the actual request, so the model's usual refusal vocabulary is off-limits by the time it sees the harmful ask. Deprived of its normal phrasing for saying no, the model is more likely to comply or produce a compliant-sounding answer even to a request it would otherwise refuse.

## Why it matters

An organization relying on a model's built-in refusals as a safety control can have that control quietly disabled per-request, leading to unsafe or policy-violating outputs being generated and possibly acted on downstream.

## What you can do

- Flag prompts that explicitly ban refusal or apology phrases, or that list forbidden words tied to declining a request.
- Do not treat the absence of refusal language in a response as proof the request was safe — check the underlying content itself.
- Review any legitimate use cases (e.g. 'no boilerplate disclaimers' style formatting requests) and scope exceptions narrowly so genuine safety refusals are never suppressed.
- Log and review cases where such instructions appear alongside sensitive or borderline requests, since the pairing itself is the strongest signal of intent.

## Known benign look-alikes

- Legitimate formatting instructions that ask the model to avoid boilerplate disclaimers in specific business contexts
- Test harnesses that explicitly check whether the model can respond without preamble

## References

- https://agentthreatrule.org/en/rules/ATR-2026-01015

---
Source: https://www.netzilo.com/threats/atr-evasion-refusal-suppression-via-forbidden-response-strings