ResearchGuard Models

HaloGuard 2.0: An Output Guard That Reads the Answer as It Streams

A summary of the HaloGuard 2.0 paper: a small open streaming guard that comes out ahead of the current open streaming guards, the shortcut it had to unlearn, what the paper reports, and what it does not claim.

Astroware

  • Guard Models
  • Streaming Safety
  • Multilingual Safety

An input guard decides whether a request reaches the model. It never sees what the model says. Harm that appears during generation, because a jailbreak got past the input check or a harmless question drifted into operational detail, only shows up in the answer, and only as the words arrive.

This article summarises our paper, HaloGuard 2.0: An Open-Weights Constitutional Output Guard for Multilingual Response Safety, published on arXiv on 1 November 2026. HaloGuard 2.0 is a family of open guards with 0.8B parameters: an English output guard, a 17-language output guard, and a new input guard. It is a different model from HaloGuard EU, which is built to block output the EU AI Act bans or treats as high-risk. Everything below is what the paper and the model cards report.

01The answer is where the harm shows up

Most moderation runs after the reply is complete. That works for batch review, but not for chat, where the reply streams to the user word by word. By the time a guard that reads the finished reply returns its verdict, the user may already have read the harmful part. Holding the whole reply back until it is checked removes the reason to stream.

Streaming output guards solve this by scoring the reply as it is generated. They are not new. Anthropic's Constitutional Classifiers include a streaming output classifier that scores each token and stops generation; its weights are not public. Qwen3Guard-Stream, at 0.6B, 4B and 8B, puts token-level heads on an open model.

HaloGuard 2.0 is closest in shape to Qwen3Guard-Stream. Like it, HaloGuard 2.0 gives a safe or unsafe probability for every token of the reply, in a single pass, as it is generated, and the application can stop the stream once harm is confirmed. What the paper adds is a guard that comes out ahead of every Qwen3Guard-Stream size at 0.8B, and the shortcut described in section 03.

A prompt goes from the user through the input guard, HaloGuard2-Gen-0.8B, to the LLM or agent. The reply streams back token by token through the output guard, HaloGuard 2.0, which checks each token; the stream to the user is cut. Below, an illustrated reply: each word has a risk bar, and the stream is cut at the word whose bar crosses the cut line.
Fig. 1An input guard checks the request and never sees the reply. HaloGuard 2.0 checks the reply as it streams, token by token, so your app can cut it mid-stream.

02Two boundaries: what, and when

A streaming guard has to draw two lines. The first is the content line, the same one an input guard draws: a reply that helps someone cause harm is unsafe; a reply that discusses a hard topic is not. A security engineer asking how a class of exploit works, a nurse asking about overdose thresholds and a historian asking about chemical attacks in the First World War all deserve a capable answer.

The second line is specific to streaming: the point in the reply where there is enough evidence to step in. A prefix such as "To synthesise this compound, you would first need" may become a refusal, a textbook overview or a procedure. Fire too early and the guard interrupts legitimate answers. Wait too long and the harmful part has been shown.

The prompt and the response tokens go into a safety-tuned model backbone with a per-token classification head, which gives P(unsafe) for each response token in a 2,048-token window. A chart, for the English model HaloGuard2-Stream-0.8B, shows illustrated scores rising until two tokens in a row pass 0.70 and the guard fires at token 8 and stays fired; the 17-language model fires on three tokens in a row at 0.675 or above. The output is unsafe at token 8, or safe; the app can cut the stream, replace the reply, refuse, log or escalate. A timing row shows the guard scoring token t while the model writes token t+1: 0.37 ms per token per stream on one H100, with 64 replies at once.
Fig. 2The English streaming guard reads the prompt once as context and scores only the reply, one token at a time. It fires if any token reaches P(unsafe) 0.975, or two in a row reach 0.70, and stays fired. Your app decides what happens next.

HaloGuard 2.0 reuses the constitution of HaloGuard 1.0, so the input and output verdicts for one conversation refer to the same policies. It also treats "refuse, then comply" as unsafe: a reply that opens with "I can't help with that" and then helps anyway.

03The shortcut: judging the question instead of the answer

The paper reports a shortcut specific to streaming. In typical response datasets nearly every harmful reply is harmful from its first token. A guard can therefore score well by judging the prompt and never reading the answer.

