Automatic Safety Downgrading for High-Risk LLM Requests

Frontier generative models continue to improve in code understanding, tool use, and cross-domain reasoning. Those gains also expand the capabilities that can be misused, including cybersecurity knowledge, sensitive biological and chemical procedures, and model distillation or extraction.

Relying solely on the primary model’s internal alignment creates a critical dependency: if a jailbreak or prompt injection succeeds, advanced capabilities and high-risk behavior may become accessible together.

An engineering approach to this problem is to use an independent classifier to assess intent in real time and route requests that trigger high-risk policies to an older, more constrained model rather than immediately rejecting them. This separates capability delivery from safety enforcement.

The vast majority of everyday conversations should remain outside this fallback path. The objective is to preserve the normal user experience while withholding the strongest model’s most sensitive capabilities from high-risk requests.

Why Downgrade Instead of Reject?

Hard refusals introduce two problems.

First, classifiers inevitably produce false positives. Rejecting every flagged request can interrupt legitimate research, defensive security assessments, and compliance audits.

Second, refusals provide feedback that attackers can use to probe policy boundaries.

Downgrade routing takes a different approach. Users can still receive useful responses, but those responses come from an intentionally constrained older model. Sensitive capabilities—such as constructing complex exploit chains, providing detailed experimental procedures, or producing large-scale distillation recipes—are deliberately reduced.

The underlying release rationale is to make selected advanced capabilities available under safety constraints rather than delaying all access until every risk has been fully resolved.

Three considerations motivate this design:

• Externalities from advanced capabilities: Cybersecurity, biological and chemical risks, and model distillation are priority areas for control, with cybersecurity often subject to particularly strict policies.
• Release pressure: Waiting for the primary model’s alignment to fully match its capabilities can substantially delay deployment.
• Independent verification: A separate classifier can be red-teamed, tuned, and updated without retraining the primary model each time.

Architecture: Classification, Routing, and User Notices

A typical pipeline has four stages.

1. Independent Real-Time Classification

The classifier is decoupled from the primary inference service. It scores user messages, multi-turn context, and attachment metadata with low latency.

Inputs typically include:

• The original query
• A summary of the conversation history
• Whether the request indicates an intent to use tools

The output is a multilabel risk vector, such as {cyber, bio_chem, distillation, other}, with associated confidence scores.

The classifier should use an architecture with substantially less capability than the primary model, or a dedicated model with strict alignment controls. The intent is to avoid allowing the high-capability model to authorize its own access.

2. Policy Evaluation

Each risk label has thresholds and combination rules.

For example, a cybersecurity score above its configured threshold may be sufficient to trigger routing. A distillation-related classification may instead be combined with patterns such as requests for weight-level details or large-scale synthetic training-data recipes.

Initial settings may favor caution, accepting more false positives to reduce missed detections. They can then be adjusted using labeled production data.

3. Safe Routing

When a request matches the policy, it is forwarded to an older model instance with more limited capabilities. That instance may also have selected tools disabled, a shorter context window, or high-risk skill plugins removed.

A response header or in-conversation notice should clearly tell the user that the request has been switched to a safety-constrained fallback model. Silent downgrades can undermine trust.

4. Auditing and Feedback

Each downgrade should be recorded in an audit log, including:

• Classification scores
• The rules that triggered routing
• Any user appeal concerning a false positive
• Subsequent human annotations

Monitoring should focus on sudden changes in downgrade rates, spikes in particular risk categories, and repeated probing by the same user.

These records feed back into classifier tuning. The objective is to bring false positives within an acceptable range while maintaining a safety standard under which no general-purpose jailbreak with scalable bypass potential has been identified.

The following pseudocode illustrates the routing logic:

risk = classifier.score(messages)
if risk.cyber > T_cyber or risk.bio > T_bio or risk.distill > T_distill:
    reply = legacy_model.generate(messages)
    attach_notice("Routed to a safety-constrained fallback model")
else:
    reply = frontier_model.generate(messages)
audit.log(risk, route)

Policy Priorities Across Three High-Risk Domains

Cybersecurity

