Safety Pretraining: Toward the Next Generation of Safe AI

Thanks for your excellent review and strong "Accept" recommendation! We're grateful for your recognition that our work "contributes an important new idea" with "experimental evidence" and rates "excellent" in originality and clarity.

Summary of Concerns and Responses

1. Adversarial Evaluation Robustness

"Probably the most critical piece missing from the paper is a set of strong, adaptive red teaming evaluations under stricter safety standards."

While we agree stronger adversarial evaluation (via human red teamers) would be valuable, our current evaluation actually includes several adversarial components that demonstrate robustness:

Existing Adversarial Tests:

• GCG attacks: 39.0% ASR vs 57.0% baseline (learned adversarial suffixes)
• Benign finetuning attacks: 8.3% ASR vs 38.0% baseline (deployment-time degradation)
• Cross-benchmark generalization: Consistent improvements across HarmBench, TDC, JailbreakBench, AdvBench
• Out-of-distribution prompts: Safety holds on evaluation data not seen during training

To strengthen these further, we add in new results using PAIR[1] as another automated red-teaming strategy. We observe that our safety pretraining strategy reduces the sucess rate of this additional attack strategy on JailbreakBench:

These results suggest our approach exhibits robustness to a variety of different adaptive attacks, and we acknowledge that human red-teaming studies would strengthen this claim.

Action 1.1: We will better highlight the adversarial nature of our existing evaluations, particularly the GCG attacks and robustness testing.

[1] Chao, et. al. Jailbreaking black box large language models in twenty queries.

2. Comprehensive Safety Coverage

"However, safety has many more dimensions than those captured in the static benchmarks and gradient-based attacks the authors used."

Our evaluation actually covers multiple safety dimensions beyond attack success rates:

Multi-dimensional Safety Assessment:

• Attack robustness: 4 different safety benchmarks with diverse attack types
• Helpfulness preservation: Alpaca evaluation shows minimal overrefusal (slight increase)
• General capability maintenance: 9 standard benchmarks show no performance degradation
• Robustness under distribution shift: Benign finetuning evaluation tests real deployment scenarios

Action 2.1: We will emphasize the breadth of our evaluation across multiple safety and capability dimensions.

3. Scaling and Practical Deployment

Indeed, scaling experiments beyond 1B, 600BT scale is beyond our computation capability. The experiment breadth provided in the paper took multiple months of compute time given our resources. The performance implications with scale are indeed to be explored, but we anticipate that models that can reason better will only get safer when their backbone is safe. Recognition at NeurIPS can indeed be a great way to get bigger labs to explore such pretraining interventions, or strike compute collaborations.

That said, we do want to highlight that the strategies such as scoring web data, and rephrasing web data have become quite commonplace in most state-of-art LLM training pipelines[1,2,3]. While previously such efforts have been focussed towards performance improvements, our work pushes a similar strategy for safety improvements. Hence, the methods underscoring safety pretraining itself do not have scalability concerns.

[1] Kimi K2: Open Agentic Intelligence [2] Qwen2.5-Coder Technical Report. Hui et. al. 2024 [3] Nemotron-CC: Transforming Common Crawl into a Refined Long-Horizon Pretraining Dataset. Su et. al. 2024

4. Broader Impact and Future Directions

We see this work as establishing a foundation for pretraining-time safety that others can build upon:

• Open datasets: SafeWeb, RefuseWeb, and Moral Education data for community use were released on Huggingface.
• Reproducible methods: All safety scoring and processing techniques have been detailed.

Action 4.1: We will emphasize the community contribution aspects that enable future research in pretraining-time safety.

Thank you for recognizing the novelty and importance of our approach for baking safety into pretraining. We appreciate your strong support. Please let us know if any additional analyses lie between strengthening your support for our work.

Thanks for your thorough review recognizing our "thorough framework" and "good" experimental quality. We value your feedback on strengthening our experimental rigor and baseline comparisons.

Summary of Concerns and Responses

1. Baseline Comparisons with Existing Methods