The paper tests for this with matched pairs: one prompt with a safe and an unsafe reply, where only the reply tells them apart. A guard trained on conventionally shaped data handled only 13.9% of these pairs correctly. A corrective second phase built around those failures fixed it, and the released model is the equal-weight average of the base and corrective models.

0417 languages

The multilingual model, HaloGuard 2.0-Poly-0.8B, released on Hugging Face as HaloGuard2-MultiStream-0.8B, is trained on PolyGuardMix and covers 17 languages: English, Spanish, French, German, Italian, Portuguese, Dutch, Swedish, Polish, Czech, Russian, Arabic, Chinese, Japanese, Korean, Thai and Hindi.

The European and CJK groups and Arabic stay within 4.4 points of English. Thai (73.9) and Hindi (64.2) are the weakest. For Hindi the guard misses more than one harmful reply in five.

05What the paper reports

On six English response-safety benchmarks (HarmBench, SafeRLHF, BeaverTails, XSTest-Response, Aegis 2.0 and WildGuardTest), the English model reaches a macro F1 of 83.6 under one global decision rule, and 83.3 on held-out halves of the decision-rule search. That is up from 72.8 for the base guard, with 38% fewer false positives.

That makes it a new state of the art (SOTA) for open output guards in the paper's comparison:

  • It is 2.6 points above the strongest streaming guard, Qwen3Guard-Stream-4B (81.0), and 4.8 above the one closest in size, Qwen3Guard-Stream-0.6B (78.8).
  • It has the highest average of any model compared, 83.63, just ahead of Qwen3Guard-Gen-4B and -8B (83.57), which read the whole reply before deciding and have 5-10x more parameters. The paper notes the margin over those two is small; the size gap is not.
  • It is the best model on HarmBench (96.4) and on SafeRLHF (81.7, 11.2 points above the next model).

The multilingual model reaches 83.1 F1 on the response labels of PolyGuardPrompts, averaged over 17 languages. That is 5.0 points above the strongest baseline, Qwen3Guard-Gen-4B (78.1), and 7.3 above the strongest streaming guard, Qwen3Guard-Stream-8B (75.8).

On one H100, the guard costs 0.37 ms per token per stream when moderating 64 replies at once. Because it scores one token while the generator produces the next, it adds delay only when its step is slower than the generator's.

Together with HaloGuard 1.0's 0.8B input guard, the paper reports a complete moderation stack of 1.6B parameters.

06What it does not do

Every harmful reply that is caught has already shown the tokens between the point it turned harmful and the point the guard fired. The paper suggests that deployments that cannot tolerate any leak on the most severe policies hold back a short buffer of output before display.

The guard gives a signal; the application decides what to do with it: cut the stream, replace the partial reply, fall back to a refusal, log it or escalate it. The output guards return safe or unsafe and where it fired, not a policy category. They were trained on inputs of up to 2,048 tokens.

The English model misses more than it over-flags, most of all on WildGuardTest. The multilingual model over-flags more than it misses, and its rule needs three tokens, so it cannot flag a one- or two-token reply. Every training record is in a single language, so mixed-language replies are only partly covered.

The model card calls the guard one layer in a defence in depth, next to input guarding, tool permissions, logging and human escalation.

07Red-teaming both layers

HaloGuard 1.0 is hardened by red-teaming in rolling seven-day cycles: four days of attacks on a guarded agent that can use tools, then three days of curating the successful attacks and retraining. The paper extends the same protocol to the output layer. Attackers now face both guards at once, and each successful attack is attributed to the layer that should have stopped it.

Three attack types aimed at the output layer are tracked separately: a long harmless lead-in before the harmful part, a refusal followed by compliance, and harmful content moved into an encoding, a code block or another language.

The paper describes the protocol but does not report results from its cycles.

08The new input guard

The collection also holds a new input guard, HaloGuard2-Gen-0.8B. Its model card reports that it is trained on inputs of up to 8,192 tokens, with prompt injection and jailbreak detection grown multi-fold over HaloGuard 1.0, and 90.9 average F1 across seven prompt-safety benchmarks.

09Read the paper

HaloGuard 2.0: An Open-Weights Constitutional Output Guard for Multilingual Response Safety, arXiv, 1 November 2026.

All three HaloGuard 2.0 models are released as open weights on Hugging Face, under the Apache 2.0 licence.

Earlier: HaloGuard 1.0: Building an Input Guard Around the Boundary, Not the Keyword.

Sharma et al., Constitutional classifiers: defending against universal jailbreaks across thousands of hours of red teaming, 2025.