1 Introduction↩︎

Large Language Models (LLMs) have achieved unprecedented capabilities across diverse natural language processing tasks [1]–[4], but their safe deployment has become an increasingly urgent concern [5]–[8]. To mitigate potential risks, safety guardrails have been proposed as lightweight external defenses that monitor and filter model inputs and outputs [9]–[11]. Yet, as LLMs are deployed in increasingly complex real-world applications [12], new safety risks continue to emerge, ranging from unauthorized actions by LLM agents [13] to dangerous advice from consumer-facing chatbots [14]. It is imperative to build guardrails that are robust across an ever-expanding spectrum of safety threats.

Building a robust and generalizable guardrail remains challenging. Safety violations are inherently diverse, ranging from explicit malicious intents [15], [16] to context-dependent harms [17], [18] that require domain-specific judgment. Different risks often demand different decision boundaries. An agent deleting emails without user permission, for example, is unsafe under agent-safety rules, yet may not fit conventional content- or cyber-safety definitions. Compressing such heterogeneous criteria into one guardrail model can blur domain-specific boundaries and induce task interference. This challenge is further amplified by the evolving safety landscape, where guardrails that perform well on existing risks may fail once new deployment scenarios introduce novel constraints, policies, or action spaces [19]. Meanwhile, the absence of a unified, human-annotated benchmark limits comprehensive evaluation of genuinely robust guardrails. Existing datasets typically cover narrow subsets of violations, such as toxicity or bias in isolation [20]–[22]. Moreover, many current evaluation pipelines rely on synthetic data [17], [23] or LLM-as-a-judge approaches [24]. Since different LLMs follow distinct safety alignment rules, their judgments on borderline cases can be inconsistent and may fail to reflect reliable human consensus.

To better understand the robustness of guardrails, the first contribution of this paper is GuardZoo, a unified, human-annotated benchmark for evaluating guardrails across heterogeneous safety risks. We build GuardZoo by curating samples from nine high-quality guardrail datasets, harmonizing their labels under a unified safety taxonomy, and re-annotating them through human adjudication. The resulting benchmark contains 32,460 conversational samples covering 15 distinct unsafe categories, spanning general safety risks such as hate speech and self-harm, as well as specialized risks such as cyberattacks and agent-policy violations. Beyond its scale and coverage, GuardZoo is designed to stress-test guardrails under realistic and heterogeneous safety conditions. Its samples span diverse interaction formats, from malicious prompts, single and multi-turn conversations to agent trajectories. Rather than requiring only binary safe/unsafe decisions, GuardZoo asks models to identify the specific violation categories involved in each unsafe case. This fine-grained setting is further complicated by the fact that 35.17% of unsafe examples involve multiple violation categories, reflecting the overlapping and compound nature of real-world safety risks. As a result, GuardZoo provides a rigorous foundation for evaluating whether modern guardrails can remain robust across a broad spectrum of safety risks.

Addressing the heterogeneous risks captured by GuardZoo with a single guardrail model is inherently difficult. This motivates the second contribution of this paper: RouteGuard, a dynamic router-expert framework for scalable guardrail detection, as illustrated in 1. Instead of relying on one overburdened model to detect all violations, RouteGuard first uses a router to identify the relevant threat domains for the input, and then dispatches the input to specialized expert guardrails. This decomposition allows each expert to focus on a more coherent subset of safety risks, reducing task interference and enabling more precise domain-specific decision boundaries. Beyond improving detection performance, the modular design of RouteGuard also supports extensibility: when new safety threats emerge, practitioners can incorporate additional experts through localized router updates, without retraining the entire guardrail system. Extensive experiments show that RouteGuard consistently outperforms monolithic guardrail baselines across diverse safety categories, while also demonstrating strong adaptability to newly introduced threat domains.

2 GuardZoo: A Unified Safety Benchmark↩︎