"This is not the only body of work looking at the impact of pretraining data on final safety performance. The authors don't compare their experimental results to any method other than theirs."

You're right that we should better position our work relative to existing methods. Our ablation studies (Section 7) are closely related to various existing approaches. We will make it a point to dutifully cite these when they are introduced:

Mapping Our Ablations to Existing Methods:

• Score-0 only filtering (43.8% ASR): Highlights that an approach solely focused on removing harmful content is sub-optimal. Infact, similar observations have been made in a concurrent work [3].
• + Rephrasing (33.6% ASR): Comparable to data curation methods like Liu et al [1] that you referred us to. In Liu et. al. the CTRL framework revises text continually to reduce its pereplexity. Our work is more focused at directly recontextualizing the data.
• Full approach (8.3% ASR): Our comprehensive method

This shows 4.6x improvement over simple synthetic data curation [1] and even more improvement over approaches solely focused on removing harmful content in pretraining corpus [2]. We do want to note that given the sheer compute cost of reproducing any of the baselines exactly and pretrainig for that much compute, it is beyond our capacity to delineate all the differences.

Stranisci et al. [2] focus on various different existing filtering strategies; we find in our work that filtering by itself is not sufficient and that other pretraining interventions (such as rephrasing and contextualization) are crucial in pretraining safer models.

We will add these references and this discussion with them to our revision.

[1] Robustifying Safety-Aligned Large Language Models through Clean Data Curation. Liu et. al. 2024.

[2] What Are They Filtering Out? A Survey of Filtering Strategies for Harm Reduction in Pretraining Datasets. Stranisci et al. 2025.

[3] When Bad Data Leads to Good Models. Li et. al. 2025

Action 1.1: We will reframe our ablation study as comparisons to existing methods, clearly mapping our components to prior approaches.

Action 1.2: We will add a comparative analysis table showing how our approach relates to and improves upon existing pretraining safety methods.

2. Statistical Significance Analysis

"Additionally, the results present no standard deviations... How do we know that/which results are statistically significant?"

We have added in standard errors from running evaluations over 5 seeds. We see the following results:

Similarly, for our pretraining intervention ablations, we have for Benign FT Model ASRs:

We note that since SafeBeam is a modified version of a beam search algorithm it is deterministic and involves no randomness.

Action 2.1: We will add confidence intervals and effect size analysis for all major results using bootstrap methods on our evaluation data.

Action 2.2: We will provide power analysis showing our effect sizes are large enough to be practically significant despite single training runs.

3. Dataset Scaling Analysis

"The authors do not cover how their approach scales with dataset size. However pretraining datasets are now bigger - potentially a few orders of magnitude more than what the authors are exploring."

Scaling Cost Analysis:

• Data for Safety classifier: Fixed cost (Labeling of 10K examples, regardless of corpus size)
• Scoring pretraining corpus and synthetic data generation: This involves inference with a small LLM(eg. 7B sized) or an embedding model (350M parameter).
  • Firstly, we would like to mention that synthetic data generation and rephrasing is indeed a major part of most state-of-art LLM training pipelines[1,2,3], and a lot of compute is indeed accounted to this as it is a crucial, yet one time cost. While previously such efforts have been focussed towards performance improvements, our work pushes a similar strategy for safety improvements.
  • For a rough analysis, let us begin by assuming that the training cost (forward + backward pass) is roughly 3x of the inference cost (only forward pass).
  • If the size of the pretrained model was same as the generator, the total inference cost amounts to only about 33% of the training cost. In practice, inference can be carried out on cheaper and more readily available GPUs (single GPUs without inteconnect). For instance, in our experiments, we distributed the pretraining corpus scoring process across a large number of RTX 2080 GPUs, which are significantly less expensive than the high-end GPUs (e.g., H100) required for actual training.
  • When training a larger model, the relative inference cost becomes an even smaller fraction of the overall budget. For example, for a 32B-parameter model, the inference cost would drop to roughly 7% of the training cost.
  • Crucially, this inference cost is incurred only once and can be amortized over multiple training runs, making its long-term impact on total compute expenditure negligible.

