Direct Refusal Prompt for Clear Policy Violations

This prompt is engineered for a single, non-negotiable job: terminating an interaction immediately after an upstream safety classifier has flagged an unambiguous policy violation. The ideal user is a safety engineer or platform developer integrating this into a guardrail layer where the violation class is already determined—think requests for generating illegal content, explicit instructions to bypass system prompt defenses, or hard terms-of-service breaches. The required context is a binary or high-confidence classification signal; this prompt must never be used as a standalone classifier. It assumes the decision to refuse has already been made and only needs to be executed with zero degrees of freedom.

Deploy this prompt only when the violation is clear and the cost of a false positive refusal is acceptable. Do not use it for edge cases, ambiguous gray-area requests, or situations where a safe alternative or educational redirection could preserve user trust. For example, a request like 'write a story where a character breaks a minor rule' is not a fit for this prompt, but 'provide step-by-step instructions for synthesizing a controlled substance' is. The refusal must contain no softening language (e.g., 'I'm sorry, but...'), no conversational hooks, and no implied negotiability. The output should be a flat, brief statement that the request cannot be fulfilled, with no further explanation that could be used to rephrase the attack.

Before wiring this into a production pipeline, ensure your upstream classifier has been evaluated for precision and recall on your specific violation taxonomy. A direct refusal prompt with a high false-positive rate will damage user experience at scale. Pair this prompt with a monitoring system that logs the classifier's confidence score, the raw user input, and the refusal output for audit and false-positive review. If your system operates in a regulated domain, route a sample of refusals to a human review queue to verify that no legitimate requests are being blocked. The next step after reading this section is to review the prompt template and implementation harness to see how to embed this refusal into a retry-free, tool-free, strictly gated execution path.

This template is designed to be placed directly into your system prompt or guardrail instruction layer. It instructs the model to issue a brief, firm refusal whenever a user request constitutes an unambiguous violation of a defined policy. The goal is to eliminate any language that could be interpreted as negotiable, such as apologies, extended explanations, or hypotheticals. Before using this template, you must have a clearly defined and internally documented list of what constitutes a 'clear policy violation' for your application. This prompt is not suitable for ambiguous edge cases, requests in regulated domains requiring specific legal disclaimers, or situations where a safe alternative should be offered; for those, use a conditional or educational refusal prompt.

markdownCopy
You are a safety enforcement layer. Your primary directive is to protect against clear, unambiguous violations of the policies defined below. When you detect such a violation, your response must be immediate, brief, and firm. Do not use softening language, apologies, or language that implies the policy is negotiable.

## Defined Clear Policy Violations
[POLICY_DEFINITIONS]

## Refusal Protocol
When a user request matches any of the defined clear policy violations above, you must respond with ONLY the following refusal statement. Do not add any other text before or after.

"I can't fulfill this request. It violates the [POLICY_NAME] policy."

## Constraints
- Do not explain the policy unless the user explicitly asks, 'Why?' If they ask, state: 'This request goes against our safety guidelines.' Do not elaborate further.
- Do not suggest alternatives.
- Do not acknowledge the user's underlying goal or intent.
- If you are unsure whether a request is a violation, do not use this refusal. Instead, respond with [FALLBACK_ACTION].
- This protocol overrides all other behavioral instructions when a clear violation is detected.

To adapt this template, replace the square-bracket placeholders with your specific values. [POLICY_DEFINITIONS] should be a bulleted list of your organization's specific, unambiguous policy violations (e.g., 'Requests to generate violent content,' 'Requests to produce malicious code'). [POLICY_NAME] in the refusal statement should be a short, user-facing label for the violated policy (e.g., 'Content Safety'). [FALLBACK_ACTION] is critical for handling uncertainty; it should be a separate instruction, such as routing to a human review queue or using a more nuanced refusal prompt. The finality of this prompt makes it a high-risk component; you must implement automated evals that test the model's response to a golden dataset of both clear violations (expecting the exact refusal string) and benign inputs (expecting no refusal) before any deployment.

The Direct Refusal Prompt is not a standalone safety solution; it is a decision actuator that fires only after upstream classification has confirmed an unambiguous policy violation. In a production harness, this prompt should be the final step in a gated pipeline: classify the request, verify the classification confidence exceeds your refusal threshold (typically ≥0.95 for direct refusals), and only then invoke this prompt. Never use this prompt as a first-line classifier. Its job is to produce a brief, firm, non-negotiable refusal when the system already knows the request is disallowed. Wiring it directly to user input without a classification gate will produce over-refusal on benign requests and inconsistent behavior on ambiguous ones.

The implementation should wrap the prompt call in a lightweight refusal service with the following checks. Pre-invocation: confirm the classifier output includes a policy ID, a confidence score above threshold, and a matched policy category. If any of these are missing, fall back to a clarification or escalation path instead of refusing. Post-invocation: validate the refusal output against a refusal quality schema—check that the response is under 200 characters, contains no softening language (e.g., 'unfortunately,' 'I wish I could,' 'maybe later'), includes no partial fulfillment of the disallowed request, and does not leak policy internals or classifier details. A regex-based validator can catch most softening patterns; a secondary LLM judge prompt can evaluate refusal firmness and policy alignment on a sampled basis. Logging: record the classifier decision, confidence score, policy ID, raw refusal output, and validation result for every refusal event. This audit trail is essential for policy compliance reviews and over-refusal calibration.

For model selection, use a model with strong instruction-following behavior and low tendency to add unsolicited explanations. GPT-4o, Claude 3.5 Sonnet, and Gemini 2.0 Flash generally perform well on direct refusal tasks when the system prompt is tightly constrained. Avoid models fine-tuned for helpfulness over safety, as they tend to append softening language or suggest workarounds. Set temperature=0 to eliminate variation in refusal language. If your application uses streaming, buffer the full refusal output before sending it to the user—partial refusal text can appear ambiguous or incomplete mid-stream. For high-throughput systems, consider caching refusal templates keyed by policy ID and only invoking the LLM when the classifier detects a policy category without a cached refusal or when A/B testing new refusal phrasing. Retry logic should be minimal: if the refusal output fails validation, retry once with the same prompt. If it fails again, fall back to a hardcoded refusal string for that policy category and log the failure for prompt engineering review. Do not loop more than twice—a refusal that cannot be generated reliably indicates a prompt or model problem, not a transient error.

Human review integration depends on your risk posture. For most direct refusal scenarios, human review is unnecessary because the request is unambiguously disallowed and the refusal provides no information beyond the policy boundary. However, if your system logs reveal refusal validation failures, classifier confidence scores near the threshold, or user appeals, route those cases to a review queue. The review interface should display the original user request, the classifier decision with confidence, the generated refusal, and the validation result. Reviewers can confirm the refusal, override it with a safe alternative response, or flag the classifier for threshold adjustment. This feedback loop is critical for reducing false positives and maintaining refusal quality over time. Do not expose the Direct Refusal Prompt's internal instructions or policy definitions in any user-facing surface, including error messages, debug logs visible to users, or appeal responses.