We introduce GuardZoo, a unified safety benchmark for fine-grained guardrail evaluation. We first align heterogeneous sources under a shared 15-category taxonomy in 2.1, then present our two-phase relabeling pipeline in 2.2. 2 provides an overview of the construction pipeline and the resulting label distribution.

2.1 Taxonomy Consolidation↩︎

Existing safety datasets use fragmented taxonomies: similar violations appear under different names, while some datasets only provide binary safety labels [23], [25]. We therefore aggregate representative subsets from nine safety datasets, covering both general safety moderation and agent-specific risks. 1 summarizes the source composition of GuardZoo.

To build a shared taxonomy, we align overlapping categories and remove redundancy. For example, we merge WildGuardMix’s violence_and_physical_harm [26] with BeaverTails’ violence, aiding_and_abetting [17], yielding 19 intermediate categories. We further merge frequently co-occurring categories, such as hate_speech and discrimination, resulting in 15 core unsafe categories listed in 7.1.

2.2 Two-Phase Relabeling Pipeline↩︎

Directly mapping source labels to the unified taxonomy introduces mismatch and noise. To ensure data quality, we implement a rigorous two-phase annotation pipeline to relabel the entire corpus.

2.2.0.1 Phase 1: Multi-LLM Ensemble Voting.

We use three proprietary LLMs from distinct model families as annotators: Gemini 3 Flash [29], GPT-5 Mini [30], and Claude 4.5 Haiku [31]. This diverse ensemble mitigates provider-specific alignment biases. Each model independently assigns a binary safety label and, if unsafe, the violated categories from our 15-domain taxonomy. We accept a label only when all three models agree on both dimensions, resolving 20,133 samples.

2.2.0.2 Phase 2: Expert Human Adjudication.

For the remaining 12,327 disputed samples, we rely on human adjudication. Annotators are presented with the disputed conversations, alongside strict taxonomic definitions and canonical examples derived from the original datasets. They act as expert judges to reconcile discrepancies and assign the final gold-standard labels. Additional annotation details and multi-category examples are provided in [sec:human_annotation,app:multi_category_examples].

3 RouteGuard↩︎

We now present RouteGuard, a router-expert guardrail framework for fine-grained safety detection. Given a conversation \(x\), a guardrail system first determines whether it is safe or unsafe; if unsafe, it further predicts a set of violated threat categories \(V \subseteq \mathcal{T}\) under a predefined taxonomy \(\mathcal{T}\). RouteGuard decomposes this process by using a safety-aware router to dispatch each input to one or more specialized expert guardrails, whose outputs are aggregated into the final category prediction. We describe the expert construction and routing mechanism in 3.1, followed by modular expansion to emerging threats in 3.2.

3.1 Building RouteGuard↩︎

Monolithic guardrails [32], [33] typically optimize a single mapping function \(f_\theta: x \rightarrow \{0, 1\} \times \mathcal{P}(\mathcal{T})\) over the taxonomy power set. Forcing a shared parameter space \(\theta\) to navigate conflicting decision boundaries inevitably causes task interference. To resolve this bottleneck, RouteGuard introduces a dynamic dispatch mechanism. The framework consists of a Router and an ensemble of specialized Experts. For any incoming conversation, the router triages the input to the relevant expert(s). The activated experts then evaluate the text independently, and their discrete outputs are aggregated to form the final system prediction.

3.1.0.1 Building Expert Guardrails.

The core motivation of this decoupled design is to minimize task interference by shrinking the output space for individual expert guardrails. Analogous to a medical triage system directing patients to specialized departments, each expert is dedicated to managing a single domain. To achieve this, we partition the full taxonomy \(\mathcal{T}\) into \(M\) semantically cohesive domains \(\{\mathcal{D}_1, \dots, \mathcal{D}_M\}\) by grouping highly correlated categories (e.g., animal abuse and child abuse). Each expert \(E_i\) thus acts as a dedicated authority over its respective domain, tasked exclusively with identifying violations within its purview: \(E_i(x) \subseteq \mathcal{D}_i\).