[1] Kimi K2: Open Agentic Intelligence [2] Qwen2.5-Coder Technical Report. Hui et. al. 2024 [3] Nemotron-CC: Transforming Common Crawl into a Refined Long-Horizon Pretraining Dataset. Su et. al. 2024

Action 3.1: We will provide detailed scaling curves and cost projections for trillion-token datasets.

Action 3.2: We will include practical deployment guidance for large-scale applications.

4. Framework Component Justification

"A few elements of the proposed framework seem a little arbitrary. For example, why is there a need for a dual approach in terms of safety classification?"

Our dual classification approach addresses different types of safety issues. We considered three methods for classification, and evaluated their recall on a small held-out set (assuming GPT-4o labels as oracle).

• LLM classifier: Better at contextual/semantic harms (92% recall)
• Embedding classifier: Better at lexical/pattern-based harms (90% recall)
• Ensemble (max score): Combines the strengths of the two (95% recall)

Action 4.1: We will add analysis showing why ensemble classification significantly outperforms individual approaches for comprehensive safety coverage.

Minor Comments

1. The percentage of synthetic data used in the experiments was varying depending on the exact ablation study. The SafeWeb data released by us comprises of 100 billion tokens of synthetically recontextualized data. The RefuseWeb data further comprises of 33 billion tokens, and the Moral Education Data is an additional 24 billion tokens. We will make sure to provide a complete breakdown of these values in a table in the paper. We do release all our datasets on Huggingface for researchers to use. | Data Type | Percentage | |-----------|------------| | Real | 55.39% | | Rephrased | 22.31% | | Refusal | 17.30% | | Moral | 5.00% | | Total | 100.00% |
2. Thanks for the suggestion on the placement! We will update this in the final draft.

Concluding Remarks

Thank you for holding us to high experimental standards. Our ablation studies actually provide strong baselines comparable to existing methods, showing 3-4x improvements over individual approaches. The statistical analysis demonstrates large, practically significant effects. Given this reframing of our ablations as baseline comparisons and the added statistical rigor, please let us know if this address your concerns about experimental completeness, and if anything else would move you toward a more positive assessment :)

We are glad that our response has addressed most of the reviewer’s concerns, and we sincerely thank them for their continued engagement with our work.

the authors did reply in terms of compute cost to apply their pipeline (section 3 of the rebuttal). How about in terms of time though? That's also a significant decision factor, so it would be a great addition.

This is a great question—thank you for raising it. Most of our safety recontextualization pipeline consists of inference with existing models, which is highly parallelizable and can be run on widely available, lower-cost GPUs (e.g., single GPUs without interconnect). For concreteness, our original pretraining corpus was of around 200B tokens. Time taken by various parts of the pipeline:

Safety scoring and tagging: ~8 hours using 160×RTX 2080s (1 GPU per corpus shard).
Initial Rephrasing: ~36 hours using the same setup

This amounts to roughly 2 days total, and can be reduced further easily via additional parallelization. For comparison, a single training run of even a 1B-parameter model on 600B tokens with 256×H100s takes ~96 hours (4 days) and this time scales proportionally as the parameters are scaled.

In contrast, the compute and time for our safety rephrasing pipeline scales with only the pretraining dataset size and not the size of the model being trained. We believe, in practice, even at very large scales, our pipeline will just add a couple of days to the overall training process that usually extends to over a couple of weeks. Finally, again, it is a one-time cost that can be amortized over multiple training runs.

We appreciate the suggestion to make these compute and time costs explicit and will update the manuscript accordingly.

the authors did not address my following question: "how did the authors pick the synthetic dataset sizes they ended up using?"

We apologize for missing this earlier. We first tag the raw web data using our safety classifier. All the data tagged as unsafe is then transformed—via recontextualization for score-1/2/3 content, and via refusals plus moral-education rewrites for score-4/5 content. This process is automatic, and we do not manually fix or tune the size of the generated synthetic data. The final proportions of real and synthetic data in the training corpus are then determined naturally by the number of tokens in each subset after this transformation. We will add this clarification in the updated manuscript.

