EscalAtion: Assessing Multi-Agent Risks in Military Contexts

This project applies Anthropic's BLOOM framework to detect manipulation in multi-turn LLM conversations, evaluating three models across 20 advisory scenarios. The paper is clearly written and straightforward to follow.

The core challenge is operationalization: the work measures conversations where recommendations increase and beliefs shift over time, but doesn't demonstrate this constitutes manipulation rather than normal advisory dynamics. Financial advisors legitimately help clients refine vague goals into specific plans, which involves increasing specificity and shifting beliefs through collaborative refinement.

Critical missing evidence includes: (1) example conversations showing what crossed the manipulation threshold versus what didn't, (2) the rubric given to Claude Sonnet 4.5 for scoring, making it impossible to assess how the judge distinguishes manipulation from helpful persuasion, (3) human validation of the 77.9% detection rate, and (4) outcome assessment showing "manipulated" users made worse decisions.

The missing counterfactual is particularly important: to claim "commitment escalation," you'd need to compare scenarios with/without prior statement referencing to show that referencing causes increased compliance rather than just reflecting natural information accumulation as the AI learns user preferences.

The work would be strengthened by: providing 3-5 example flagged conversations with turn-by-turn scores plus non-flagged examples for contrast, including the complete judge rubric, conducting human validation, testing the counterfactual, and assessing whether detected patterns correlate with harmful outcomes. These would clarify whether the system detects genuine manipulation or normal conversation patterns where advice becomes more refined over time.

This paper evaluates how models might influence users using tactics that develop over the course of an interaction. They focus on two particular strategies outlined by Cialdini, commitment escalation and gradual belief shifting.

This is an interesting angle and manipulation over the course of a conversation. It's definitely an area that requires more attention.

The main problem that I see with this paper is that it does not seem to provide much control for evaluating whether what is judged to be manipulation is in fact plausibly manipulation. They mention that they base their judge criteria on a thorough rubric. It would have been very good to include this rubric as an appendix so that someone reading the paper could assess whether it is plausible. In its current state, the risk is that what merely should count as being a helpful advisor in some way would in fact qualify as being manipulative by this rubric, and I have no means of checking whether that is true. If that were true, then the relatively high number of manipulation suggested by these results could be entirely explained as an artifact of those criteria without ruling the scenario out. The value of the paper is severely diminished.

I would recommend the author to spend some time making clear what makes something manipulative as opposed to merely helpfully influential and make that abundantly clear to the reader while developing clearer methods to make sure that the judge model picks up on these differences.

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.