Each expert \(E_i\) is trained to map the conversation \(x\) to a target token sequence \(\mathbf{o}_i\). To enforce sharp domain boundaries and mitigate over-triggering, \(\mathbf{o}_i\) defaults to a special none token whenever there are no in-domain violations, and lists the precise categories within its purview otherwise: \[\mathbf{o}_i = \begin{cases} \text{\texttt{none}}, & \text{if } V^* \cap \mathcal{D}_i = \emptyset, \\ V^* \cap \mathcal{D}_i, & \text{otherwise.} \end{cases}\] where \(V^* \subseteq \mathcal{T}\) is the ground-truth violation set. We optimize \(E_i\) using a standard token-level cross-entropy loss: \[\mathcal{L}_{\text{expert}}^{(i)} = - \sum_{k=1}^{|\mathbf{o}_i|} \log P_{\theta_i}(o_{i,k} \mid x, o_{i,<k})\] where \(o_{i,k}\) represents the \(k\)-th token of \(\mathbf{o}_i\).

3.1.0.2 Building the Router.

The router serves as a safety-aware triage module that decides whether an input requires expert inspection and, if so, which expert domains should be activated. Unlike conventional model routing, where every query is typically assigned to a candidate model, our setting allows clearly benign inputs to bypass the expert pool through a null route.

Formally, given expert domains \(\mathcal{D}=\{D_1,\ldots,D_M\}\) and an input conversation \(x\), the router predicts a routing set \[R(x) \subseteq \{1,\ldots,M\}.\] For a training instance with ground-truth violation set \(V^* \subseteq T\), the target routing set is \[R^*(x)=\{i \mid V^* \cap D_i \neq \emptyset\}.\] When \(V^*=\emptyset\), we set \(R^*(x)=\emptyset\), corresponding to the null route.

In practice, we instantiate the router as a generative domain-set predictor that outputs textual expert sets, such as {agent, cyber} for multi-domain violations and {} for the null route. During inference, the activated expert set is \(\mathcal{A}(x)=\{E_i \mid i \in R(x)\}\), and the final prediction is obtained by union aggregation: \[V(x)=\bigcup_{E_i \in \mathcal{A}(x)} E_i(x).\] If the router predicts the null route, or if all activated experts return \(\emptyset\), the system outputs safe.

3.2 Extensibility to Novel Threats↩︎

As the safety landscape continuously evolves, monolithic guardrails struggle to rapidly adapt to novel risks [34], [35]. Incorporating these emerging threats via full retraining incurs prohibitive computational costs and requires re-validating all previously verified decision boundaries. Conversely, updating the shared parameter space through continual learning notoriously triggers catastrophic forgetting, where optimizing for \(t_{\text{new}}\) inadvertently degrades the detection accuracy of existing categories [36], [37].

To circumvent these limitations, RouteGuard leverages its architecture for plug-and-play extensibility. When a new threat \(t_{\text{new}}\) emerges, developers simply train a dedicated expert \(E_{\text{new}}\), leaving all existing experts frozen. System integration requires updating only the router to dispatch relevant inputs to \(E_{\text{new}}\). Ultimately, RouteGuard guarantees scalable defense without the monumental overhead of monolithic re-optimization.

4 Experiments and Results↩︎

In this section, we describe the experimental setup in 4.1, compare RouteGuard against monolithic and router baselines under in-domain and out-of-domain settings on GuardZoo in 4.2, and further study modular threat expansion, router design, and expert specialization in [subsec:continual_learning,subsec:router_ablation,subsec:expert_choice].

4.1 Experimental Setup↩︎

4.1.0.1 Dataset Splits.

We split GuardZoo by data source to evaluate both in-domain performance and out-of-domain (OOD) generalization. Specifically, we hold out all Toxic-Chat [23] and OpenAI-Moderation [10] samples as the OOD test set, and use the remaining sources as the in-domain pool. The in-domain pool is split into 80% training and 20% test data; the training portion is used for RouteGuard and all trainable baselines.