We again thank the reviewer for their time and would be more than happy to provide any further clarifications. Finally we also request the reviewer to consider updating the overall evaluation score for our work, if they believe that we have addressed most of their concerns.

I thank the authors for their thorough and structured reply, with the inclusion of action items. My concerns have been resolved, except for two:

• the authors did reply in terms of compute cost to apply their pipeline (section 3 of the rebuttal). How about in terms of time though? That's also a significant decision factor, so it would be a great addition.
• the authors did not address my following question: "how did the authors pick the synthetic dataset sizes they ended up using?"

Thanks for your constructive review and assessment that our work addresses an "undeniably important problem." We appreciate your recognition that our paper is "technically solid" and your "borderline accept" recommendation.

Summary of Concerns and Responses

1. GPT-4o-mini Safety Oracle Reliability

"For safety scoring, the authors rely on GPT-4o-mini to generate labels through prompting... using it as a safety oracle may not be sufficiently reliable for detecting nuanced or borderline harmful content."

Based on your comment we added a confusion plot between scores by GPT-4o, GPT-4o-mini, and GPT-4.1. We are showing a table version of the first two due to rebuttal constraints.

Our cheaper GPT-4o-mini approach demonstrates strong performance on the most critical safety challenge - avoiding confusion between safe and harmful content. The results show:

• Only 0.1% of content classified as safe by GPT-4o-mini was deemed harmful by GPT-4o
• Only 1.3% of harmful content was misclassified as safe

This near-perfect separation between safe and harmful categories (with just 1.4% total confusion) validates that our cost-effective approach maintains robust safety boundaries where it matters most.

2. Harmfulness Tag Placement Strategy

"Additionally, harmfulness tags are inserted at random positions with a 5% probability, which could be ambiguous. Since harmfulness often depends on specific chunks, more targeted placement of these tags might improve effectiveness."

We understand your suggestion to wrap harmful text in <harmful>...</harmful> blocks. However, accurately identifying the exact spans of harmful content is much more challenging and often suffers from low recall. For instance, the harmful intent of a passage may only emerge in a long context of surrounding text, leading a span‑based extraction approach to miss such cases.

Of note, we did conduct a systematic ablations on tag placement fraction (Appendix B.3):

• 3% injection rate: Higher ASR (worse safety)
• 5% injection rate: Optimal balance of safety and utility
• 10% injection rate: Lower ASR but significant helpfulness degradation

The 5% random placement was empirically determined to provide the best safety-helpfulness tradeoff. More targeted placement is an interesting direction but would require additional annotation overhead.

Action 2.1: We will highlight the systematic ablation study that led to our 5% random placement choice, showing it was empirically optimized.

3. Dialog Format for Recontextualization

"Why did the authors choose dialog style for recontextualization? Is there any experimental evidence that dialog is more effective than other formats?"

We tested 12 different prompt templates for recontextualization (Appendix J.2), including:

• Dialog format (parent-child, friends)
• Textbook style
• TED talk format
• Teacher script
• YouTube video format

Dialog formats were selected because they naturally incorporate safety reasoning and context, allowing the model to understand why content is sensitive rather than just avoiding it. The use of such conversational patterns and how it impacts pretraining has also been noted in recent literature such as WRAP [1] and Nemotron [2] datasets. This style alignment with post-trainig datasets has been hypothesized to better align with the fine-tuning representations of the models.

Of note, we do highlight in Appendix J.2 our procedure for "Iterative Prompt Engineering" in the subsection on "Synthetic Recontextualization". However, actually training a model on each of these steps is prohibitively expensive, and this exploration is largely based on intuitions developed based on reading the referenced papers.

Action 3.1: We will better highlight our systematic prompt template exploration and the reasoning behind dialog format selection.

4. Safe beam generation only as a baseline

In Figure 2, the authors attribute the increased ASR when training only on Score-0 data to lack of exposure to unsafe patterns. If that is the case, wouldn’t a strong refusal+safe generation strategy alone be sufficient, without the need for rephrasing or moral education? Are there any additional experiments to justify the necessity of those components?

