Dual-Use Technology Research Safeguard Prompt Template

This prompt is designed for research platforms, academic search tools, and technical knowledge bases that must handle queries about technologies with both civilian and military applications—such as AI safety, cryptography, biotechnology, and aerospace engineering. The core job-to-be-done is to permit legitimate research discussion while applying heightened scrutiny to queries that drift toward weaponization, proliferation, or operational misuse instruction. The ideal user is a safety engineer or platform architect who needs a repeatable, auditable classification layer that does not default to blanket refusal on dual-use topics, which would cripple legitimate research workflows.

Use this prompt when your platform serves researchers, graduate students, policy analysts, or technical professionals who need to discuss dual-use concepts in academic, regulatory, or defensive-security contexts. The prompt template expects several inputs: the user's query, any surrounding conversation context, a defined output schema for risk classification, and a set of domain-specific constraints that define where the boundary sits for your organization. It is not suitable for consumer Q&A bots, general-purpose chatbots without domain expertise, or platforms where any dual-use discussion is prohibited by policy. If your use case involves real-time weapon design assistance, active CBRN (chemical, biological, radiological, nuclear) instruction, or operational attack planning, this prompt is insufficient—those scenarios require hard-coded refusal at the application layer before any model inference occurs.

Before deploying this prompt, you must define your organization's risk taxonomy for dual-use topics and prepare a labeled evaluation set covering edge cases in your specific domains. The prompt includes placeholders for [RISK_LEVEL] thresholds and [CONSTRAINTS] that should be tuned to your policy. Do not deploy this prompt without human review of its classification decisions on a representative sample of queries, particularly those near the boundary between academic inquiry and application instruction. The next section provides the copy-ready template you can adapt.

This template is the core instruction set for a system that must handle queries about technologies with both civilian and military applications. It is designed to be copied directly into your prompt management system, with square-bracket placeholders you replace based on your specific domain, risk tolerance, and output requirements. The prompt does not simply refuse or allow; it classifies the query into a risk tier and selects a response strategy appropriate for that tier, permitting legitimate research while applying heightened scrutiny to weaponization-adjacent requests.

textCopy
You are a research safeguard classifier for a platform that handles queries about dual-use technologies—technologies with both civilian and military applications. Your job is to evaluate each query and produce a risk-classified response framework.

## INPUT
Query: [USER_QUERY]
User Context: [USER_ROLE] | [AFFILIATION] | [SESSION_HISTORY_SUMMARY]

## CLASSIFICATION TAXONOMY
Assess the query against the following risk tiers:

- **TIER 1 (Permitted)**: General scientific inquiry, educational discussion, historical context, or civilian application focus with no weaponization signal. Examples: cryptography fundamentals, aerospace materials science, biotechnology literature review.
- **TIER 2 (Scrutinized)**: Queries that touch on sensitive capabilities but remain within legitimate research or defensive security contexts. Examples: vulnerability disclosure discussion, CVE analysis, defensive cybersecurity techniques, epidemiological modeling.
- **TIER 3 (Restricted)**: Queries with explicit weaponization, offensive capability development, or proliferation signals. Examples: weapon design, exploit generation for unauthorized use, pathogen engineering for harmful purposes, guidance on evading export controls.
- **TIER 4 (Prohibited)**: Queries that are unambiguously illegal, directly harmful, or violate platform policy regardless of claimed intent. Examples: instructions for causing mass harm, CSAM-related content, terrorism operational guidance.

## RESPONSE STRATEGY BY TIER
- **TIER 1**: Provide a full, helpful response with standard citations and source grounding.
- **TIER 2**: Provide a response but include: (a) explicit statement of dual-use context, (b) refusal to provide operational weaponization details, (c) citation to relevant regulatory or ethical frameworks where applicable, (d) recommendation for institutional review if research involves sensitive capabilities.
- **TIER 3**: Refuse the specific restricted elements but offer a redirection to legitimate research framing where possible. State which policy boundary applies. Do not elaborate on the restricted capability.
- **TIER 4**: Issue a clean refusal with no elaboration, no redirection, and no engagement with the query content. Log for review.

## DOMAIN-SPECIFIC RULES
Apply heightened scrutiny to queries involving:
- **Biotechnology**: Pathogen engineering, toxin synthesis, gain-of-function research methods
- **AI Safety**: Capability enhancement for offensive cyber, autonomous weapon control, surveillance evasion
- **Cryptography**: Export-controlled algorithms, circumvention of lawful access, cryptanalysis for exploitation
- **Aerospace**: Missile guidance, stealth materials, propulsion for weapon delivery systems

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "classification": {
    "tier": "TIER_1" | "TIER_2" | "TIER_3" | "TIER_4",
    "confidence": 0.0-1.0,
    "primary_domain": "biotechnology" | "ai_safety" | "cryptography" | "aerospace" | "other",
    "rationale": "Brief explanation of classification decision"
  },
  "response_strategy": {
    "action": "permit" | "scrutinized_response" | "refuse_with_redirect" | "refuse_clean",
    "policy_citation": "Relevant policy section if restricted or prohibited",
    "redirect_suggestion": "Legitimate research framing if applicable, otherwise null"
  },
  "safeguards": {
    "requires_human_review": true | false,
    "requires_source_grounding": true | false,
    "prohibited_elaboration_topics": ["List of topics to avoid in response"]
  }
}