4.1.0.2 Router and Expert Configuration.

RouteGuard uses five specialized safety experts over semantically grouped domains: Agent Safety, Cybersecurity, Physical Harm, Non-Violent Misconduct, and Social Risks. Each expert is obtained by fine-tuning Qwen3Guard-0.6B [38] on its corresponding domain partition, with sub-category mappings and fine-tuning details provided in 8.1.

The router serves as a triage layer that maps each input to a target expert-domain set, with a null route for safe inputs. We fine-tune Qwen3Guard [38] routers at three scales (0.6B, 4B, and 8B), yielding RouteGuard-0.6B, RouteGuard-4B, and RouteGuard-8B; implementation details are provided in 8.2.

4.1.0.3 Baseline Implementations.

We compare RouteGuard against zero-shot guardrails, fully fine-tuned guardrails, and traditional classification routers adapted to dispatch inputs to our experts. The guardrail baselines cover Qwen3Guard [38], LlamaGuard [4], [32], and ShieldGemma [39] across multiple scales, while the router baselines include k-NN Router [40], MLP Router [41], RouterDC [42], and GraphRouter [43]. Detailed model variants and implementation settings are provided in [app:traditional95router].

4.1.0.4 Evaluation Metrics.

We evaluate both coarse binary safety detection and fine-grained multi-label threat categorization. For binary detection, we report Safe/Unsafe Accuracy and Unsafe \(F_1\); for category detection, we report Macro Category \(F_1\) and Micro Category \(F_1\) on unsafe samples. Detailed metric definitions are provided in 8.4.

4.2 Robust Safety Detection with RouteGuard↩︎

4.2.0.1 In-Domain Evaluation.

2 shows that RouteGuard-4B and RouteGuard-8B achieve the best fine-grained category performance. Compared with the strongest fully fine-tuned monolithic baselines, the gains are modest but consistent on Macro and Micro \(F_1\), suggesting that decomposing safety detection into domain-specific experts can better support fine-grained threat categorization. Monolithic fine-tuning guardrails remain a strong baseline, especially for coarse safe/unsafe detection, indicating that RouteGuard’s main advantage lies in category-level specialization rather than simply improving binary safety classification.

Zero-shot guardrail baselines perform substantially worse on category-level metrics, reflecting the difficulty of directly adapting existing guardrails to a customized, unified safety taxonomy without task-specific training. Traditional router baselines also lag behind the generative router, despite using the same expert pool. This suggests that routing itself is a non-trivial component of the problem, particularly for multi-category inputs that may involve overlapping safety policies. Overall, these results indicate that RouteGuard provides a more effective routing-and-specialization strategy for fine-grained safety detection.

4.2.0.2 Out-of-Domain Evaluation.

To evaluate generalization under distribution shifts, we select a representative subset of baselines that perform strongly in-domain. As shown in 3, all systems experience performance degradation, especially on Macro and Micro \(F_1\), confirming that the held-out sources present a challenging out-of-domain evaluation setting. Nevertheless, RouteGuard-4B and RouteGuard-8B achieve the strongest overall results across the evaluated metrics, with particularly clear gains on fine-grained category prediction. This suggests that separating routing from domain-specific expert judgment can improve robustness to unseen source distributions.

4.3 Modular Expansion to Emerging Threats↩︎

As safety threats evolve, guardrails should be able to incorporate new hazards without fully retraining the entire system. This setting is challenging for monolithic guardrails: retraining on the full expanded dataset can be costly, while sequentially fine-tuning on newly introduced threats may degrade performance on previously learned domains. We examine whether RouteGuard provides a more localized path for system expansion.