That's a great question -- we believe that the increased ASR when training only on Score-0 data is indeed a lack of exposure to unsafe patterns, which results in a model's lack of understanding why content is harmful.

• Synthetic Recontextualization helps: We've already included an ablation (Figure 2) in seeing the benefits of incorporating Moral Education, which leads to a slight improvement in ASR after benign finetuning (without incorporating the safe generation strategy). Note that these gains are over those already given by synthetic rephrasing data.
• Just refusal finetuning + Safe Beam gives poor helpfulness: We have this exact ablation in Figure 5 in the Appendix. We find that only incorporating a harmful tag without any other of our safety recontextualization interventions leads to a model that is much less helpful, as it has a much weaker understanding of safe vs. harmful queries. This translates to a baseline that has poorer quality generations in benign use cases (e.g., Alpaca).

Concluding Remarks

Thank you for your thorough review of our methodology. Our systematic ablations and ensemble approaches address the core reliability concerns you raised. The validation data demonstrates that our design choices were empirically grounded rather than arbitrary. Given this evidence of systematic methodology and the ensemble safety oracle approach, please let us know if there is any other analysis that would strengthen your opinion about our work

[1] Rephrasing the Web: A Recipe for Compute and Data-Efficient Language Modeling. Maini et. al. 2024.
[2] Nemotron-CC: Transforming Common Crawl into a Refined Long-Horizon Pretraining Dataset. Su et. al. 2024

Thanks for your continued engagement!

Regarding tag placement on misclassified examples and SafeBeam's potential impact

You raise an excellent point about the interaction between misclassification and SafeBeam. Yes, when harmfulness tags are applied to the small fraction of safe content misclassified as harmful, SafeBeam could potentially steer away from some safe generations. Improving the quality of annotations could further improve the safety-helpfulness tradeoff, and we absolutely agree that this is a promising future direction. Furthermore, training models to perform targeted safety tagging (which could be used rather than random tag placement) is a separate open problem in the literature that is actively being studied in the field. Alternative approaches, such as dynamic thresholding during SafeBeam selection (varying based on the confidence of the harmful token) and calibration methods, are potential directions that we plan to explore in the future.

Regarding using all Rephrasing/Moral Ed. data as NativeRefusal:

This is an insightful observation. These experiments are very expensive to run -- due to requiring another full round of pretraining (6 days on 64 H100 GPUs).

We believe that if we converted all rephrasing and moral education data to pure refusal format, we would indeed expect lower ASR. However, we believe that this would come at a significant cost in terms of this safety-helpfulness tradeoff: Pure refusal training lacks the contextual understanding that rephrasing provides. Furthermore, our Moral Ed data was in fact derived from refusal, by generating synthetic data to explain the reasoning behind each of the refusal examples, so that the model can reason as well about the hard boundaries.

As a result, the model would lose the ability to engage with nuanced topics safely. The key insight from our ablations is that each component serves a complementary purpose: rephrasing teaches context-aware safety, refusals establish hard boundaries, and moral education provides ethical reasoning. The combination achieves a better safety-helpfulness balance than any single approach.

Regarding Figure 5 and Score-0 data inclusion:

Yes, you're correct - for the "Harmfulness-Tag PT + SafeBeam" condition in Figure 5, we include Score-0 data during training. We apologize for the confusion and will include this in our revision.

We are happy to address any further comments you might have!

Thanks for your detailed review and recognition that our framework is "well-motivated" with a "significant reduction in attack success rate." We appreciate your thoughtful concerns about the adversarial nature of safety research.

Summary of Concerns and Responses

1. Arms Race and Adversarial Robustness

"What about zero-day safety breaches? As we have seen in (cyber) security for LLMs, there is an ongoing attack–defense arms race."