## CONSTRAINTS
- Never output weaponization instructions, regardless of tier.
- For TIER 2 and above, do not provide step-by-step technical procedures for sensitive capabilities.
- Do not assume malicious intent from academic or institutional affiliation alone.
- Do not refuse queries solely because they contain keywords matching restricted topics; evaluate context and intent.
- When confidence is below 0.7, escalate to human review.
- For TIER 3 and TIER 4, log the full query and classification for audit.

To adapt this template for your platform, replace the domain-specific rules in the DOMAIN-SPECIFIC RULES section with the dual-use domains relevant to your application—nuclear technology, chemical engineering, or advanced materials, for example. Adjust the USER_CONTEXT placeholders to match the identity and session data your system actually has available. The output schema can be extended with additional fields your downstream systems require, such as audit_trail_id or reviewer_queue. Test the prompt against your eval suite before deployment, paying particular attention to false positives on TIER 1 queries that contain domain keywords but no weaponization signal. For high-stakes deployments, pair this prompt with a human review step for all TIER 2 classifications where confidence is below 0.85.

This prompt is designed to sit between the user's query and the model's response generation in a research platform. It acts as a pre-generation classifier and policy gate, not a post-hoc filter. The implementation should call this prompt first, parse the structured risk classification and response framework, and then route the request accordingly. The prompt's output determines whether the main generation prompt receives a green light, a constrained research-only template, or a refusal instruction. This architecture prevents the primary model from ever processing a weaponization-adjacent query without guardrails, which is critical because once a capable model begins generating a response to a high-risk query, partial harmful outputs can appear before any downstream filter catches them.

Integration flow: (1) User submits a query to your application. (2) Your application calls the safeguard prompt with the user's query inserted into the [QUERY] placeholder, along with any relevant [RESEARCH_CONTEXT] such as the user's institutional affiliation, access tier, or session history. (3) Parse the JSON output, specifically the risk_classification field (values: LOW_RISK, RESEARCH_PERMITTED_WITH_CONSTRAINTS, HIGH_RISK_REFUSAL) and the response_framework object. (4) Route based on classification: LOW_RISK passes the original query to your main research model with no restrictions. RESEARCH_PERMITTED_WITH_CONSTRAINTS passes the query to your main model but prepends the response_framework.constraints as a system instruction overlay, ensuring the model stays within academic discussion boundaries. HIGH_RISK_REFUSAL returns the response_framework.refusal_message directly to the user without invoking the main model at all. (5) Log the full classification payload, query, user context, and routing decision for audit purposes.

Validation and retry logic: The safeguard prompt returns structured JSON. You must validate that the risk_classification field contains exactly one of the three expected enum values. If parsing fails or the enum is invalid, retry the safeguard prompt once with the same inputs. If the retry also fails, fail closed: treat the query as HIGH_RISK_REFUSAL and return a generic safety refusal. Do not fall through to the main model on a classification failure. For RESEARCH_PERMITTED_WITH_CONSTRAINTS outputs, validate that the constraints field is a non-empty array of strings before attaching them to the main model call. Missing or empty constraints on a permitted-with-constraints classification is a policy gap and should be treated as a classification failure.

Model choice and latency budget: This safeguard prompt works best with models that have strong instruction-following and structured output capabilities, such as GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro. Expect 300-800ms of added latency for the classification step. For high-throughput research platforms, consider batching safeguard calls or using a smaller, fine-tuned classifier model for the initial triage, reserving the full safeguard prompt for queries that the lightweight classifier flags as ambiguous. If you fine-tune a classifier, use the eval criteria described in the topic's test harness (biotechnology, AI safety, cryptography, aerospace cases) as your training and evaluation split.

Human review integration: For RESEARCH_PERMITTED_WITH_CONSTRAINTS classifications, consider adding an optional human review step for queries from unverified accounts or first-time users. The risk_classification output includes a confidence_score field; queries with low confidence (below 0.85) in the constrained category should be queued for review rather than auto-proceeding. For HIGH_RISK_REFUSAL classifications, log the refusal but do not expose the internal risk reasoning to the user. The refusal_message field is user-facing; the risk_rationale field is for internal audit only. Never include the rationale in the user response, as it can educate adversaries on how to circumvent the classifier.

What to avoid: Do not use this prompt as a post-generation filter. By the time the main model generates a response to a weaponization query, the output may already contain dangerous information that a filter can only partially redact. Do not skip the safeguard for authenticated or

trusted

users without additional context—institutional affiliation should be passed in `[RESEARCH_CONTEXT