We simulate sequential threat emergence across five domains: Agent, Harm, Social, Cyber, and Non-violent violations. For monolithic baselines, we sequentially fine-tune Qwen3Guard models at 0.6B, 4B, and 8B scales as new domains are introduced. For RouteGuard, each newly introduced domain is handled by training a dedicated Qwen3Guard-0.6B expert, while previously trained experts remain frozen. To integrate the expanded expert pool, we update the router using a 20% subset drawn from all available domains.

As shown in 3, sequentially fine-tuned monolithic baselines suffer from degraded fine-grained category performance after domain updates, especially in Macro and Micro \(F_1\). In contrast, RouteGuard better preserves overall safety detection performance because most domain-specific parameters are isolated in frozen experts, and only the router and newly added expert require updates. These results highlight a practical advantage of the router-expert design: emerging safety domains can be incorporated through localized expert expansion and lightweight router recalibration, avoiding full-system retraining.

4.4 Ablation Study on Router Design↩︎

To examine the effect of domain specialization, we compare RouteGuard with a dense Mixture-of-Experts (MoE) routing baseline [41], [44], [45]. Unlike RouteGuard, whose experts are trained on disjoint safety domains, the MoE baseline uses five all-category Qwen3Guard-0.6B experts fine-tuned with different random seeds. For each top-\(k\) setting, we derive router labels by enumerating all \(\binom{5}{k}\) expert subsets and selecting the subset whose aggregated predictions best match the ground truth. We train MoE routers with both Qwen3Guard-0.6B and Qwen3Guard-4B backbones.

As shown in 4, dense MoE routing is competitive with a 0.6B router, where MoE top-2 slightly outperforms RouteGuard on Macro \(F_1\). However, with a 4B router, RouteGuard achieves the best category-level performance, reaching 70.24 Macro \(F_1\) and 71.88 Micro \(F_1\). In contrast, MoE variants gain little from the larger router, suggesting that routing among dense, overlapping experts provides limited benefit. These results indicate that RouteGuard benefits from explicit domain-specialized experts, where improved routing capacity more directly translates into better fine-grained safety detection.

3pt

4.5 Expert Specialization and Scale↩︎

We further analyze whether our experts truly specialize in their assigned domains and whether such specialization requires larger backbones. As shown in 4, specialized experts generally outperform monolithic baselines of the same scale on their corresponding domains. The gain is especially large for agent safety, cybersecurity, and harm-related domains, where the 0.6B expert substantially improves over the 0.6B baseline. These results suggest that experts learn domain-specific decision boundaries rather than acting as smaller copies of monolithic guardrails. Meanwhile, scaling experts beyond 0.6B brings limited additional gains: larger experts do not consistently improve performance on agent safety or cybersecurity, and the average improvement from 0.6B to 4B/8B remains small. This finding is important for RouteGuard, as it shows that effective plug-and-play specialization can be achieved with small experts, preserving the efficiency of the overall routing framework.

5 Related Work↩︎

5.0.0.1 Guardrail.

Guardrails have become a practical defense layer for LLM and agent systems, serving as external input-output or trajectory-level monitors without modifying the protected model [32], [33], [38], [46]. Early guardrails mainly address broad safety risks, including harmful prompts, jailbreaks, and unsafe generations, under general safety policies [15], [47], [48]. However, recent evidence shows that such guardrails often fail in specialized settings: domain-specific risks may look benign, and agent compliance failures may require multi-step, policy-aware reasoning [49]–[51]. This motivates a shift from monolithic safety moderation to task- and domain-specialized guardrails, as recent benchmarks reveal distinct risks across scientific [52], [53], application-specific [54], and policy-compliance settings [19]. In this work, we take a complementary step: instead of assuming one guardrail fits all safety tasks, we study how to route each input to the most suitable guardrail under a unified safety benchmark, composing heterogeneous guardrails into a flexible, task-aware safety system.

5.0.0.2 Model Routing.

