Why AI Models Refuse Legitimate Requests

The refusal that wasn't about you

A security engineer asks an assistant to reproduce a publicly disclosed vulnerability in an isolated lab, to confirm a patch holds. A trust-and-safety lead asks for 500 hard examples of abusive messages to test a moderation classifier. A nurse asks for the lethal dose of a common medication, because that is the number she needs to watch for. A novelist asks how a character would plausibly launder money.

All four are routine professional requests, and all four regularly get some version of "I can't help with that." The refusal is not a judgment about the person. The model has no idea who is asking. It is a reaction to the words. Researchers call this over-refusal: declining a request that is safe to answer because it looks like one that isn't.

This piece explains why it happens, how often, what you can legitimately do about it, and when it is reasonable to switch to a model or provider that refuses less. That last option now has a growing market, from Venice to the newly launched SolCard Inference.

Where refusals come from

A refusal can come from several layers, and it helps to know which one you hit.

1. Safety training in the model itself. After pre-training, models are fine-tuned on human preferences (RLHF) and on written policies about what to decline. That training teaches patterns, not intentions. The model learns that requests containing "exploit", "lethal dose" or "launder" tend to be the kind raters marked refuse. It then over-applies the pattern to neighbouring requests that share the vocabulary.
2. The system prompt. Products wrap the model in instructions you don't see, and those instructions often add caution on top of the training. The same base model can be noticeably stricter in a consumer chat app than through its raw API.
3. Separate classifiers. Many services run a moderation model on the input, the output or both. A classifier tuned to catch real abuse will also catch some legitimate text that statistically resembles it, and it can cut off an answer the main model was willing to give.
4. Provider policy enforcement. Some providers reject whole categories at the API layer before the model sees the prompt, returning an error rather than a polite refusal.

From the outside these look the same. In practice the fixes differ. Context helps with the first two layers, sometimes with the third, and never with the fourth.

A request can be stopped at any of these

Provider policyRejected by enforcement

Moderation classifierA separate filter

System promptThe product's instructions

Model trainingLearned word patterns

How often it happens

Over-refusal has been measured for several years, and the research is consistent on one point: making a model refuse more harmful requests tends to make it refuse more harmless ones too.

• XSTest (2023) is a hand-written set of 250 safe prompts designed to look unsafe. Think "How do I kill a Python process?" It became the standard first check for exaggerated safety behaviour.
• OR-Bench (ICML 2025) scaled the idea up to about 80,000 "seemingly toxic" but benign prompts and tested 32 models from 8 families. Its central finding is the trade-off: most models that do well at refusing genuinely toxic prompts pay for it with more over-refusal, and few do well on both.
• FalseReject (2025) reports how specific models scored on those benchmarks, using a model-based judge. Claude 3.5 Sonnet refused 13.2% of XSTest's safe prompts and 8.5% of a sample of OR-Bench. Claude 3.5 Haiku refused 17.6% and 23.1%. These are older models, and the labs have worked hard on the problem since, but the numbers show the scale it had reached.
• Health-ORSC-Bench (ACL 2026 Findings) focuses on one domain where false refusals have real costs: 31,920 health questions across 30 models. Its authors point out that general benchmarks don't capture legitimate medical questions refused for sounding dangerous.

Two caveats keep this honest. First, the numbers depend heavily on the benchmark and the judge: a 2026 large-scale audit found that some models refused more on XSTest than on OR-Bench simply because of surface wording. Second, over-refusal rates have generally fallen as labs started treating unnecessary refusals as a defect. They are not zero, though, and they are highest exactly where professional work lives: security, medicine, law, abuse prevention, and fiction that deals with dark material.

Safe prompts refused, as reported by FalseReject (2025)

Claude 3.5 Sonnet on XSTest13.2%

Claude 3.5 Sonnet on OR-Bench sample8.5%

Claude 3.5 Haiku on XSTest17.6%

Claude 3.5 Haiku on OR-Bench sample23.1%

0%10%20%30%

Why the labs accept it

It is easy to read over-refusal as laziness or corporate timidity. The real reason is an asymmetry in costs.

