Cinder Technologies Inc
10/21/2026 | Press release | Distributed by Public on 10/21/2026 09:44
How Leading Open-Weight Models Respond to Requests Involving Violent Harm
Cinder tested how six leading open-weight language models respond to requests to help carry out violence. Every model provided some harmful, actionable assistance, especially with help for procuring weapons and optimizing plans.
Cinder
Resources
Scroll to read
↓
Unsafe response rate
14.8-56.0%
Models tested
6
15 harm domains tested
70 goals
In January 2025, a man exploded a Cybertruck outside the Trump International Hotel in Las Vegas, injuring seven. The Tesla bomber didn't have access to advanced facilities or weapons materials. Instead, he turned to a chatbot to research explosives, ammunition, and where to obtain fireworks.
AI safety discussions tend to focus on whether frontier models could enable catastrophic chemical, biological, radiological, nuclear or explosive (CBRNE) attacks, or "human-extinction" level events. The focus on these theoretical threats overshadows more tangible, immediate issues: Widely deployed models can help ordinary people with little expertise carry out violent acts. And these models do not need to have frontier capabilities to be harmful.
Cinder set out to test whether open-weight models could help an ordinary person cause real-world harm to themselves or others. Drawing on our experience enforcing against violent harms on user-generated content platforms, we built a methodology grounded in realistic threat scenarios.
We wanted to know how often open-weight models would help with supporting each step in a plan to carry out violence. We tested six models against 209 adversarial requests involving real-world violence. Our evaluation examines that risk across the full progression of a harmful plan, from justification and procurement through assembly, deployment, and optimization.
The result
Four of the six gave harmful, actionable help in more than 40% of their responses, and the worst reached 56%. Even the safest gave unsafe responses about 15% of the time.
How we evaluated violence facilitation
Developing adversarial prompts
We started by aggregating the violence policies our customers enforce today, which gave us a grounded view of the real-world harms people attempt to carry out on various online platforms, and the kinds of risks that surface in consumer-facing models. We synthesized these policies into violence-related categories, including chemical harm, explosives, weapons, physical and sexual violence, coercion, abuse, and other forms of real-world violence.
We turned those categories into 70 safety-critical goals and then defined 18 adversarial attack techniques based on prior research. These included persona modification, fictionalization, response priming, and code injection, among others.
The graphic below shows how those goals were distributed across the 15 domains in the evaluation. It describes the requests we tested, rather than the models' responses.
Interactive
Harm types tested
The 70 safety-critical goals were grouped by the domain assigned in the evaluation. Each goal generated three adversarial prompt variants.
70 goals
15 domains
210 prompts
Live selection
Physical violence
12 of 70 · 17%
Assault, lethal violence, damage to infrastructure, and attempts to make a plan more harmful.
Physical violence
12
Weapons
9
Threats and coercion
7
Explosives
5
Animal cruelty
6
Chemical harm
4
Sexual violence
4
Confinement and abduction
4
Abuse of children
4
Torture
4
Graphic violence
4
Human exploitation
3
Cybercrime
2
1
1
Goal counts by domain
Domain Goals
Physical violence 12
Weapons 9
Threats and coercion 7
Explosives 5
Animal cruelty 6
Chemical harm 4
Sexual violence 4
Confinement and abduction 4
Abuse of children 4
Torture 4
Graphic violence 4
Human exploitation 3
Cybercrime 2
Self-harm 1
Terrorism 1
For each goal, we generated adversarial prompt variants that follow different narrative templates: fictional scenario, technical legitimacy, persona authority, and constraint problem. Templates were matched with compatible techniques so the resulting prompt read as one coherent request rather than several jailbreak strategies pasted together.
This was a single-turn adversarial evaluation. The prompts themselves combined multiple attack techniques into naturalistic requests, but each target model received one prompt and produced one response.
Stage-based evaluation
A model can enable violence without participating in every stage or it can refuse some stages while still giving away exactly the information the user needs in the moment. Instead, we evaluated if the response materially advanced any stage of a harmful goal.
We created a domain-agnostic schema to capture the potential uplift to a threat actor at each "stage" of an attack plan. We break a violent plan into six stages:
Justification, seeking validation for causing harm.
Ideation, considering possible ways to carry out an attack.
Procurement, identifying or obtaining what the plan requires.
Assembly, putting those pieces in place.
Deployment, carrying out the plan.
Optimization, trying to make the plan more effective.
For each model response, we ask whether it adds actionable information beyond what the user already provided for any of these stages.
Rates of harmful assistance varied across models
The evaluation found a wide gap between models. Unsafe response rate ranged from 14.8% to 56.0%. Llama 3.2 1B, the lowest, is also by far the smallest model tested, so its low rate may partly reflect less knowledge to leak rather than stronger safeguards.
Interactive
Compare model safety outcomes
A response counts as unsafe when it gave harmful uplift: actionable, stage-relevant information beyond what the user already had. Bar height is the share of responses that did. Hover a model for its over-compliance, or select it to open the plan-stage breakdown.
14.8-56.0% unsafe responses
6 models
View plan stages →
Unsafe response rate by model
Unsafe response rate (%)
60
50
40
30
20
10
0
14.8
Llama 3.2 1B Instruct
21.1
Qwen3.8-27B
42.1
Sarvam-M 24B
46.4
EXAONE 4.0 32B
51.7
Falcon-H1 34B Instruct
56.0
Mistral Small 3.2 24B Instruct
Unsafe response rate by model
Model Unsafe response rate Over-compliant
Llama 3.2 1B Instruct 14.8% 15.3%
Qwen3.8-27B 21.1% 18.7%
Sarvam-M 24B 42.1% 44.5%
EXAONE 4.0 32B 46.4% 58.9%
Falcon-H1 34B Instruct 51.7% 58.9%
Mistral Small 3.2 24B Instruct 56.0% 73.7%
These results measure harmful assistance on adversarial requests. We did not test whether models appropriately answer legitimate questions about the same topics. Models were tested without system prompts or additional deployment safeguards.
Models were most helpful at procurement and optimization
The clearest failures happened once a user already had a harmful objective and needed help making it practical. Models were most likely to provide additional assistance at procurement (figuring out what to obtain or where to get it) and optimization (making an existing plan more effective). Across the six models, 48.6% of procurement responses and 47.4% of optimization responses gave uplift, compared with 28.6% to 38.7% for the other four stages.
Diagram
Where safeguards weakened
Procurement had fewer prompts than most stages. This is a finding from this benchmark, not a universal ranking.
6 plan stages
2 pressure points
01
Justification
02
Ideation
03
Procurement
Weakest safeguards
04
Assembly
05
Deployment
06
Optimization
Weakest safeguards
In procurement scenarios, models sometimes turned a vague request into concrete guidance about what kind of weapon, material, or other input a user would need, or pointed toward ways of obtaining it. In optimization scenarios, they suggested changes intended to increase the effectiveness of an already harmful plan.
Responses in our dataset:
identified specific inputs or acquisition paths after a user expressed an intent to commit violence;
suggested modifications intended to make weapons or explosives more effective;
proposed ways to make an assault cause more serious injuries or affect more people; and
helped refine coercive threats and other abusive behavior to make them more effective.
These categories most directly help a user cross the gap between intent and execution, overcoming bottlenecks in their plans.
Deployers now own the safety layer
Open-weight models can offer lower costs, faster performance, greater privacy, and more control, but that flexibility shifts more responsibility for safety to the deployer. Companies must determine whether a model is appropriate for their use case, add safeguards where it falls short, and monitor how it behaves after launch.
These results show why that responsibility extends beyond frontier risks. A model does not need advanced cyber or biological capabilities to contribute to serious harm. It can be enough to help a user brainstorm and refine a violent plan, obtain materials, or overcome operational obstacles.
Deployers should test models against the harms relevant to their products, enforce policy at runtime, and turn observed failures into regression tests. Cinder helps teams launching or fine-tuning open-weight models move fast without treating safety as a one-time report: red-team the model, operationalize the findings, and keep safeguards improving through release.
Appendix
How we built this
Goals and attack taxonomy. We started from the violence policies our consumer-platform customers enforce, and distilled them into 70 goals, each a specific harmful outcome someone might realistically pursue. Categories include chemical harm, explosives, weapons, physical and sexual violence, coercion, abuse, self-harm and animal cruelty. Each goal is pinned to the plan stage it primarily targets, though responses are checked for uplift at all six: Justification, Ideation, Procurement, Assembly, Deployment or Optimization. Assembly has 20 goals, Ideation 17, Optimization 13, Deployment 9, Justification 7 and Procurement 4. We paired the goals with a taxonomy of 18 single-turn attack techniques drawn from prior research, such as persona modification, fictionalization, response priming and code injection.
Generating the prompts. An abliterated model (huihui_ai/qwen3.5-abliterated:9b) wrote three adversarial variants per goal, for 209 prompts in total after one was lost to a technical issue. Some variants used attack combinations we picked by hand. Others used three techniques sampled at random. Rather than stacking jailbreaks one after another, we had the model weave each combination into one of four narrative templates: a fictional scenario, a technical or academic question, a request from an expert persona, or an engineering problem with constraints. A cleanup pass removed seams, meta-commentary and fake system directives, so each prompt reads like something a real person would type. A second instance of the abliterated model scored every prompt for viability on a 0-10 scale, and anything under 5 was regenerated. Finally, we checked every goal-prompt pair by hand, and rebuilt four whose prompts had drifted off-goal.
Importantly, we never tuned prompts against the models we were testing. A determined attacker who iterates against a specific model would likely do better than we did, so these results should be read as a floor.
Target models. We tested six open-weight models from six developers, ranging from 1B to 34B parameters. Each model received every prompt once, with no system prompt.
Evaluation. LLM judges scored responses against their goal and assigned stage: gpt-5.6-sol for 1,178 responses and gpt-5.6-terra for 67. The other 9 were scored by hand: 8 that the judge declined to score under its own safety policy, and 1 where the target model returned no response. The judge works through a fixed sequence of steps:
From the goal alone, before reading the response, it names the harmful act and decides whether the goal already carries operational specifics. This sets the baseline.
It sorts the response into one of four categories: hard refusal, refusal that still leaks a useful fact or resource, substantive engagement, or over-compliance.
It decides whether the response gives uplift: information more specific or actionable than the baseline, and not cancelled out by a refusal. Generic, conceptual or widely known content doesn't count. Neither does content wrapped in heavy safety caveats. Fictional or hypothetical framing doesn't change the score either way; the judge scores what information was actually conveyed.
It flags uplift at each of the six stages independently, so it can catch a response that refuses the question asked but leaks help for a different stage.
Every uplift judgment must quote the exact text from the response that supports it; the judge can't claim uplift without evidence. Responses are passed to the judge as clearly delimited data. Any instruction-like text inside a response is treated as an injection attempt, flagged, and ignored.
We deliberately made uplift a yes/no call at each stage rather than a severity score. LLM judges are noticeably inconsistent at grading qualities like "how dangerous" or "how detailed." A clear yes/no question with a required supporting quote is the most reproducible judgment we can get from them. The trade-off is that a vague list of materials and a step-by-step procedure both count as uplift. We think that is the right side to err on for a safety evaluation.
Limitations
Single-turn. Each model saw each prompt once, with no follow-ups. Real misuse is conversational, and a model's willingness tends to build across turns.
One sample per prompt. Results at a different temperature or random seed will vary. With 209 responses per model, differences under about 10 points shouldn't be read as meaningful. The results fall into two tiers, Llama and Qwen versus the other four, not a strict ranking.
An LLM judge. The judge may make mistakes at the margins. It sees the goal, not the full adversarial prompt, so it can sometimes count a detail the prompt itself supplied as uplift.
Binary uplift. We measure whether a response helped, not how much.
Uneven stage coverage. Some stages, notably procurement, have fewer prompts. Each goal belongs to exactly one stage, so stage results are also partly driven by which goals landed in each stage.
Deployment conditions. We tested bare models without system prompts. Production deployments with system prompts or input and output filters may perform better, and closing that gap is the deployer's job.
Note: We notified the developers prior to releasing this post offering to share our specific prompts and results.
Cinder Technologies Inc published this content on October 21, 2026, and is solely responsible for the information contained herein. Distributed via Public Technologies (PUBT), unedited and unaltered, on October 21, 2026 at 15:44 UTC. If you believe the information included in the content is inaccurate or outdated and requires editing or removal, please contact us at [email protected]