Our work is aimed at highlighting a new paradigm for building inherently safer models via pretraining time interventions. Having a model with absolute guarantees is indeed impossible and a cat-mouse game does help us to continuously move towards building models that are harder to break. More importantly, our work highlights the extreme brittleness of post-hoc alignment methods and the critical need to approach the problem by taking a step back to pretraining time interventions.

Our existing evaluations actually demonstrate robustness against several adversarial scenarios that approximate "zero-day" attacks:

• GCG attacks (learned adversarial suffixes): 39.0% ASR vs 57.0% baseline - represents adaptive attacks
• Benign finetuning attacks: 8.3% ASR vs 38.0% baseline - represents deployment-time vulnerabilities
• Cross-domain evaluation: Safety holds across different prompt categories not seen during training

These results show our approach raises the bar significantly for attackers, though we agree absolute guarantees are impossible.

Action 1.1: We will clarify that our safety improvements represent substantial risk reduction, not elimination, consistent with defense-in-depth principles.

2. Safety Data Cards and False Security

"Given that these claims are grounded in empirical data, tagging pre-trained data with safety data cards (Levels 0–5) risks creating a false sense of safety."

You raise an important point about interpretation. Our data cards are designed as transparency tools, similar to nutrition labels: they inform decisions but don't guarantee outcomes. Our validation shows that such data interventions indeed have value as shown in our evaluations across multiple threat models.

Adversarial Robustness

Adversarial Robustness: Could you discuss the effectiveness of these techniques against adversarial attacks.

As new attack vectors emerge, safety data card ratings may require updating. In such cases, how will models or datasets previously tagged under an earlier version of the safety data card rating rubric be re-evaluated or upgraded.

Our evaluations test this to some extent, as our pretraining interventions are not aware of the adversarial suffix strategy of GCG. In addition to this, we also add in another adversarial attack, PAIR [1] (based on your suggestion on adaptive attacks). We again find that our approach (which is unaware of this attack) reduces the attack success rate on the JailbreakBench examples

Were the models produced by this pipeline subjected to red-teaming?

While we agree stronger adversarial evaluation (via human red teamers) would be valuable, our current evaluation actually includes several adversarial components that demonstrate robustness:

Existing Adversarial Tests:

• GCG attacks: 39.0% ASR vs 57.0% baseline (learned adversarial suffixes)
• Benign finetuning attacks: 8.3% ASR vs 38.0% baseline (deployment-time degradation)
• Cross-benchmark generalization: Consistent improvements across HarmBench, TDC, JailbreakBench, AdvBench
• Out-of-distribution prompts: Safety holds on evaluation data not seen during training

To strengthen these further, we add in new results using PAIR[1] as another automated red-teaming strategy, as shown in the Table above.

Action 2.1: We will add explicit disclaimers positioning data cards as "labels for datasets" with clear limitations and update protocols.

[1] Chao, et. al. Jailbreaking black box large language models in twenty queries.

3. Scalability Analysis

"Pre-training is expensive. Authors validated the approach on small models (1.7b)... questions arise about the magnitude of safety-annotated data needed and the cost for commercial-sized LLMs."

Our approach has favorable scaling properties:

Scaling Analysis:

• Data for Safety classifier: Fixed cost (Labeling of 10K examples, regardless of corpus size)
• Scoring pretraining corpus and synthetic data generation: This involves inference with a small LLM(eg. 7B sized) or an embedding model (350M parameter).
  • Firstly, we would like to mention that synthetic data generation and rephrasing is indeed a major part of most state-of-art LLM training pipelines[1,2,3], and a lot of compute is indeed accounted to this as it is a crucial, yet one time cost. While previously such efforts have been focussed towards performance improvements, our work pushes a similar strategy for safety improvements.
  • For a rough analysis, let us begin by assuming that the training cost (forward + backward pass) is roughly 3x of the inference cost (only forward pass).
  • If the size of the pretrained model was same as the generator, the total inference cost amounts to only about 33% of the training cost. In practice, inference can be carried out on cheaper and more readily available GPUs (single GPUs without inteconnect). For instance, in our experiments, we distributed the pretraining corpus scoring process across a large number of RTX 2080 GPUs, which are significantly less expensive than the high-end GPUs (e.g., H100) required for actual training.
  • When training a larger model, the relative inference cost becomes an even smaller fraction of the overall budget. For example, for a 32B-parameter model, the inference cost would drop to roughly 7% of the training cost.
  • Crucially, this inference cost is incurred only once and can be amortized over multiple training runs, making its long-term impact on total compute expenditure negligible.

