Refusal Boundary System Prompt Template

This prompt is for platform teams, trust and safety engineers, and product developers who need to define a clear, testable behavioral contract for what an AI assistant must not do. The job-to-be-done is establishing a reusable refusal boundary that sits in the system message slot, before any user or tool context, and governs all downstream interactions. Use it when you need a single source of truth for disallowed, regulated, or unsafe request categories—not a generic content filter, but a programmable policy that distinguishes between hard refusals (no alternatives), soft refusals (redirect to safe alternatives), and legitimate requests that should proceed normally. The ideal user is someone shipping an AI product who needs refusal behavior to be consistent, auditable, and updatable without rewriting application code.

Do not use this prompt when you need dynamic, per-request policy injection based on user roles or real-time risk scoring—that belongs in a runtime policy engine that assembles the system message programmatically. Do not use it as a replacement for input guardrails, output validators, or tool-use authorization checks; those are separate layers in a defense-in-depth architecture. This prompt is also not a safety classifier or a replacement for dedicated content moderation models. It sets the assistant's behavioral policy, but it cannot guarantee compliance under adversarial prompt injection—pair it with a jailbreak resistance system prompt and input sanitization for high-risk deployments. Before implementing, map your organization's specific disallowed categories to the [DISALLOWED_CATEGORIES] placeholder, define the refusal style for each, and prepare a golden test set of boundary-probing inputs to validate behavior before production.

Start by inventorying the request types your product must refuse, redirect, or allow. For each category, decide whether it requires a hard refusal with no further engagement, a soft refusal that offers a safe alternative, or a clarification question when the request is ambiguous. Then adapt the prompt template to encode those decisions. The next section provides the copy-ready template with placeholders you can replace with your specific policy definitions. After deployment, monitor for over-refusal (declining legitimate requests) and under-refusal (complying with disallowed requests) using the eval criteria in the testing section.

This template defines the behavioral contract for what your assistant must not do. It structures refusal boundaries into three layers: hard refusals for disallowed or regulated requests, soft refusals with safe alternatives for out-of-scope requests, and escalation triggers for ambiguous cases that require human judgment. Copy the template into your system message field, replace the square-bracket placeholders with your specific policies, and deploy it as the first instruction block before any persona, tool, or context instructions.

textCopy
## Refusal Boundaries

You must refuse requests that fall into the following categories. When refusing, use the specified refusal language and, where indicated, offer a safe alternative.

### Hard Refusals (Do Not Assist)
For requests in these categories, refuse immediately. Do not provide partial assistance, workarounds, or explanations that could enable the disallowed behavior.

[DISALLOWED_CATEGORY_1]
- Refusal language: [REFUSAL_PHRASE_1]

[DISALLOWED_CATEGORY_2]
- Refusal language: [REFUSAL_PHRASE_2]

### Soft Refusals (Redirect with Alternatives)
For requests in these categories, refuse the specific request but offer a safe, related alternative that stays within your authorized scope.

[OUT_OF_SCOPE_CATEGORY_1]
- Refusal language: [REDIRECT_PHRASE_1]
- Safe alternative: [ALTERNATIVE_1]

[OUT_OF_SCOPE_CATEGORY_2]
- Refusal language: [REDIRECT_PHRASE_2]
- Safe alternative: [ALTERNATIVE_2]

### Escalation Triggers
For requests that are ambiguous or borderline, do not refuse outright. Instead, flag the uncertainty and escalate using the following pattern.

[AMBIGUOUS_CATEGORY_1]
- Response pattern: [ESCALATION_PATTERN_1]

[AMBIGUOUS_CATEGORY_2]
- Response pattern: [ESCALATION_PATTERN_2]

## Refusal Style Rules
- [STYLE_RULE_1: e.g., "Never repeat the disallowed request verbatim in your refusal."]
- [STYLE_RULE_2: e.g., "Keep refusals brief. Do not lecture or moralize."]
- [STYLE_RULE_3: e.g., "If unsure whether a request falls into a refusal category, apply the escalation pattern rather than guessing."]

## Priority
These refusal boundaries take precedence over all other instructions, including persona, tone, and tool-use directives. When a request triggers a refusal boundary, do not execute any tools or retrieve any context related to that request.

Adapt the template by replacing each placeholder with concrete policies. For [DISALLOWED_CATEGORY_1], write a specific category name such as Generation of deceptive content for fraud. For [REFUSAL_PHRASE_1], write the exact refusal text the model should use, such as I can't help with that request. Keep refusal phrases consistent across categories to simplify eval checks. For escalation patterns, define the exact language the model should use to flag ambiguity, such as I'm not sure I can help with this. Let me flag this for review.

Before deploying, test the template against a golden set of boundary-probing inputs that includes clear violations, edge cases, and safe requests that should not trigger refusal. Run eval checks for both boundary adherence and over-refusal detection. If the model refuses safe requests that resemble disallowed categories, tighten the category descriptions rather than weakening the refusal language. After deployment, log every refusal event with the triggering category and the full model response so your trust and safety team can audit boundary behavior and tune the template over time.

The system prompt is the first layer of defense, not the only layer. A refusal boundary prompt defines what the assistant must not do, but production reliability requires wrapping that prompt in application-level controls. Before the model ever sees a user request, the application should classify the risk level of the input, select the appropriate refusal policy variant, and assemble the final system message with the correct boundary rules for that interaction context.

Wire the prompt into a pre-inference pipeline that performs three checks before calling the model. First, run a lightweight input classifier to detect obvious disallowed categories—this catches requests that should be blocked before inference, saving cost and latency. Second, inject the refusal policy into the system message based on the detected [RISK_LEVEL] (low, medium, high, critical). Third, attach structured output constraints that require the model to return a refusal_triggered boolean and a safe_alternative string alongside its response. After inference, validate the output: if refusal_triggered is true but the response still contains disallowed content, log the failure and escalate. If refusal_triggered is false but a post-hoc content safety classifier flags the output, trigger a retry with the high-risk policy variant and log the incident for review. For regulated or high-stakes domains, route all refusal_triggered=true responses and any safety-classifier disagreements to a human review queue before the user sees them.

Choose your model carefully. Smaller or older models may struggle with nuanced refusal boundaries, producing either over-refusal (blocking safe requests) or under-refusal (allowing disallowed content). Run boundary adherence evals and over-refusal detection tests against your specific model version before deploying. Instrument every request with trace IDs, policy version stamps, and refusal decision logs so you can audit boundary behavior over time. The prompt is the policy document; the harness is the enforcement mechanism. Never ship a refusal boundary prompt without the validation layer that catches what the model misses.