The primary concern is not conceptual discussion. It is actionable exploit chains, weaponized scripts, and step-by-step guidance for targeting unauthorized systems.

Defensive research, patch analysis, and authorized compliance scanning should generally qualify for an allowlisted or lower-risk path.

The classifier needs to consider contextual features, including whether the target is an unauthorized asset and whether the user requests a runnable proof of concept. Otherwise, routine security engineering work may be downgraded indiscriminately.

Biological and Chemical Risks

The focus is on experimental details, acquisition methods, and production scale-up procedures that could cause harm.

General educational explanations and reviews of published literature should remain available through the primary model wherever possible.

Policy evaluation can look for combinations such as specific reagent ratios, an ordered procedure, and an intent to evade regulatory oversight, rather than relying on blanket keyword restrictions.

Model Distillation

Relevant requests include attempts to elicit large volumes of otherwise hidden model behavior, systematically extract alignment policies, or construct reproducible datasets for training a student model.

Scale, systematic collection, and transferability help distinguish these activities from ordinary requests to explain how distillation works.

The classifier can give additional weight to an explicit combination of bulk generation of diverse samples and an intention to use those samples to train another model.

Testing and Release Strategy

Deployment should follow sustained internal adversarial testing and external red teaming.

One testing measure described for this approach is more than a thousand cumulative hours of jailbreak attempts. The emphasis is on finding general-purpose, transferable bypasses that can be written once and reused across multiple scenarios, rather than isolated prompt tricks.

If testing identifies no stable general-purpose jailbreak, the mechanism can be released alongside the model, while acknowledging that the initial classifier may be overly conservative. This does not mean that every possible bypass has been ruled out.

After release, optimization should proceed in the following order:

1. Collect false-positive examples. Develop exemption templates for legitimate settings such as security operations, life-sciences compliance, and university teaching.
2. Review borderline scores manually. Focus on requests that are legitimate but use terminology associated with sensitive activities.
3. Combine classification with prompt-level and permission controls. System-prompt revisions and tighter tool permissions provide defense in depth: the classifier handles routing, while prompts and permissions limit high-risk capability delivery if classification misses a request.
4. Run regular red-team regression tests. Ensure classifier updates do not introduce new bypass opportunities.

Engineering Considerations

Latency

The classifier should be deployed in the same data center as the gateway and support horizontal scaling. It must not become a bottleneck for time to first response.

Multi-Turn Consistency

Once a conversation has been downgraded, subsequent turns should remain on the fallback path by default.

The conversation can return to the primary model after a reset, or when the user clearly moves to a low-risk topic and the request passes reassessment.

Explainability

Users should receive a broad explanation of the downgrade category. Exact rules and thresholds should not be exposed, because that detail could facilitate adversarial probing.

Observability and Auditing

Downgrade events should flow into the platform’s shared logging and monitoring systems, supporting tenant-level and API-level quotas and audits.

Object storage can archive sanitized original requests, while message queues can support asynchronous secondary review.

Capability Tiers

The fallback should not be an arbitrary small model. It should be a version with an established safety profile, clearly understood capability boundaries, and substantial prior deployment exposure. Those properties make residual risk easier to evaluate.

Separating Capability from Safety Boundaries

The purpose of automatic downgrading is not simply to weaken the product. It is to remove unacceptable risk paths from the strongest model’s inference path.

The intended operating profile is for the primary model to continue handling more than 95% of harmless conversations and production tasks, while high-risk intent is routed to a narrower capability tier. This is a target profile for the mechanism, not a guaranteed outcome for every deployment.

For platform operators, the approach reduces the likelihood that a major capability release immediately enables uncontrolled misuse. For users, most interactions remain unchanged, while some flagged requests can still receive useful answers instead of a blanket refusal.

Further optimization should focus on false-positive rates, classification latency, and policy transparency—not on reconnecting high-risk capabilities to the strongest model.

Automatic safety downgrading is therefore a practical release strategy built around independent classification, policy-based routing, explicit user notices, continuous red teaming, and false-positive management. As a safety layer for generative services, it places cybersecurity, biological and chemical risks, and model distillation within an auditable, reversible engineering framework while model capabilities continue to advance.