Model routing addresses a related but distinct problem: given a fixed pool of candidate models and an incoming query, decide which model should serve it [55]–[60]. These methods typically operate in the general-purpose serving setting, where the candidate models can all answer the same query but differ in capability, latency, or cost, and routing decisions optimize quality–efficiency trade-offs. A separate line of work instead focuses on constructing the candidate pool itself from a large, heterogeneous model space [61]. Our work repurposes the routing paradigm for a different objective: rather than arbitrating among general-purpose models, RouteGuard routes among specialized safety experts, each optimized for a disjoint threat category. In our setting, the router does not choose between models for cost or speed; it sends each input to the expert that handles its threat type. This reduces the task interference seen in single-model guardrails and makes the system easy to extend with new experts.

6 Conclusion↩︎

We introduced RouteGuard, a router-expert framework for fine-grained LLM safety guardrails, together with GuardZoo, a human-annotated benchmark built from nine safety datasets under a unified 15-category taxonomy. Across in-domain and out-of-domain evaluations, RouteGuard improves category-level threat detection over strong monolithic and routing baselines, with particularly clear gains under distribution shift. We further show that its modular design supports localized expansion to emerging threat domains by adding new experts and recalibrating the router, avoiding full-system retraining. Overall, our findings highlight threat-domain specialization as a practical direction for more scalable and adaptable safety guardrails.

Limitations↩︎

While RouteGuard demonstrates the promise of router-expert guardrails, it has several limitations. First, RouteGuard presents one practical instantiation of the router-expert paradigm, but does not claim to identify the optimal way to partition safety domains or train routers. Alternative expert groupings, hierarchical routing strategies, or joint router-expert optimization may further improve performance. Second, our out-of-domain evaluation focuses on held-out data sources, which captures source-level distribution shift but does not cover all real-world deployment shifts, such as new languages, modalities, or rapidly emerging threat types. Future work can extend GuardZoo and RouteGuard to broader distribution shifts and more diverse safety scenarios. Finally, our modular expansion experiment assumes access to a small global calibration subset for router updates. It should therefore be viewed as a practical adaptation setting rather than a rehearsal-free continual learning benchmark. Developing router-expert guardrails that can incorporate new threats with even less historical data remains an important direction for future work.

Ethical Considerations↩︎

This work is intended to improve the reliability of LLM safety guardrails. GuardZoo is constructed from existing safety and alignment datasets and further curated through a two-phase relabeling process with human adjudication. Because safety data may contain harmful, sensitive, or offensive content, all annotations are conducted with appropriate guidelines, access control, and annotator well-being considerations. RouteGuard is designed as a defensive framework for detecting and categorizing unsafe interactions. The paper reports aggregate benchmark results and taxonomy-level analyses, and does not require releasing operational jailbreak strategies or instructions for harmful activities. At the same time, guardrail models can produce false positives or false negatives, especially on ambiguous or context-dependent inputs. Therefore, RouteGuard should be used as part of a broader safety pipeline rather than as a complete replacement for human oversight in high-stakes applications. Figure 1 was created with assistance from a generative AI tool and was manually edited by the authors for clarity and accuracy.

7 GuardZoo Dataset Appendix↩︎

7.1 Final Core Taxonomy↩︎

Table 5 presents the complete list of the 15 consolidated core safety domains deployed in our router-expert framework.

7.2 Final Dataset Statistics and Examples↩︎

Following the rigorous two-phase annotation pipeline, the final GuardZoo benchmark comprises 32,460 fully curated conversational samples. The dataset exhibits a balanced distribution between safe and unsafe interactions, containing 16,037 safe samples and 16,423 unsafe samples.

A key characteristic of GuardZoo is its inclusion of complex, real-world conversational threats. Among the 16,423 unsafe instances, 10,647 (64.83%) are classified into a single primary violation domain. The remaining 5,776 samples (35.17%) involve multi-category violations, spanning two or more safety categories simultaneously.

Table 6 details the exact distribution of the 10,647 single-category unsafe samples across our 15 core taxonomic domains.

