The dangerous part is often clearer after the model starts answering
Moderation usually begins with the user’s prompt. That sounds sensible. Read the request, classify the risk, block the bad thing, let the good thing through. A tidy little border checkpoint, complete with imaginary clipboard.
The problem is that jailbreaks are not polite enough to declare themselves at the border.
A malicious request can be wrapped in role-play, fiction, translation, policy evasion, instruction hierarchy confusion, or harmless-looking indirection. The prompt may look ambiguous. The answer the model is about to give is often not ambiguous at all. Once the model sketches its intended response, the hidden intent has a habit of taking off the fake moustache.
That is the core move in Reasoned Safety Alignment, or ReSA, from ByteDance Seed and Hong Kong Baptist University: stop trying to infer everything from the prompt alone; make the model privately draft what it would answer, then audit that intended answer before anything reaches the user.1
This is not merely “add more safety prompting”. ReSA is a training recipe for a specific reasoning habit:
- form a concise intended answer summary;
- check that summary against safety policy;
- release a helpful answer, refuse, or safely complete.
The paper calls this Answer-Then-Check. A less charming but more operational name would be: pre-output audit over intended behaviour. Less catchy, more accurate. Marketing weeps; governance breathes.
ReSA shifts the safety target from the prompt to the planned answer
Most jailbreak defences ask one of two questions.
The first is: Is this prompt unsafe? That is the input-filter worldview. It is fast and convenient, but it puts all the burden on decoding the user’s intent before the model has tried to answer.
The second is: Is this final answer unsafe? That is the post-hoc-filter worldview. It can catch dangerous completions, but by then the main model has already generated the risky material, and the system is usually left with a blunt decision: show it or suppress it.
ReSA inserts a third question in between:
What am I about to say, and would that be safe?
The distinction matters. ReSA’s intended answer summary is not the full answer. It is a compact representation of what the model would naturally produce. For benign queries, that summary helps the model avoid silly over-refusal. For harmful queries, especially adversarially disguised ones, it exposes the operational content that the prompt tried to bury.
The paper’s template wraps this private process in structured tags: an intended answer summary, then a safety analysis, then the visible final response. Only the final response is meant to be shown to the user. The private block is the audit trail, not the customer-facing performance.
In practical terms, ReSA teaches the model to behave less like a nervous bouncer staring at someone’s shoes and more like an editor checking the article before publication. Still imperfect, but at least now the editor has the article.
The dataset teaches four distinctions most safety systems blur
ReSA is not just a clever template. The authors construct an approximately 80K-sample dataset that trains the template into the model.
The important design choice is the dataset’s four-way balance:
| Query type | What it tests | Why it matters |
|---|---|---|
| Vanilla harmful | Directly unsafe requests | Basic refusal competence |
| Vanilla benign | Clearly safe requests | Normal helpfulness |
| Adversarial harmful | Harmful intent hidden inside jailbreak framing | Robustness against real attacks |
| Adversarial benign | Safe intent wrapped in jailbreak-like style | Resistance to over-refusal |
That fourth category is easy to miss and commercially important. Many “safe” systems become safe by becoming tedious. They see a dramatic prompt, a dangerous-sounding word, or a suspicious structure and decide the safest strategy is to become a stone. ReSA explicitly trains on adversarial-looking benign prompts so the model learns that style is not the same as substance. A pirate voice asking to turn off a lamp is still asking to turn off a lamp. AI safety, astonishingly, sometimes requires understanding idioms.
The construction pipeline has three main stages. First, the authors collect vanilla and adversarial prompts, starting from WildJailbreak and adding attacks such as PAIR, PAP, and GPTFuzzer. Second, they generate intended answers: an uncensored Dolphin model is used for harmful queries because aligned models tend to refuse before producing the very signal ReSA needs; Qwen2.5-72B-Instruct is used for benign ones. Third, they synthesize policy-grounded safety analyses using Llama3.3-70B-Instruct and classify/filter samples with Llama-Guard-3-8B.
There is a quiet but important engineering point here. ReSA does not require a proprietary frontier reasoning model to generate its training traces. The paper positions the method as accessible with strong general LLMs and guard classifiers. That does not make it cheap in a hobbyist sense; it does make it more reproducible than a method whose secret ingredient is “ask a model nobody else can inspect”.
The mechanism explains the headline result better than the headline does
The paper reports that ReSA-trained models substantially improve jailbreak defence while keeping over-refusal low. That result is interesting. The mechanism explains why it might happen.
A jailbreak often succeeds by making the harmful request look like something else. Input-level inspection must solve the disguise problem directly. ReSA avoids some of that burden by asking the model to summarize the answer it is preparing to give. Once the intended response contains the operational substance of the request, the safety classifier has a cleaner object to inspect.
This is why the paper’s comparison with “check-before-answer” approaches matters. Deliberative safety methods that reason over policy before answering are useful, but they may still be reasoning over an obfuscated prompt. ReSA reasons over the model’s own planned answer. It is the difference between auditing a pitch deck and auditing the actual wire transfer instructions.
The method is also not equivalent to post-hoc detection. A post-hoc filter can block an unsafe answer, but it usually cannot reshape the model’s behaviour into a better safe response. ReSA’s final answer is produced after the safety analysis, so the model can refuse, answer normally, or produce a safer alternative. That becomes especially relevant in self-harm contexts, where a hard refusal can be technically compliant and humanly useless. Congratulations, the bot is safe and cold. A classic enterprise trade-off.
The main evidence is a safety-utility trade-off, not a single leaderboard win
The experimental section tests ReSA on Llama3.1-8B-Instruct and Qwen2.5-7B-Instruct, using supervised fine-tuning and an RL variant. The models are evaluated across safety, over-refusal, general reasoning, and safe completion.
The headline safety numbers are strong. On StrongREJECT, using Llama-Guard as evaluator, ReSA-SFT on Llama3.1-8B-Instruct reaches an average defence score of 0.9046, compared with 0.7812 for post-hoc LlamaGuard, 0.8203 for STAIR-DPO, and 0.7173 for WildJailbreak SFT. ReSA-RL pushes that to 0.9932. The pattern is similar under the fine-tuned StrongREJECT evaluator and the HarmBench classifier, where ReSA-RL again leads.
For Qwen2.5-7B-Instruct, the LlamaGuard-evaluated StrongREJECT average rises from 0.3131 for the base model and 0.6494 for WJ-SFT to 0.8953 for ReSA-SFT and 0.9836 for ReSA-RL. That is not a rounding-error improvement. That is the model going from “please stop handing the intruder the keys” to “mostly remembering what keys are for”.
The stronger interpretation, however, is not “ReSA wins table”. The stronger interpretation is that ReSA improves the trade-off curve. Safety methods often buy robustness by increasing refusal. ReSA’s claim is that the answer-audit pattern improves robustness while preserving useful behaviour.
The over-refusal results support that claim. On Llama3.1-8B-Instruct, ReSA-SFT reaches 95.02% average over-refusal accuracy, while ReSA-RL reaches 96.84%. STAIR-DPO, despite good safety robustness, drops to 76.98%. On Qwen2.5-7B-Instruct, ReSA-RL reaches 96.02% average over-refusal accuracy. In plain English: the model becomes harder to jailbreak without becoming much more allergic to ordinary requests.
General reasoning is more nuanced. ReSA does not improve reasoning; it mostly preserves it. On Llama3.1-8B-Instruct, the base model’s average across MATH500, HumanEval, and MMLU is 61.85%. ReSA-SFT reports 59.78%, and ReSA-RL 57.58%. On Qwen2.5-7B-Instruct, the base model is 78.00%, ReSA-SFT 75.50%, and ReSA-RL 76.05%. That is a modest capability cost, not a free lunch. The paper frames this as maintaining general capability; the careful reading is that ReSA preserves most of it while buying substantial safety robustness.
That distinction matters for enterprise deployment. A system that becomes safer by quietly losing coding or mathematical reliability can create downstream risk under a nicer label. ReSA’s reported degradation looks manageable in these tests, but it is still something to measure in your own workload. Safety that hides capability loss is not governance. It is accounting with better fonts.
The comparison with stronger models is the useful reality check
One of the more useful experiments compares ReSA with advanced general and reasoning models, as well as prompt-engineered defences. The authors evaluate models such as GPT-4.1, Claude Sonnet 4, DeepSeek-V3, DeepSeek-R1, and o4-mini under a narrower attack set due to API cost.
The result is not that small open models magically become frontier systems. The result is more specific: a smaller model trained for this safety reasoning pattern can outperform stronger general models on this particular safety-utility trade-off.
In Table 4, ReSA-RL reaches 0.9920 average safety and 0.9727 average over-refusal accuracy. ReSA-SFT reaches 0.9330 and 0.9294 respectively. The implemented OpenAI-style Deliberative Alignment baseline reaches 0.9000 safety and 0.9244 over-refusal. Several general models either underperform on safety or improve safety with prompt engineering at a cost to over-refusal.
The operational lesson is not “fine-tune everything and ignore frontier models”. It is that safety behaviour is not only a function of raw model intelligence. It is also a function of what intermediate object the model is trained to inspect. ReSA gives the model a more legible object: its intended answer. For regulated or customer-facing systems, that is a design primitive worth stealing.
Politely, of course. With attribution. We are not animals.
Safe completion is where post-hoc filtering looks least satisfying
The safe completion section is small but important. The authors extract self-harm-related samples and train models to produce supportive, safety-aligned responses rather than direct refusals.
This is where post-hoc filtering reaches its product limit. A filter can block unsafe text. It cannot, by itself, generate a better response. In sensitive contexts, “I cannot help” may be safer than harmful compliance, but it is not necessarily the best safe behaviour.
The paper evaluates safe completion by pairwise comparison, using Qwen2.5-72B-Instruct and Llama3.3-70B-Instruct as judges. Scores above 0.5 mean ReSA-SFT is preferred over the baseline. For Llama3.1-8B-Instruct, ReSA-SFT scores 0.9510 against all-refusal and 0.8203 against post-hoc LlamaGuard under the Qwen evaluator; under the Llama evaluator it scores 0.9444 and 0.8333. For Qwen2.5-7B-Instruct, the corresponding scores are also clearly above parity.
This is not just a safety benchmark flourish. It points to a broader design issue: many enterprise safety systems treat refusal as the only safe terminal state. ReSA’s structure permits three terminal states:
| Situation | Weak safety behaviour | ReSA-style behaviour |
|---|---|---|
| Benign request | Answer | Answer |
| Unsafe request | Refuse | Refuse |
| Sensitive but helpable request | Refuse bluntly | Provide safe completion |
That third state is where safety becomes product quality rather than legal theatre.
The ablations show the habit matters more than dataset size
The paper includes ablations that should be read as mechanism tests, not decorative appendix furniture.
The first tests data size. The authors train on subsets of the ReSA dataset: 0.1K, 0.5K, 1K, and 5K examples. The surprising result is that 500 samples already yield strong robustness and generalization, close enough to the full dataset to suggest that the core behaviour is learnable from a relatively small curated set.
This does not mean your production agent can be safety-aligned with 500 random examples and good vibes. The samples are structured, policy-grounded, and built to teach a specific reasoning pattern. The finding is about behavioural leverage, not magic data compression.
The second ablation removes the extra PAIR, PAP, and GPTFuzzer-generated training data, leaving only WildJailbreak-derived samples. This “Only WJ” ReSA model still outperforms WJ-SFT despite using far fewer samples: 63K versus 262K. On Qwen2.5-7B-Instruct, LlamaGuard-evaluated average safety is 0.7548 for ReSA-SFT Only WJ versus 0.6494 for WJ-SFT. The full ReSA model reaches 0.8953.
That tells us two things at once. First, the Answer-Then-Check structure itself is doing real work. Second, jailbreak diversity still matters. The full dataset performs better, especially on attacks that require generalization. Structure gives the model the habit; diverse attacks teach it where the habit must survive.
Here is the clean reading of the experimental stack:
| Experiment | Likely purpose | What it supports | What it does not prove |
|---|---|---|---|
| StrongREJECT / AdvBench / HarmBench across multiple attacks | Main evidence | ReSA improves measured jailbreak defence | Universal robustness against future attacks |
| Over-refusal benchmarks | Main evidence | ReSA avoids much of the refusal tax | No false refusals in real products |
| MATH500 / HumanEval / MMLU | Capability check | General reasoning mostly survives | No degradation on domain-specific workflows |
| 0.1K–5K subset training | Sensitivity / data-efficiency test | The reasoning pattern can be learned from small curated sets | Any small dataset will work |
| Only-WJ ablation | Mechanism ablation | The Answer-Then-Check format matters | Jailbreak diversity is optional |
| Adaptive strategy | Implementation extension | Normal-query overhead can be reduced | No latency issue in every serving stack |
| RL intended-summary safety | Threat mitigation | Internal summaries can be made safer | Hidden reasoning is safe to expose by default |
That last row deserves its own section.
The hidden audit is useful precisely because it should usually stay hidden
ReSA’s private intended answer summary creates an obvious risk. If the model privately drafts unsafe content, what happens if that private reasoning leaks?
The paper treats this directly. The basic mitigation is simple: hide everything inside the safety-check block and return only the final answer. That is how many deployed reasoning systems already handle internal reasoning. The more interesting mitigation is the RL variant.
The authors evaluate the safety of the intended answer summaries themselves. Under the fine-tuned StrongREJECT evaluator, ReSA-SFT’s intended summaries average 0.7920 across several attacks. ReSA-RL raises that to 0.9951. In other words, RL training does not merely improve the visible final response; it makes the private planning artefact much safer too.
This is a useful result, but it should not be overread. A safer internal summary is not a general license to expose chain-of-thought. In production, the audit trace should be treated as a privileged diagnostic object. It may be logged, sampled, reviewed, or distilled into a user-facing explanation, but raw internal reasoning should not be casually rendered just because the chart looks attractive.
The business version is simple: ReSA creates a better internal control. Internal controls are not automatically customer copy.
Efficiency is better than the template makes it sound
At first glance, Answer-Then-Check looks expensive. The model writes a private summary, writes a safety analysis, then writes the final answer. Surely that means more tokens, more latency, and more CFO noises.
The paper’s efficiency analysis is more interesting. On harmful StrongREJECT queries, ReSA can be faster than the base model because a jailbroken base model may produce long unsafe completions, while ReSA detects the risk and issues a short refusal. For Llama3.1-8B-Instruct on StrongREJECT, the base model averages 537.89 response tokens and 190s runtime; ReSA-SFT averages 397.78 tokens and 27s. For Qwen2.5-7B-Instruct, the base model averages 642.75 tokens and 177s, while ReSA-SFT averages 461.62 tokens and 46s.
On benign reasoning tasks, the story changes. ReSA-SFT adds overhead because it still performs the private audit. On MATH500, Qwen2.5-7B-Instruct rises from 58s to 77s. That is not catastrophic, but it is not nothing.
The Adaptive Answer-Then-Check variant addresses this by training the model to bypass the audit path for normal questions. In the paper’s results, the adaptive version preserves comparable safety while returning closer to base-model efficiency on normal queries. For Qwen2.5-7B-Instruct on MATH500, adaptive ReSA is 62s, close to the base model’s 58s, and much lower than ReSA-SFT’s 77s.
For business systems, this matters because safety design often dies in the latency budget. A method that works only when every query gets a solemn private courtroom proceeding may be elegant and commercially dead. ReSA’s adaptive variant is therefore not a side quest. It is the version product teams would actually want to test.
Where this fits in an enterprise AI stack
ReSA is most useful when viewed as a pattern, not a single model checkpoint.
For a customer-support assistant, the model can draft its intended answer, audit whether it crosses policy lines, then respond with either normal help, safe redirection, or refusal. The gain is not just fewer unsafe completions; it is fewer absurd refusals on harmless but suspiciously worded queries.
For an internal coding assistant, Answer-Then-Check can help distinguish legitimate technical operations from requests that enable misuse. The model’s planned answer reveals whether it is about system administration, defensive analysis, credential theft, exploit deployment, or something else. The nouns alone are not enough; the intended procedure matters.
For agentic workflows, the same pattern becomes more valuable. Before taking a tool action, the agent can summarize its intended action plan, check it against policy, and only then execute. The audited object is not merely text; it can be a tool call, transaction, file operation, outbound email, database query, or customer-impacting workflow.
Cognaptus would translate ReSA into a control pattern like this:
| Layer | ReSA-inspired control | Business value |
|---|---|---|
| Chat response | Intended answer summary before final response | Reduces jailbreak success and false refusals |
| Tool use | Intended action summary before execution | Prevents unsafe or unauthorised actions |
| Logging | Store structured audit outcome, not raw unsafe content by default | Improves reviewability without expanding exposure |
| Escalation | Route uncertain audits to human review or stricter policy | Makes ambiguity operational rather than theatrical |
| Domain adaptation | Fine-tune or prompt on domain-specific policy categories | Aligns safety behaviour with actual risk |
The important inference is that Answer-Then-Check is not only an AI safety technique. It is an internal approval workflow compressed into model behaviour. That makes it legible to compliance teams, security teams, and product teams in a way that “the model felt unsafe” never will.
The boundaries are real, and conveniently not dramatic
The paper is strong, but its boundaries matter.
First, the results are benchmark-based. StrongREJECT, AdvBench, HarmBench, XSTest, OKTest, WJ-Eval, MATH500, HumanEval, and MMLU are useful probes, not production replicas. A bank, hospital, logistics company, or public-sector agency will have domain-specific risks that these benchmarks only partially cover.
Second, evaluator dependence remains a concern. The paper uses multiple evaluators, which is good practice, and it separately evaluates the RL model with non-reward evaluators. Still, safety scores are mediated by classifiers and judge models. A high DSR means “judged safe under this evaluation setup”, not “metaphysically safe”. Sadly, metaphysical safety remains unavailable in Python.
Third, ReSA assumes the system can reliably hide the safety-check block. That is an implementation requirement, not an academic footnote. If product code leaks hidden reasoning, logs it too broadly, or exposes it through debugging interfaces, the safety design can become a data exposure problem.
Fourth, multi-turn and agentic settings are not fully settled by the paper. The mechanism should transfer conceptually to tool-use planning, but the experiments focus on response generation. Tool actions introduce state, permissions, irreversible operations, and external side effects. The answer summary becomes an action summary; the audit must become stricter.
Finally, adversarial drift does not stop. Attackers adapt. ReSA’s mechanism is promising because it inspects a more revealing intermediate representation, but no fixed representation remains ungameable forever. The serious deployment strategy is ReSA plus monitoring, red-teaming, post-hoc filters, policy updates, and incident review. Annoying, yes. Also known as engineering.
The real lesson is not “more safety”; it is better sequencing
ReSA’s contribution is not that models should think more. AI safety has accumulated enough “let’s think carefully” prompts to wallpaper a small airport.
The contribution is sequencing.
Do not only ask whether the prompt is unsafe. Ask what the model is about to do. Do not only block final outputs. Shape the model’s decision before the final output exists. Do not treat refusal as the sole safe endpoint. Train the model to distinguish between unsafe compliance, safe refusal, and safe completion.
That is why Answer-Then-Check is business-relevant. It turns safety from a perimeter filter into an internal control loop. The model proposes its own next move, audits that move, and then acts. This is the same pattern mature organisations use for high-risk operations: plan, review, execute. ReSA compresses that pattern into the model’s generation process.
The paper does not prove universal jailbreak immunity. It does not eliminate the need for external safeguards. It does not mean hidden reasoning should be shown to users. It does show that auditing an intended answer can be a better safety signal than staring at an adversarial prompt and hoping the disguise falls off.
For enterprise AI, that is the useful takeaway. The future of safety is not simply stronger refusal. It is systems that understand what they are about to do before they do it.
A low bar, perhaps. But in software, as in management, many disasters begin with skipping exactly that step.
Notes
Cognaptus: Automate the Present, Incubate the Future.
-
Chentao Cao, Xiaojun Xu, Bo Han, and Hang Li, “Reasoned Safety Alignment: Ensuring Jailbreak Defense via Answer-Then-Check,” arXiv:2509.11629v2, March 6, 2026. arXiv:2509.11629. ↩︎