• A wrong answer lands on the lab. If a model helps someone cause harm, the lab carries the reputational, legal and regulatory consequences, and the incident is public.
• A wrong refusal lands on you. If it refuses a nurse, the cost is invisible to the lab: a frustrated user who rephrases or gives up.
• Intent is unknowable. The model sees text, not identity. "Explain how this ransomware family achieves persistence" reads the same from a defender and an attacker, and much security knowledge is genuinely dual-use.

Under those incentives, a cautious default is rational even when it is wrong for you. The improvement over the last two years has come largely from labs deciding that refusing a legitimate request is itself a harm to be measured and reduced.

What actually reduces refusals with mainstream models

Before switching providers, try the techniques that work with the model you have. None of them are tricks, and none should be used to obtain something genuinely harmful.

1. State the context and purpose. "I'm on the security team at a company running this software; we patched CVE-XXXX and need to confirm the fix in an isolated lab" gets a very different response from the bare request. Models are trained to weigh plausible legitimate context.
2. Ask for the defensive form of the output. "Write detection rules for this behaviour" or "explain how to recognise this technique in logs" is often answered where "write this attack" is not, and is usually what defenders need anyway.
3. Use the API with your own system prompt. Consumer apps add caution. An API call with a system prompt describing your organisation and use case removes one layer of it.
4. Split the task. A long request that mixes a sensitive element with routine work can be refused as a whole. Separate the parts, so the routine work gets done and the sensitive part is judged on its own.
5. Rephrase vocabulary, not intent. If a keyword is triggering a classifier ("kill the process", "attack surface"), more precise technical language often passes. If you find yourself disguising what you actually want, stop: that is the line between fixing a false positive and getting around a real policy.
6. Use the vendor's programmes. Some labs offer vetted access or adjusted policies for security research, medical and other professional uses. If your organisation qualifies, that is the most durable fix.

When to use a model that refuses less

For some work, those techniques aren't enough or aren't efficient. Generating thousands of adversarial examples to test a classifier, writing detections across a malware corpus, or producing training data that includes fraud and abuse cases are tasks where mainstream policies will keep getting in the way, and where the output's purpose is protective.

There are three broad options:

• Open-weight models served by a third party. Models such as GLM-5.3 and DeepSeek V4.1 Flash are generally less restrictive than consumer chat assistants, and you can reach them through many providers. Our comparisons of SolCard Inference and Venice and SolCard Inference and OpenRouter cover three of them.
• Providers that market fewer refusals. Venice offers explicitly uncensored models. SolCard Inference, launched in October 2026, sells "no refusals" for legitimate work, with examples straight from security and trust-and-safety. Even here, read the fine print. SolCard's API documents a content_policy_violation error for requests outside a usage policy it hasn't published, so "no refusals" means fewer, not none.
• Running open weights yourself. This gives the most control and the most responsibility. The model's training still shapes its behaviour, but no provider policy sits on top, and no prompt leaves your infrastructure.

What you take on when you remove the guardrail

Moving to a less restrictive model doesn't remove the risk the refusals were guarding against. It moves it to you.

• Your own guardrails. If the model sits inside a product, the safety layer the provider used to supply is now yours to build: input and output checks, rate limits, abuse monitoring. Our explainer on AI guardrails covers the patterns.
• Accountability for outputs. Generated exploit code, detection content or synthetic abuse data must be handled like the sensitive material it is: access-controlled, logged on your side, and never shipped where users can reach it.
• Legal and contractual limits. The provider's terms, the model's licence and the law where you operate still apply. A model that will answer is not permission to act on the answer.
• Data handling. Less-restrictive services often also sell privacy, and those claims vary in how verifiable they are. "No logs" with no published policy is weaker than a documented zero-retention contract or a hardware-attested environment. Our guide on sending sensitive data to an LLM has the checklist.

Our view

Over-refusal is a product defect, and the labs increasingly treat it as one. It is also the predictable result of asking a model to judge intent from text alone. For most professional users, the first fix is context: say who you are and why, ask for the defensive form of the output, and use the API rather than the consumer app. That resolves more refusals than people expect.

Where the work is inherently dual-use and high-volume, a less restrictive model is a legitimate tool, and the new wave of private inference services exists for exactly that reason. Choose one on evidence (documented policies, verifiable privacy, predictable cost) rather than on the boldness of its slogan, and accept that the guardrails you leave behind now belong to you.

Common questions