To illustrate why GuardZoo requires multi-label annotation, we provide two representative examples in [fig:multi_category_example_agent,fig:multi_category_example_story]. Each sample contains multiple overlapping safety risks and therefore cannot be faithfully represented by a single unsafe category.

7.3 Data Annotation Pipeline↩︎

To ensure industrial-grade annotation standards, top-tier data quality, and taxonomic consistency, we established a rigorous and ethically compliant human curation framework in collaboration with a well-known, industry-leading data service company. The annotation was executed by a professional curation team with a stable core of 20–30 long-term annotators, carefully selected from geographically diverse regions to ensure culturally nuanced and balanced safety judgments. The team maintained high educational credentials, with over 80% of the annotators holding a Bachelor’s degree or higher. Prior to entering production, all candidates underwent extensive taxonomy training, completed trial annotations, and passed a strict qualifying exam. Furthermore, we prioritized the welfare and ethical compensation of our annotators, strictly complying with local labor regulations and providing compensation and welfare benefits well above the regional average market rates.

Our commitment to rigorous quality control directly translated into high data fidelity through a strict multi-stage auditing process. During the initialization phase, an initial pilot batch of 200 conversations was directly reviewed by the authors; any batch or individual annotator exhibiting high error rates was immediately rejected and sent back for comprehensive revision and calibration. Once production stabilized, we implemented a continuous daily auditing protocol, randomly sampling and inspecting newly submitted data to ensure long-term consistency and prevent drift. This exhaustive quality-assurance loop guarantees that the human gold-standard labels in GuardZoo serve as a highly reliable benchmark for fine-grained safety evaluation.

8 Experimental Details↩︎

8.1 Detailed Expert Configurations↩︎

The five specialized RouteGuard experts process disjoint subsets of the 15 consolidated core taxonomies as follows:

• Agent Expert: Agent Safety.

• Cyber Expert: Cyberattack, Copyright Violations, Sensitive Information (Organizations & Government).

• Harm Expert: Physical Harm, Weapons, & Drugs, Self-Harm, Mental Health Crisis, Animal Abuse, Child Abuse.

• Non-Violent Expert: Non-Violent Unethical Behavior.

• Social Expert: Hate Speech, Discrimination, & Harassment, Controversial Topics & Politics, Misinformation on Ethics, Laws, & Safety, Sexually Explicit & Adult Content.

During fine-tuning, we enforce three distinct behavioral objectives for each targeted domain expert. First, if the input contains unsafe categories falling within its designated domain, the model must output the precise union of the relevant violation labels. Second, if the input contains violations belonging exclusively to other expert domains, the model must return an empty set \(\emptyset\). Third, when encountering clean and safe inputs, the model must also return an empty set \(\emptyset\).

8.2 Detailed Router Implementation↩︎

At the routing level, safe inputs require special treatment. Unlike standard model routing, where every query is assigned to at least one candidate model, safety routing allows the system to abstain from expert activation when no violation is detected. We therefore introduce a dedicated null-route target for clean inputs. This design improves stability by explicitly teaching the router to distinguish between inputs that require expert inspection and inputs that should bypass the expert pool.

For generative LLM routers, we fine-tune Qwen3Guard models to directly output textual domain sets. For example, the router may generate {agent, cyber} for a multi-domain threat. For clean inputs, the router generates the empty set {}, which is the textual realization of the null route. Thus, both discriminative and generative routers implement the same routing semantics: unsafe inputs are dispatched to one or more expert domains, whereas safe inputs are assigned to the null route and bypass expert activation.

For discriminative router baselines, we train models to output a 6-dimensional indicator vector: \[(c_{\text{agent}}, c_{\text{cyber}}, c_{\text{harm}}, c_{\text{non\_violent}}, c_{\text{social}}, c_{\text{null}}).\] The first five dimensions correspond to expert domains, while \(c_{\text{null}}\) denotes the null route for safe inputs. During training, clean safe samples are mapped to \((0,0,0,0,0,1)\). Unsafe samples activate the corresponding expert-domain slots according to their ground-truth violation categories, while setting \(c_{\text{null}}=0\).

