A Model That Refuses Everything Is Not Safe

Part I

Problem Definition

A system can score well on a one-sided harmful-prompt test by refusing every request while remaining unusable and leaving tool misuse, privacy leakage, or adversarial bypass untested [R1] [R2].

This note treats a model that refuses everything is not safe as a bounded control question. It does not infer universal product behavior from a paper, standard, interface screenshot, or single test. A demonstrated result applies only to the cited configuration; an authoritative source defines a requirement or design direction but does not certify an implementation. ACE therefore asks whether the tested system can produce the required behavior and evidence under declared versions, policies, topology, identities, and failure conditions.

The operational distinction is between a claim and a control that can be re-performed. The positive control is: The model assists a benign incident-response request while refusing its harmful operational contrast. The adversarial condition is: A global refusal policy blocks every benign task yet appears perfect on harmful-only scoring. A useful result must show both that authorized work remains possible and that the prohibited path is stopped before an irreversible side effect. Missing fields are classified as insufficient evidence, not silently converted into a pass.

Real-world impact

• Over-refusal can become a policy-driven denial of service that pushes work to ungoverned channels.
• A single refusal-rate dashboard can reward a system that provides no safe utility.
• A control claim without versioned evidence can mislead procurement, audit, incident response, and system owners.
• Failing closed without a positive control can conceal a denial-of-service design rather than demonstrate trustworthy behavior.

Part II

Mitigation Direction

Research-backed direction

1. 01
   research proposed

   Pair unsafe prompts with safe lexical and structural contrasts to detect exaggerated safety [R1].

2. 02
   research proposed

   Use a large, diverse over-refusal set with toxic controls so indiscriminate compliance also fails [R2].

3. 03
   research proposed

   Evaluate robust refusal under adversarial attacks rather than only clean static prompts [R3].

LogionOS engineering mapping

Implementation hypotheses only. No production validation is claimed.

1. 01
   implementation hypothesis

   Add a versioned policy object for a model that refuses everything is not safe and keep its decision inputs outside model-writable context.

2. 02
   implementation hypothesis

   Generate a signed technical receipt linking actor, request, policy version, decision, enforcement point, and observed outcome.

3. 03
   implementation hypothesis

   Export missing evidence explicitly as insufficient evidence and limit every claim to the tested configuration.

Part III

Consequences and Research Agenda

Consequences

• Over-refusal can become a policy-driven denial of service that pushes work to ungoverned channels.
• A single refusal-rate dashboard can reward a system that provides no safe utility.
• A failed acceptance test requires the related capability claim to remain not demonstrated or insufficient evidence.
• A passing test supports only the declared configuration and does not establish universal safety.

Second-order effects

• Stronger enforcement can increase latency, state, operational dependencies, and legitimate denials.
• More evidence can increase privacy and retention exposure unless raw content is minimized and access-controlled.
• A detector or policy service can become a new failure point and must have explicit fail behavior.
• Attackers may adapt to published checks, so the public test direction should be paired with private regression variants.

Limitations

• Several cited AI-agent and reasoning-security sources are preprints or bounded experiments; they are identified as such in the references.
• The proposed ACE acceptance test has not yet been run across all incumbent and AI-native implementations.
• Cryptographic integrity proves that an artifact was not altered after commitment; it does not prove that the artifact was true, complete, or correctly interpreted.
• Legal and contractual applicability remains deployment- and jurisdiction-specific.

Open research questions

1. What safety-utility frontier is acceptable for each enterprise workflow?
2. How should refusal disparities across language, dialect, and sensitive-topic discussion be measured?
3. Which evidence fields are mandatory for a demonstrated result, and which may be not applicable?
4. How should continuous regression detect policy, model, tool, and provider drift after the initial test?

Sources

References

1. [R1]
   XSTest: A Test Suite for Identifying Exaggerated Safety Behaviours

   published · original-paper

2. [R2]
   OR-Bench: An Over-Refusal Benchmark for Large Language Models

   preprint · original-paper

3. [R3]
   HarmBench: A Standardized Evaluation Framework for Automated Red Teaming

   published · original-paper

Record

Publication Record

Recommended citation

Ma, Chris. “A Model That Refuses Everything Is Not Safe.” ACE Research Note ACE-RN-2026-020, v1.0, 2026.

Corrections

No corrections recorded.

Organizational disclosure

ACE Research and LogionOS share organizational affiliation. LogionOS mappings in this note are implementation hypotheses, not independently validated product claims.

Evidence boundary

This note synthesizes cited public research and defines an ACE acceptance direction. It does not report a completed cross-vendor experiment unless explicitly stated, and it contains no private ACE prompts, holdout identifiers, customer data, or raw model responses.