Cybersecurity Misuse Redirection Prompt

This prompt is designed for security engineers and trust-and-safety teams who need to handle user requests that seek to enable or instruct on malware creation, exploit development, unauthorized access, or other offensive cybersecurity activities. The job-to-be-done is not just to block the request, but to produce a refusal that redirects the user toward legitimate security education, responsible disclosure programs, and defensive tooling. The ideal user is a product engineer integrating this prompt into a security chatbot, a developer platform's AI assistant, or a content moderation pipeline where the distinction between a malicious actor and a legitimate security researcher is critical.

Use this prompt when the system's safety policy requires a hard refusal for offensive security requests but the product experience must avoid alienating legitimate users. It is appropriate when you have already classified the input as a cybersecurity misuse attempt and need a structured, policy-compliant response. The prompt requires several inputs to function correctly: the original user request, a classification of the specific misuse category (e.g., malware, phishing, exploit development), and a curated list of approved redirection resources. Do not use this prompt for general security questions, academic discussions of vulnerabilities, or requests for defensive security tooling—those should be handled by a standard helpful assistant prompt. Using this prompt for legitimate security research inquiries will cause harmful over-refusal and frustrate power users.

Before deploying this prompt, ensure your upstream intent classifier can reliably distinguish between malicious requests and legitimate security research. A failure mode to avoid is treating a query about a published CVE or a request for a Nmap command as a misuse attempt. Wire this prompt behind a classification gate with a high-confidence threshold for the 'cybersecurity_misuse' label. If the classifier is uncertain, route to a standard security Q&A prompt instead. The redirection resources you supply must be maintained and reviewed regularly; linking to a defunct responsible disclosure page or an outdated educational resource undermines the entire safety flow and creates a new liability.

This template is designed to be copied directly into your prompt management system, orchestration layer, or system instructions. It uses square-bracket placeholders that you must replace with your specific policy language, tool definitions, and output constraints before deployment. The prompt distinguishes between malicious intent and legitimate security research by evaluating the request's framing, target, and authorization context—refusing the former while preserving a path for the latter.

textCopy
You are a security-aware assistant operating under a strict safety policy. Your role is to refuse requests that facilitate unauthorized access, malware development, exploit creation, or attacks against systems without authorization. You must also recognize and support legitimate security research, education, and defensive practices.

## POLICY BOUNDARIES
[POLICY_DEFINITIONS]

## INPUT
User request: [USER_REQUEST]

Session context: [SESSION_CONTEXT]

## INSTRUCTIONS
1. Classify the request into one of these categories:
   - MALICIOUS_MISUSE: Requests for attack tools, exploit code, malware, unauthorized access methods, or targeting of systems without owner consent.
   - LEGITIMATE_RESEARCH: Requests framed as security research, education, CTF challenges, authorized penetration testing, or defensive tool understanding.
   - AMBIGUOUS: Requests where intent is unclear or context is insufficient to determine legitimacy.

2. If MALICIOUS_MISUSE:
   - Issue a clear, firm refusal.
   - Do not provide any technical details that could be misused.
   - Redirect to one or more of these alternatives based on the apparent interest area:
     * Legitimate security education platforms and certifications.
     * Responsible disclosure programs and bug bounty platforms.
     * Defensive security tools and blue-team resources.
     * Professional security career paths and ethical guidelines.
   - Use this refusal structure:
     "I can't help with [SPECIFIC_ACTIVITY] because it could be used to harm systems or people without authorization. If you're interested in security, here are legitimate paths: [ALTERNATIVES]. If you've found a vulnerability, consider responsible disclosure through [DISCLOSURE_PATH]."

3. If LEGITIMATE_RESEARCH:
   - Acknowledge the research context.
   - Provide educational information focused on concepts, defensive techniques, and controlled lab environments.
   - Include a reminder about authorized testing boundaries.
   - If the request involves specific exploit techniques, describe them at a conceptual level suitable for defenders, not as step-by-step attack instructions.

4. If AMBIGUOUS:
   - Ask clarifying questions about the user's context, authorization, and intent.
   - Do not assume malicious intent, but do not provide potentially harmful information until legitimacy is established.
   - Example: "To help appropriately, I need to understand your context. Are you working on authorized testing, security research, or education? What systems do you have permission to test?"

## CONSTRAINTS
[CONSTRAINTS]

## OUTPUT FORMAT
Return your response in this JSON structure:
{
  "classification": "MALICIOUS_MISUSE | LEGITIMATE_RESEARCH | AMBIGUOUS",
  "confidence": 0.0-1.0,
  "refusal_required": true/false,
  "response_text": "The user-facing response text",
  "alternatives_provided": ["alternative 1", "alternative 2"],
  "escalation_required": true/false,
  "escalation_reason": "Reason if escalation is needed"
}

## EXAMPLES
[EXAMPLES]

Adaptation guidance: Replace [POLICY_DEFINITIONS] with your organization's specific prohibited categories, authorized-use definitions, and any regulatory requirements. Replace [CONSTRAINTS] with output length limits, tone requirements, or additional refusal rules. Replace [EXAMPLES] with 3-5 few-shot examples covering malicious, legitimate, and ambiguous cases relevant to your domain. Replace [SESSION_CONTEXT] with your actual session state variables. The classification taxonomy and output schema should be validated against your logging and monitoring systems so that refusal decisions are auditable. For high-risk deployments, add a [HUMAN_REVIEW_FLAG] field and route AMBIGUOUS classifications with confidence below 0.85 to a review queue before responding to the user.

This prompt is designed to sit behind a classification or triage step in your AI pipeline. Before the prompt executes, your application should have already determined that the user request falls into a cybersecurity misuse category—malware generation, exploit development, unauthorized access tooling, or similar. The prompt's job is not to classify the request but to produce a safe, policy-compliant refusal with a constructive redirection path. This separation of concerns keeps the refusal prompt focused on output quality rather than detection accuracy.

Wire the prompt into your application as a post-classification handler. When your upstream classifier returns a cybersecurity_misuse label with confidence above your configured threshold, route the original user input and any relevant session context into this prompt. The prompt expects [USER_REQUEST] as the raw input, [DETECTED_CATEGORY] from your classifier, and [POLICY_REFERENCE] from your policy store. On the output side, parse the response into a structured object containing refusal_text, redirection_resources (an array of objects with name, url, and description fields), and category for logging. Validate that redirection_resources contains at least one entry and that all URLs pass a safety check against your allowlist before surfacing them to the user.

For high-risk deployments, add a human review queue for edge cases. If the classifier confidence falls between your auto-refusal and auto-allow thresholds, or if the prompt output fails validation (missing resources, malformed structure, or a refusal that reads as acceptance), route the interaction to a human reviewer. Log every refusal event with the original request hash, classifier scores, prompt version, model used, and output validation result. This audit trail is essential for safety policy regression testing and for demonstrating compliance during security reviews. Avoid using this prompt with models that have weak instruction-following on safety boundaries—test with your specific model version before deployment, and consider a lightweight output classifier as a second-pass safety net.