CBRN-SAFE-Eval: Transparent Escalation Framework

This project is an impressive MVP for something developed so quickly! It’s also great to see careful thought given to issues of real-life relevance like unsafe content storage and notification timing.

One limitation is novelty: crescendo attacks are not a “new threat model” (https://doi.org/10.48550/arXiv.2404.01833 is not cited) and, on newer models, less effective (https://doi.org/10.48550/arXiv.2410.10700), which makes the approach feel less forward-looking. The watchlists and scoring system are also rather simple (though it makes sense for a hackathon).

To strengthen the work, it would help to benchmark against a wider set of adversarial techniques, clarify what’s genuinely new, and use worst-case scores rather than averages (like SWS), since the most harmful query matters most. A valuable next step would be stress-testing the framework against obfuscation strategies (character substitutions etc.).

Regarding (quick) code replication, the demo ran nicely but, if removed, results/logs they are not regenerated.

Overall, it seems like this project relied too much on AI assistance and not enough human thought/refinement. The formatting of the paper is a giveaway, it does not match the style or structure of an academic paper. Given it was a single person over a weekend, it's understandable, but I recommend going for a smaller scope and executing one thing well rather than creating such a sprawling project with mentions of many contributions that aren't quite useful.

It's not motivated that the multi-turn crescendo attacks are a viable jailbreaking strategy with modern LLMs. By default, I would expect LLMs to start refusing when they get to the more severe messages. Most model providers already have a flagging/banning mechanism in place for users who make too many unsafe requests.

It's nice that code was provided, but it's not something that would realistically be useful in an LLM safety system due to over reliance on naive LLM judges. I would have liked to see some discussion of validation the judges using a labeled validation set to build confidence in them before deployment.

Key strengths of the approach

There was a solid background on IAEA and nuclear C3 systems and a clear explanation of choke points (centrifuges, enrichment, etc.). I liked that there was a proposed framework with guiding principles. Good mentions of early warning and forecasting ideas

Critique:

Not novel (similar work already done by IAEA, US, etc.). A lot of the project felt like it was recommending to simply put an AI on top of data that was already collected (this already happens, and/or the IAEA is already looking into it).https://www.energy.gov/topics/artificial-intelligence-national-security, https://www.pnnl.gov/news-media/detecting-nuclear-threats-artificial-reasoning

No direct references to IAEA’s own AI integration work which was a bit suprising:  https://www.iaea.org/projects/crp/j02024 ,

https://www.iaea.org/bulletin/how-artificial-intelligence-will-change-information-and-computer-security-in-the-nuclear-world 

SAFE Framework relies too heavily on querying Google searches which would not help as nuclear processes are kept secret and any thing made public enough to appear on google could/ is already monitored by nuclear watchdogs.

Would have liked to see more literature on how using AI in forecasting would help.

Some guidelines seemed misaligned with AI integration focus (e.g., export controls in guideline #3)

Questionable feasibility of AI supply chain audits (data secrecy issues)

//Suggestions for how to develop this into a stronger project//

1) Narrow focus to one concrete application of AI in nuclear monitoring

2) Back claims about AI forecasting with data/research

3) There is an IAEA event happening next month on this issue: https://www.iaea.org/events/evt2405595 

Key strengths of the approach

1) Well-structured tier system as a framework

2) Clear demonstrations with wide-ranging metrics

3) The paper took a proactive approach to preventing CBRN risks.

4) There was a well-defined research question and supporting need at the outset.

5) System works within one second which was a strong technical result because it probably doesnt get in the way of UX.

Specific areas for improvement

1) No consideration of jailbreak attacks in demonstrations which is probably the main attack vector.There was also no strategy for this.

2) Some wording felt convoluted and unclear

3) I was not sure if the framework was intended for model providers or government mandate? (Audience wasnt clear)

4) Did not discuss privacy implications of monitoring every chat or how that interacts with existing legislation. My understanding is that scanning each and every chat to be automatically scanned might also use computational resources, which is not analyzed, and probably a major reason why a lab might not want to do this.

5) Tier definitions (Tier 2 vs Tier 3 for example ) was not clearly distinguished - what is the difference between conceptual knowledge and contextual guidance.

Suggestions for how to develop this into a stronger project

1) Incorporate jailbreak attack attempts into evaluation framework

2) Clarify intended audience (providers vs policymakers) and how this is going to get feeded into the governance of systems.

3) Define metrics and tier distinctions more explicitly

4) Acknowledge latency–privacy trade-offs in real-world deployment

The submission shows a single proof of concept attack and outlines an incident escalation protocol.

It could be made much stronger by connecting to the frontier labs' safety and threat intelligence teams protocols.

The core premise of "all systems are vulnerable to crescendo attacks" seems unsupported. The threat model, as in "who are the adversaries and what are their goals" should be laid out explicitly.

Additional work on the threat model will elucidate the project's next steps.