8.3 Baseline Details↩︎

For the zero-shot and fine-tuned guardrail baselines, we evaluate Qwen3Guard (0.6B, 4B, 8B) [38], LlamaGuard2 (8B) [32], LlamaGuard3 (1B, 8B) [4], and ShieldGemma (2B, 9B, 27B) [39]. Due to hardware constraints, ShieldGemma-27B is evaluated only in the zero-shot setting. For router baselines, we adapt k-NN Router [40], MLP Router [41], RouterDC [42], and GraphRouter [43] to predict safety-domain indicator vectors.

8.3.0.1 k-NN Router.

Following RouterBench [40], we embed each training conversation and perform nearest-neighbor retrieval at inference time. The routing vector is obtained by aggregating the domain indicators of the nearest training examples.

8.3.0.2 MLP Router.

Following RouteLLM [41], we train a lightweight MLP classifier on frozen conversation embeddings. The MLP outputs the 6-dimensional routing vector and is optimized with binary cross-entropy.

8.3.0.3 RouterDC.

Following RouterDC [42], we train a query encoder with dual contrastive objectives to align conversations with their suitable routing targets. We adapt the original model-selection objective by treating safety domains as candidate routes rather than candidate LLMs.

8.3.0.4 GraphRouter.

Following GraphRouter [43], we construct a heterogeneous graph over conversations and expert-domain nodes. Routing is formulated as predicting edges between an input conversation and its relevant domain nodes, with the null-route node used for safe inputs.

8.4 Details on Evaluation Metrics↩︎

• Safe/Unsafe Accuracy and Unsafe \(F_1\): Binary metrics for distinguishing safe from unsafe inputs.

• Macro Category \(F_1\): The unweighted average of per-category \(F_1\) over ground-truth unsafe samples, emphasizing balanced performance across threat domains.

• Micro Category \(F_1\): The pooled category-level \(F_1\) over the same unsafe subset, measuring overall multi-label prediction quality².

To isolate fine-grained multi-label category detection capability from simple coarse binary classification, both Macro Category \(F_1\) and Micro Category \(F_1\) are calculated exclusively on samples where the ground-truth label contains at least one unsafe category.

8.4.0.1 Macro Category \(F_1\).

Let \(N\) be the total number of unsafe core categories (\(N=15\)). For each category \(i \in \{1, \dots, N\}\), we treat its prediction as an independent binary classification task to compute its category-specific \(F_{1}^{(i)}\) score. The overall Macro Category \(F_1\) is the unweighted average: \[\text{Macro Category } F_1 = \frac{1}{N} \sum_{i=1}^{N} F_{1}^{(i)}\] As shown in the formula, every domain contributes equally to the final score regardless of its support size, making it a reliable proxy for tracking performance on rare, critical threats.

8.4.0.2 Micro Category \(F_1\).

This metric flattens the multi-label matrix across all unsafe samples and categories. We globally aggregate the evaluation outcomes by defining the total counts of true positives (\(\mathbf{TP}\)), false positives (\(\mathbf{FP}\)), and false negatives (\(\mathbf{FN}\)) across all \(N\) categories as follows: \[\begin{cases} \mathbf{TP} = \displaystyle\sum_{i=1}^{N} \text{TP}_i \\[1.5ex] \mathbf{FP} = \displaystyle\sum_{i=1}^{N} \text{FP}_i \\[1.5ex] \mathbf{FN} = \displaystyle\sum_{i=1}^{N} \text{FN}_i \end{cases}\] The global Micro \(F_1\) score is then computed via the joint formulation: \[\text{Micro } F_1 = \frac{2\mathbf{TP}}{2\mathbf{TP} + \mathbf{FP} + \mathbf{FN}}\] Consequently, this metric reflects the overall label accuracy across dense data streams.

References↩︎