[1] Kimi K2: Open Agentic Intelligence.
[2] Qwen2.5-Coder Technical Report. Hui et. al. 2024.
[3] Nemotron-CC: Transforming Common Crawl into a Refined Long-Horizon Pretraining Dataset. Su et. al. 2024.

Action 3.1: We will provide detailed scaling curves and cost projections for trillion-token datasets.

Action 3.2: We will include practical deployment guidance for large-scale applications.

4. Ethical Concerns

Major Concern: Data quality and representativeness, Major Concern: Safety and security

We deeply appreciate this concern, which goes to the heart of responsible and safe AI development. Our framework was explicitly designed with these ethical considerations in mind.

Data Quality and Representativeness

Our safety training corpus is built from diverse web-scale sources (detailed in Appendix D), filtered and scored using a safety classifier ensemble. We acknowledge limitations in global representativeness. While our data covers a wide range of topics and tones, it may still reflect particular norms or platform biases through our rephrasing strategy and the models used for scoring and rephrasing.

Action 4.1: We will explicitly acknowledge these limitations in the Ethics Statement and clarify that SafeWeb is an initial benchmark, not a universally normative dataset.

Safety and Security

We evaluate our models against multiple adversarial attack types (GCG, benign finetuning, domain shift) to stress-test their safety performance. To avoid creating brittle or overly conservative models, we also monitor overrefusal rates (Figure 6) to ensure utility is preserved. We see safety pretraining as (significantly) risk-reducing but not risk-eliminating. We believe our work helps contribute to transparency and ongoing evaluation of pretraining recipes.

5. SafeBeam without Safety Pretraining

We have this exact ablation in Figure 5 in the Appendix. We find that only incorporating a harmful tag without any other of our safety pretraining interventions (e.g., recontextualization, refusal data) leads to a model that is much less helpful, as it has a much weaker understanding of safe vs. harmful queries. This translates to a baseline that has poorer quality generations in benign use cases (e.g., Alpaca).

Thanks for your constructive review and assessment that our work addresses an "undeniably important problem." We appreciate your recognition that our paper is "technically solid". Please let us know if there is any further explanation that stands between a stronger endorsement of our work.

Thank you for your detailed responses.

My core concern with SDCs remains: if they come with caveats, why have them at all? We could simply state that model inferences should be interpreted with caution.

Unlike Nutrition Labels, which report factual information, SDCs present outcomes from empirical tests. These are fundamentally different in nature.

To reiterate, performance against past (seen) attacks does not guarantee resilience against future, unseen (zero-day) attacks. This is the asymmetry I referred to earlier.

For instance, the claim “Our GCG attacks (39% ASR) and benign finetuning robustness demonstrate resilience to adaptive threats”—what practical guidance does this offer a user? Without formal proofs, SDCs built on such statements could be challenged.

If these are meant as transparency reporting metrics, the paper should be restructured accordingly.

Hi, I am a fellow reviewer. I sympathize a lot with the concerns about false security/safety. May I suggest that the safety card can be interpreted as the best assessment of the model's safety under our current understanding of that definition? I fully agree that adaptive and continuous testing is necessary, especially in high-stakes scenarios. I am also, however, concerned about asking papers to "boil the ocean." The risks you mention are 100% valid and should be clarified front and center and - as I and other reviewers also point out - pre-launch red teaming should be carried out. However, this paper seems to have done a lot of work to benchmark safety and tested with adaptations of popular automated adversaries. It is, in my opinion, unreasonable to ask every paper on safety training to also solve the data poisoning problem to perfection - an area of active research with many publications. May I ask what the reviewer's concrete suggestion is here that would strengthen the paper?